Visportals vs func_portals vs antiportals

[SteveL]

Should the lightgem render be able to trigger animation updates? I don't suppose it matters if the player view has already been rendered as the update will already have been done for the frame. Unless the lightgem has a different FOV and could catch different AI?

 

NB I've not actually tested whether it's doing so, just trying to understand why in my latest test the shadow is only getting culled in the lightgem rendering passes.

 

*sigh* this was all so simple until shadows got involved.

[nbohr1more]

I suppose you could have the LOD system switch shadows off if the entity is within x percent of the center of the occluder and y distance away from the player

rather than fiddle with how the shadows are generated. I was just hoping you'd start tinkering with shadow code and maybe we'd get some optimization there too

[New Horizon]

Unless the lightgem has a different FOV and could catch different AI?

 

Not sure I understand what you mean. The lightgem captures a snap shot of the top and bottom of a diamond shaped model from the players position. It doesn't capture any of the game world. Maybe I misunderstood what you meant though.

[SteveL]

I suppose you could have the LOD system switch shadows off if the entity is within x percent of the center of the occluder and y distance away from the player

rather than fiddle with how the shadows are generated. I was just hoping you'd start tinkering with shadow code and maybe we'd get some optimization there too

 

No worries, I'm not giving up, just looking a little puzzled. Time to check carefully which system of coordinates and orientations is being used by each bit of the code I've hijacked to try a proof of concept. There are at least 4 different coordinate systems in play and 3 ways of storing orientations and plenty of mysterious uses of matrices presumably to give clever quick answers to 3D calculations. Low level code optimised for speed of course, not really designed for humans to be able to treat like a pick-n-mix.

 

My hack seems to be doing what was intended but only in the lightgem rendering pass, which is why I was looking at that. Those shadow vol frustums in my screenshots above are being generated during the lightgem rendering pass, not the playerview one. I've not had more than an hour or two to look at it the last couple of nights though, so I'll stop trying to look for quick fixes shortly and try to work it out properly.

 

Not sure I understand what you mean. The lightgem captures a snap shot of the top and bottom of a diamond shaped model from the players position. It doesn't capture any of the game world. Maybe I misunderstood what you meant though.

 

It needs to know if the shadow of an animated entity falls on it though, so it'd make sense that it does the same thing that the playerview rendering pass does: first make a list of entities directly in the FOV, then test all other entites in the visleaf against all nearby shadowcasting lights to see which ones could cast a shadow over the view. Where it finds a potential shadow, that entity gets an animation update that frame so the shadow can be rendered precisely. There's no reason not to expect that to happen for the lightgem too I guess, and it'd be rare for the lightgem to need an animation update that wasn't needed for the player view anyway.

[nbohr1more]

I don't know if this will help you decode the coordinates but here are some papers from id Software and Intel that outline some of the pertinent code areas:

 

https://software.intel.com/en-us/articles/optimizing-the-rendering-pipeline-of-animated-models-using-the-intel-streaming-simd-extensions/

 

See PDF links at the bottom too:

 

https://software.intel.com/sites/default/files/m/d/4/1/d/8/293752.pdf

 

https://software.intel.com/sites/default/files/m/d/4/1/d/8/293748.pdf

 

https://software.intel.com/sites/default/files/m/d/4/1/d/8/293749.pdf

 

https://software.intel.com/sites/default/files/m/d/4/1/d/8/293750.pdf

 

https://software.intel.com/sites/default/files/m/d/4/1/d/8/293751.pdf

[SteveL]

You are a goldmine nbohr1more. I read only half the first article before replying, and it's describing the next evolution of the rendering pipeline over the one I'm looking at, but that's no bad thing and it's illuminating. My printer is chugging away on the pdfs and my bedtime reading for the next several nights is sorted

[SteveL]

I left this thread hanging, so I'm back with a quick non-update to say that I plan to resume occluder experimentation in a couple of weeks. It's on hold while I relearn linear algebra and while I read the rendering bible Real-Time Rendering, which I bought earlier this week. It was hurting my head too much trying to figure out what the code was intended to do without knowing the background theory.

 

Does anyone have reading recommendations for an up-to-date top-up to Real-Time Rendering? The current edition is 6 years old, which is fine for understanding our engine, but since I'm putting in the effort of reading it I'd like to know what's happened in the intervening 6 years too.

[nbohr1more]

I think 6 years ago is still pretty relevant to today's game standards. Most modern engines just scale-up existing rendering paradigms.

 

That said, you may want to look into stuff like "Clustered Deferred or Forward Rendering"

 

http://aras-p.info/b...-shading-links/

 

You may also wish to review stuff like voxel cone tracing, etc.

 

Here is a reddit thread with some modern GI techniques:

 

http://www.reddit.co..._vs_cone_voxel/

 

to gain some insights into current and upcoming developments.

 

The hard part is that a great deal of the modern rendering paradigm has moved onto the GPU so to advance significantly

beyond what Doom 3 offers, you must get your feet wet in shader languages.

 

Possible assistance there:

 

http://www.amazon.com/OpenGL-Shading-Language-3rd-Edition/dp/0321637631

 

Still, a clever CPU algorithm can spare a certain amount of GPU work and (in Doom 3's case) even spare some wasted CPU work.

Edited August 31, 2014 by nbohr1more

[nbohr1more]

Hmm...

 

This might help too:

 

https://github.com/NVIDIAGameWorks/OpenGLSamples/tree/master/samples

[SteveL]

Thank you. I've already come across my first shader program in RTR chapter 3 so I'm forewarned You can't really do a "Hello World!" in the graphics pipeline so the example they use is "Gooch shading" on a teapot, which needs only half a dozen lines of code to achieve a nice effect.

[nbohr1more]

That one reference has a broken link for tile-based forward rendering. Here is the wayback archive.

 

https://web.archive.org/web/20130226142429/http://www.pjblewis.com/articles/tile-based-forward-rendering

 

the reason I bothered to grab this is that it uses a z-prepass just like Doom 3 and even mention's "Carmack's Reverse"

so the author probably was thinking of Id Tech 4 when he designed this.

[nbohr1more]

So I went back to reading the Fabien Sanglard article and noticed that he indicates that the z-buffer prepass should eliminate overdraw yet

the engine itself has a cvar to show overdraw so that must mean "z-fill overdraw" if unseen surfaces aren't shaded?

 

Still, rendering all surface interactions including all textures for each light pass rather than accumulating the light shading contributions then

running all surfaces in one run is more fillrate intensive... though it puts more weight on CPU skinning being the main bottleneck.

Edited September 3, 2014 by nbohr1more