Updates the forest editor tooling to utilize the new sets, and adjusts the creation of new Brushes in the forest editor to have user select a target module first.
This ensures all a module's brushes are grouped into the new ForestBrushGroup class which auto-registers into the ForestBrushSet, thus allowing modules to have their own sets of brushes that automatically hook into the editor workflow.
Processed core, tools and default modules to utilize assets
Converted all console types that were string based, such as TypeImageFilename to utilize const char*/the string table, which avoids a lot of type swapping shenanigans and avoids string corruption
Removed unneeded MainEditor mockup module
Removed some unused/duplicate image assets from the tools
The uninitialized variable 'box' is assigned to itself. Judging from the fact that this is a copy constructor, I think that it is necessary to store in the 'box' the value of 'cv.box'
This makes some tweaks to the engine to support this, specifically, it tweaks the hardcoded shaderpaths to defer to a pref variable, so none of the shader paths are hardcoded.
Also tweaks how post effects read in texture files, removing a bizzare filepath interpretation choice, where if the file path didn't start with "/" it forcefully appended the script's file path. This made it impossible to have images not in the same dir as the script file defining the post effect.
This was changed and the existing template's post effects tweaked for now to just add "./" to those few paths impacted, as well as the perf vars to support the non-hardcoded shader paths in the engine.
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.
