[Closed] Subsector rendering

Moderator: Developers

Subsector rendering

Postby Apeirogon » Thu Jul 12, 2018 11:11 am

Just an options which say to gzdoom "draw entire subsector with all segs".
With this option highly detailed maps can be played without significant lags.

I mean, gzdoom iterate through whole bsp tree to check what exactly it must draw.
After this gzdoom check how much segs have walls and which are it must draw.
And if there are too much walls tree become overly branched, because of implementation of bsp tree in doom.
Or I misunderstood logic of bsp tree in doom?
Apeirogon
I have a strange sense of humour
 
Joined: 12 Jun 2017

Re: Subsector rendering

Postby Graf Zahl » Thu Jul 12, 2018 11:43 am

What should that accomplish? With OpenGL it is not possible to pregenerate the render data so you end up doing more work. With Vulkan it will be doable to pregenerate an entire sector's non-translucent geometry as a single command buffer and handle it in one go - but that's a long term goal - first Vulkan needs to work.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Subsector rendering

Postby Apeirogon » Thu Jul 12, 2018 2:59 pm

Graf Zahl wrote:What should that accomplish?

Decrease load on processor. I mean, processor spend time to check what segs videocard must draw, so that map took less space in memory and save some times for other stuff. But on overly large maps, like some blade of agony maps as most popular, it take too much time to check waht segs it, processor, must send to videocard for drawing.

And "nowadays", and "yesterdays", computers have enough memory to store "garbage" graphich data, like drawed texture, most part of which invisible to player. So if processor, insted of computing what segs player see and what not, send entire subsector to videocard, I think, this this will reduce the load on the processor.
Apeirogon
I have a strange sense of humour
 
Joined: 12 Jun 2017

Re: Subsector rendering

Postby Graf Zahl » Thu Jul 12, 2018 3:15 pm

You don't understand. OpenGL has no means to store this stuff efficiently. You still have to do the really time consuming stuff, i.e. passing the data to the GPU, manually.
Vulkan, yes, but not OpenGL. This was one of the main reasons why these modern render APIs were invented in the first place. And unless you missed it, a Vulkan based renderer is already being worked on, so this suggestion has little reason to stay.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Subsector rendering

Postby Apeirogon » Thu Jul 12, 2018 3:26 pm

You right, I still dont understand...
Apeirogon
I have a strange sense of humour
 
Joined: 12 Jun 2017

Re: Subsector rendering

Postby Graf Zahl » Thu Jul 12, 2018 3:51 pm

I'll try to explain.

This will only speed up things if you can bake all the data for a sector into a single render object that can be dispatched using a single API call.
Vulkan can do that. You can create a single command buffer for the entire sector and when the sector needs to be drawn, just queue the command buffer for rendering and you are done. Lots and lots of time saved if done right.

On OpenGL you still need to set up the textures, the uniforms and a lot of other related data on the CPU for every draw call separately, i.e. you only save the time needed to collect the data. You cannot save much time with this (i.e. less than 10% is the best case scenario. That's simply not worth doing because of the needed checks elsewhere to invalidate the data if it changes.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany


Return to Closed Feature Suggestions

Who is online

Users browsing this forum: Pixel Eater and 0 guests