In almost every flash 3d-engines I know graphics is re-calculated constantly — even in nothing is changed on a scene. Taking “do not calc same things twise” optimizing principle into account, we were thinking how to calculate only changed things.

At first we managed to use flags system. For example, when setting new coords for object, we set its flag coordsChanged = true. Then, thru the different checks, visualisator decided to only move this object, without re-drawing its graphics. So this system made up its way to version 4 and thanks to it we have good performance in a demo.

Then, along with engine development, this came to a very complicated flags dependencies. We got excess check-ups somewhere, and flag cleaning task become difficult too — there are a lot of materials, points, edges, even composite (like lists) flags. So finally we got a non-transparent system with additional processor load due to constant flag checking and cleaning (30-40% without changes on a mid-complicated scene with shadows).

That lead us to review engine architecture. At the moment we created and testing new changes system — signals system.

(more…)

After launching demo all engine disadvantages came up. Processor loading is not distributed well — say, we had 30-40% without any changes to scene, which in not a Good Thing. Also we had some too complicated optimization methods.

First of all (with thanks to your feedback) we decided to code perspective correction and to re-write “honest” Z-sorting with some new optimization tricks.

After all we managed to create new, 5th version of engine which will have different architecture (not changed since 2.0). It will suppurt multiply cameras, perspective, Z-sorting using BSP-trees. “Changes listeners system” is already implemented.

And sure, we’re also making engine-server integration.