Also adds a fix to the mesh item tab in the forest editor to correct odd selection behavior that could erroneously cause selection of two items in the list when you only clicked one.
while not a major issue per-se, the sheer number of times the engine has to jump back in memory and backfill data in a given class can add up. First run of... many.,
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.
Many places utilize post-incrementation with iterators, but it's better performance to use pre-incrementation.
Resolved by changing the iter++ instances to ++iter;
Many instances of a function or expression being used repeatedly, which can lower performance.
Fixed it in these cases by creating on local var, reference or pointer that's used instead.
Adds the file path to the saveDataFile call (missionpath\missionname.forest as the format)
This correctly utilizes the forest object's datafile field if it's set.
If not, it will create a new forest item with the missionPath\missionName.forest convention.
This also removes the checks for the hardcoded "theForest" forest object name, so that if it is renamed for some reason, it doesn't break.
Lastly, this corrects a minor semi-related bug, where if you are in the forest editor and have a brush selected, and then click to paint, but no forest object currently exists, it prompts to create one. Once the forest object is created, it would trigger the editor to inspect the newly made forest object. If you attempted to paint the currently selected brush, there was a mis-match in the inspector information, and it would trigger a crash.
This has been corrected by re-initializing the forest editor's selected tool mode so it can be utilized immediately after the forest object is created.
- Con::executef now uses a template
- All public execution functions now restore the console stack upon return
- Fixed bad parameters on some callbacks
- Reverts get*Arg behavior
So the problem is that when your inside the sphere it won't render so it might make someone
think that it's not working right. So what I did was determine if the camera is inside the sphere.
If the camera is inside the sphere, then I find the distance from the center of the sphere to the camera
Round down and use that as the radius to draw the sphere.
That way if someone zooms in or out, their screen is still showing the sphere.
- Fix for issue https://github.com/GarageGames/Torque3D/issues/525 This
fix takes into account the skewed view into the world when you have a
projection offset and the ability to see further into the scene at the
edges opposite to the offset.
- SceneCullingState now has two frustum rather than one: a culling
frustum and camera frustum.
- The camera frustum should be referenced when you need the projection
matrix or don't want a skewed frustum.
- The culling frustum should be referenced during any scene culling or
when determining what dynamic geometry to render. It currently skews
itself to take into account any projection offset (automatically
calculated in SceneCullingState constructor).
- When there is no projection offset, the camera frustum and culling
frustum are the same. This usually means any time when not using the
Oculus Rift.
Removing the "using namespace Torque" from header file to prevent issues
with certain engine addons conflicting with ::UUID defined by windows
and Torque::UUID defined by T3D.
- Prevent stack corruption in a few places
- Use correct type in printfs
- Reduce type conversions in EngineApi & dAto*
- Fix compilation on GCC
- Tidy up code
