I have about 25% of the level outline drawing tools completed. The line an shape tools, together with the terrain grid, will progressively extract level entities out of templates and use the 3D models in the templates, their materials, their lights and arrange them accordingly around the player's camera position. Blender 3D model scripting, Adobe CC scripting and an Entity Framework system will feed 3d dbo models and so forth packaged into the templates to be rendered by the Dbpro viewport and the terrain it presents. From the player's perspective it will all look like a typical game level. From my perspective, I shall build levels, this time, without repetitious mouse clicking and vertex-pushing a million times just to line up a road along the terrain.
I have recently completed my viewport engine performance monitor rather quickly. In my failed attempt I had to spend about 30 minutes trying to figure out what was bottlenecking the performance each time a new impacted an existing feature in a performance degrading manner. I have been thinking about this for quite some time, as garbage collection and poor performance design led to an unmanageable circumstance. It had a rather limited engine performance monitor which only recorded the timespan between 20 or so major functions.
The new performance monitor has ability to check timespans of each and every function, 500 and counting so far, with some functions logically excluded from monitoring. There are event recordings, object detail recordings, recordings for limb counts, polygon counts, collision counts and when all of such occurs; and I get to look at the results in an Excel spreadsheet with graphs when ever I please. There are to be 3 versions of the viewport, at the time of writing. The normal version, the profiler (performance check version), and the one I am about to start writing next week, the debugger version.
The debugger version shall inherit the code base of the profiler performance version I wrote, and simply provide me with a means of checking, logging or editing variables at any point during runtime testing.