Sorry your browser is not supported!

Performance bottlenecks are the bane of developers everywhere, finding ways around them is the hallmark of a capable engineer. I've had a lot of success in my career by pursuing creative and unconventional solutions and wish you the best here.

I'm interested in hearing some more details on your terrain solution. What are you using if not a height map? Modularity is always good, but how is that being applied here? At the end of the day isn't some kind of height data still needed? Good, detailed and efficient terrains are complicated things, I'm super curious how you are approaching this

Edit: page

I hope we get to see some of your progress soon! Are you still going for a cartoon visual style?

I've now used an array of grids and called it a cell container. The terrain can have multiple cell containers for a variety of purposes. Depending on what surrounds cell, or what class of cell it is, the cell is rendered dynamically and then forms a mesh. I can have a mesh applied to flat land and other meshes applied to cliff edges for example.
I plan to add these meshes to a memory cache and file cache when not near the camera.
The main terrain features are not height field based, but there will be applications of height field terrains in use here and there.
I will be able to draw these terrain cells like pixels, but for now I am generating them while I focus more on the artefacts and architecture. I'm taking advantage of the improved hardware of today and using more non-destructive CAD features.

The visual style will feature cartoonish shading to resemble a variety of techniques used in comics. I also plan to use comic panel layouts for much of the user interface. And will reuse the style in future projects in general to make use of my investments in the rendering techniques.

I've been more consistent with my coding sessions over the past year and will soon be able to turn a bunch of lines into buildings, and performance will be more manageable this time. Once that is done I can start animating things, and I am currently looking for a better physics engine DLL.

Update

Currently playing around with geometry drawing functions which will use models to render lines, triangles, circles and grids into buildings and terrain. I have the mouse drawing actions interpreted, but I have got to spend some time working on storage and deployment of the level outlines drawn, 3D models and shaders. I shall also start putting together the user interface controls which resemble comic strips. All in all, I shall be approaching the end of the boring phase of building the framework. After next month I can start working on the fun part (which is what I care about).

Update

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.

Love the performance monitor stat's !

I appreciate that Kevin!

I shall now be very glad to know that whenever a component of the game is leading towards an unmanageable bottleneck, I can see this occurring far in the horizon through such visualisations. So desirable that something similar is being developed this week that provides visualisations of the DBPro variables, needing to be analysed and tested for any potential bugs without the need to recompile the executable.