based on https://github.com/TorqueGameEngines/Torque3D/pull/1165 and after further talks with @AtomicWalrus:
use the massbox or bounds box based mRigid.setObjectInertia method
to reduce recirulating, combine resolvecollision and resolvecontacts
clamp seperation force for contact resolution
gravity normalized to earth standard (9.8,not 20)
take delta-time into account *once* for kinetic energy vs gravity rest checks
and for debug purposes, expose mRigid.atRest to the inspector to see if it's truly at reast or grinding calcs to minimal effect
by locking in the material feature variation to ensure it uses vertex lighting due to colorization, as well as a few other switches, and applying an explicit vs default stateblock blend
do similar with moon so you don't have to set that to explicitly translucent either
review of per and post bake protocols showed that the CAPTURING shader macro was not being properly recompiled in. as opengl was not playing nice with a simple batch shader recompilation for all effected shaders, a full lightmanager restart is at time of writing required. once we have a proper globally cached scene structure stored off GPU side, we'll want to change GFXShader::addGlobalMacro("CAPTURING", String("1")); on over to dirtying that value in the cached buffer via setting a shader global uniform
review of prefilter examples shows a fixed sample count of 1024 across multiple implementations, so we'll use the standard barring further research into where that number is comming from for a scalar approach
review of gl shaders shows a doubleup in compiled state testing, so slimmed that down and added additional debugging reports
1) fix spotlight shadow casting. we weren't properly accounting for reversedepthbuffer there
2) fix mismatched variables in forward lit spotlight param array
3) use disney diffuse in the generalized brdf, and apply it for spotlights after angular attenuation, not before
4) .provide a generailze luxTargMultiplier approach for spot and point lights (as well as future growth areas) so that range, angle ect can impact the brightness variable sent to a given light source shader without perpixel overhead
5) for spotlightParams in particular, use sizeof(point4f) for the alignedarray untill that's properly reviewed/revised
6) narrow attenuation slightly based on a given lights dot product to prevent tool vs outcome leakage, plus provide safeties for when a given spotslight's inner and outter angles match identially
