Implementing hub levels a la Hexen, Dishonored, etc.

Started by motorsep, November 28, 2014, 02:19:22 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Sir Blackington

That technique is pretty much what I was trying to do I while back in eurocity to try and get the lighting better, but hadtrouble reloading the map, and then my computer died...
Anyways. For d3 poly counts, sure it works, but it would be nice to have the ability to be able to go beyond those polycounts, and not have to worry about stencil shadows exasperating the situation.

And do you think the performance issues could be helped if a tecnique like vsm? Though I know it comes with its ownchallenges

motorsep

Quote from: Sir Blackington on December 01, 2014, 08:16:46 PM
That technique is pretty much what I was trying to do I while back in eurocity to try and get the lighting better, but hadtrouble reloading the map, and then my computer died...
Anyways. For d3 poly counts, sure it works, but it would be nice to have the ability to be able to go beyond those polycounts, and not have to worry about stencil shadows exasperating the situation.

And do you think the performance issues could be helped if a tecnique like vsm? Though I know it comes with its ownchallenges

Those are just filtering of shadow maps. What RBDoom 3 BFG does is it binds FBO 7 times. It essentially doing rendering for each of the cubemap sides, while for example Darkplaces engine renders it only once and atlases shadow maps (only bind FBO twice; I guess first FBO binding happens anyway, regardless - thus 2 vs 7, instead of 1 vs 6). Back in the days when shadow mapping was just coming around, maybe that was the technique. No game does 7 FBO bindings nowadays.

So once it's solved on rendering side of the engine, you can pretty much use any filtering in shader, which gotta be optimized too anyway, and RBDoom 3's shader is not optimized either. So what I am saying essentially is that RBDoom 3 with shadow mapping is much slower than stock Doom 3 BFG or RBDoom 3 without shadow maps. People with powerful PCs and GPUs don't notice it, but average PC gamers will notice it.

Sir Blackington

Thank you for the clarification as exactly why it is slower. I was off the mark as to why it was slow. As you say for point lights, having to render each side of the cube map would be a big performance hog, but for parralel lights ( I think they are supported ) wouldn't it just have to bind only once? And if that's the case then it should still be ok for very large scenes with sun. Again thanks for your insight motorsep.


motorsep

#18
Quote from: Sir Blackington on December 01, 2014, 09:35:10 PM
Thank you for the clarification as exactly why it is slower. I was off the mark as to why it was slow. As you say for point lights, having to render each side of the cube map would be a big performance hog, but for parralel lights ( I think they are supported ) wouldn't it just have to bind only once? And if that's the case then it should still be ok for very large scenes with sun. Again thanks for your insight motorsep.

Afaik it's 4 FBO binding for parallel lights, since shadow maps are cascaded for that type of light. But, it's usually just one light per level, whether 7 binding happens per point light in the scene, and there could be many point lights.

We optimized it as much as possible and matched performance (GPU / RB timers) to shadow volumes on most of the test cases. It could have been faster with proper method, but better like this than slower. Note that as scene complexity grows (polygon wise) rendering doesn't get slower.

Btw, check this out - https://www.youtube.com/watch?v=3fOpHRrOBJQ&feature=youtu.be&t=1m42s and explanation of rendering pipeline tesseract.gg/renderer.txt
It's rendering done right. I am hoping that one day the guy can re-word shadow maps in my engine and add real-time GI.

Basically the idea is to be able to have more tris in the view at the linear cost of performance.

Sir Blackington

I remember seeing some of the tesseract stuff that you put up on another post and being impressed with the gi, and rendering on the fly. Was looking at that txt file on break and really interesting stuff onwhat they did with pcf to make it work more robustly then vsm. Too bad my break is up. Ill have to read the link they showed me after work. Good post motorsep

motorsep

I think we might still use hub map structure, but I solved the issue associated with bunch of polys and large open maps:

https://www.youtube.com/watch?v=d0f--Zv-LdA