Additional Contributors: @ andrewmac, @ LuisAntonRebollo
So. those of you that have been following along with the Deferred or PBR branches have likely gotten a bit of a taste of this already, but in the interests of letting folks digest things in a nice testable manner, the first thing out of the gate will be the shadow caching subsystem.
- Deferred Shading
- Shadow Caching
Anyone familiar with pretty much any engine knows that shadows are one of, if not the most hefty hits on the rendering pipelline. Dynamic more so than any other. Stock torque to date uses fully dynamic shadow regeneration per frame for everything unless you explicitly bake them in a third party application via lightmapping tricks, additional materials, et al.
To alleviate this a bit, Andrew and I dug around a bit and dug into regeneration portion of the shadow gen subsystem, augmenting it with a pair of cyclic updaters.
Here's how this works:
Materials gain a new flag:
Lights gain 2 new millisecond entries:
Lights start out as now, generating shadows across the board. but no longer update every frame. Instead they wait until either the dynamicRefreshFreq has expired if it's tagged as dynamic, or the static one does if it's static to redraw the relevant portions of the 'shadow scene' for lack of a better term. At time of writing, all materials default to dynamic by request in order to least disturb existing projects, which means folks wanting to take the most advantage of that will need to flip that off for all background materials. (those wishing to automate the process the other way around juts need to flip https://github.com/Azaezel/Torque3D/com ... 591c75R185 and tag players or anything animated to true.
Now the bad news: Turns out there was a lurking bug in https://github.com/Azaezel/Torque3D/com ... 466c4eae99 causing severe issues with spotlights in particular, though given the formation, that was more of a timebomb waiting for someone else to step on it at some point anyway, so looking to fully address that.
At present, that brings the bug down to one report, specifically in debug mode, of
OPENGL: GL_INVALID_OPERATION error generated. Cannot begin query on an active query object.
per light after which queries operate correctly rather than continuous spam from both that one and a secondary error report. (http://i.imgur.com/EdOdT2z.png)
Additional research notes on that matter:
https://www.opengl.org/sdk/docs/man3/xh ... nQuery.xml
GL_INVALID_OPERATION is generated if glBeginQuery is executed while a query object of the same target is already active.
As this stuff was always intended to be a community project, if folks want, I can flip that over to PR (after cleaning it down to the one documented commit) and let someone clean it up in the development fork, but my first instinct is to hold off on that until this last bit is sorted fully.