Working towards 2.0

Here's some of the current thoughts and directions for 2.0 that have been discussed by Rikard and myself as we work towards making a more robust and performant engine (the two of us have been discussing it a lot lately because well, our current task at work is to make things faster and work better with higher end art effects):

  1. Remove batches:  Mark and I added batches early last year to try to decrease scenegraph overhead.  The thought was that batches would be lightweight sceneelements that did not require calculation for bounds, transforms, etc. and were just mesh data + renderstates.  Well, as you can probably see, batches instead became just carbon copies of the old TriMesh/Line/etc. classes and therefore we actually ended up with a scenegraph that required more overhead.  While we have done a lot to try to decrease that extra (especially for cases where there is only one batch in a Spatial) it still has some overhead in both performance and memory.

  2. Add Effects:  Taking a cue from Eberly's 4.0 version and latest book, we are looking at adding Effects.  These would be similar to PassNode or our various Pass derivative except they will interact strongly with the RenderQueue.  Rikard can elaborate more here as needed.

  3. Remove getType(): we moved from instanceof to getType a while ago because instanceof used to be slower than it is today.  Unfortunately, getType is harder to maintain and extend than simple class inheritance and as it stands right now, it is only possible to have 32 types total.  Now that instanceof is no longer a major time sync (and probably was not a great place for us to try to squeeze performance in the first place) it makes sense to remove this in favor of standard instanceof. (There's only several dozen places to make that change in the jme codebase anyhow.)

  4. Move to enums for publicly set field types:  We have several methods that take int values where we expect the user to provide one of a handful of statically defined values.  Of course, the compiler can't check for correctness here and therefore we end up either trusting the user (which can end up in odd bugs) or doing checks ourselves (which is a needless waste of cpu cycles).  The plan is to move to enums for any non-extensible set of values.  An example of such is the Cull hints (INHERIT, DYNAMIC, ALWAYS, NEVER).  An example of an extensible one that would not be converted to enums is ResourceLocatorTool's resourceTypes or GameTaskQueueManager's queue names (both of which can be added to by the user.)

  5. Move to a three part loop (update, cull, render):  Again, this is a tip of the hat to Eberly's 4.0.  He has separated out the culling mechanism into a set of classes that are run against the scenegraph to create a set of currently visible objects.  The render loop works against that set of objects.  We actually do this with our RenderQueue system, but it is not very extensible.  Having it stand alone outside the draw loop will allow for things like portal culling, bsp culling, predetermined occlusion culling, etc. to be dropped into a scenegraph without adding a lot of custom scenegraph objects.

    Just to clarify, we are only at the initial stages of this work, so there's plenty of time to throw in thoughts.  Even once this work is all complete, we still have a lot of work to go on 2.0 for things like thread safety, immutable objects, etc.  Also, if we can possibly avoid large changes until the above work is done, merges will be a lot easier…

fwiw: sounds very good to me :slight_smile:

Me likey.  :stuck_out_tongue: