Agreed, it makes sense that the shaders are common, so that people can start with empty and add their own art without worrying about stuff not working as expected.
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.
This resolves menu order, cleanup and close/re-open issues, as well as crashes on close.
It also modifies the look slightly to look closer to the windows menubar to keep a cohesive look regardless of platform.
- Updated to work with 0.5.x SDK
- Uses Oculus Rendering rather than PostFX
- Stereo rendering refactored so more rendering info is grabbed from the DisplayDevice
- Implements an Offscreen Canvas for in-game gui with oculus
- Message dialogs and metrics display can now go to the OffScreen Canvas (if oculus demo is setup correctly)
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.
The editor didn't test that a mission area actually existed, so when you switched to the editor, it would trigger the crash.
It now tests if there is a mission area when switching to the editor tool, and if there is not, prompts for the creation of a new one, similar to the auto-prompt for creating terrain blocks.
