1) Reset the build when adding potential dirties to the list to ensure it isn't trying to kill off a dirty entry that it's passed by.
2) mSaveIntermediates = true; causes leakage even with all this. still tracking that end.
3) Need to remove a dead tile whether there's new data to replace it with or not. Empty tiles are an entirely possible case. Even a probable one if you have high verticality in a level.
4) Likewise you don't want to re-feed the same geometry list for a given tile in case the conditions have changed.
5) If no vertcount then clear all geometry entries. (that one might be paranoia)
As I nor az have been able to find any issues with this so far, I'll push this through. We can handle any emergent problems as they come up, but so far it looks solid.
SPECIAL NOTE: highly suggest https://github.com/GarageGames/Torque3D/pull/1441 or a variation thereof to prevent debug spew and false-postives for occlusion results.
With significant research, development and prototyping assistance from both @andr3wmac (shaders and partial hook work), and @LuisAntonRebollo (additional culling)
System operates as follows:
1) materials are given an additional castDynamicShadows boolean entry. (Default at time of writing is true by request. Personal usage at time of writing defaults to false. value is default-initialized in materialDefinition.cpp. script/gui exposed)
2) lights are given a staticRefreshFreq and dynamicRefreshFreq (in milliseconds). script/gui exposed
3) materials are (effectively) sorted into dynamic and static shadowmap render lists based on flag. (see shadowMapPass.cpp)
4) initial shadowmaps are generated for each light and 'list'.
5) as each refreshFreq times out, the relevant shadowmap for a given light is refreshed.
Special notes:
dynamicRefreshFreq for all lights is set to a (script exposed) 8MS refresh timer.
StaticRefreshFreq for the lions share of lights defaults to 250 MS (1/4 of a second)
scattersky's embedded light, which is intended to operate in a mobile manner, defaults to 8
to reiterate, these are all customizable per-light via script/inspector gui in the case of alternate project needs.
Will go ahead and merge this in on the grounds that while it may not technically be possible to make this problem occur(at least no one seems to have been able to reproduce it), having the clamping of values is generally a smart move on principle and prevents even the weird outliers from happening.
