Geometry changes - Memory reduction

These changes should not affect those who are not directly manipulating Geometry data. Those using model loaders, terrain, shapes etc, to handle all their geometry will most likely not have to make any changes to their code and they will get a HUGE memory and significant speed increase for free.

For instance, Fly, your game was running around 250-300 MB, I'm willing to be that will drop to around the 150 area, just with the geometry changes alone.

This is just one of the changes on tap. Bounding volumes will be greatly optimized, removing significant memory overhead.

jME will become MUCH leaner.

In case it wasn't clear, that's 10 hours of coding spent mostly on changes to the jme core.  Not indicative of what you'll have to do to migrate.  :)  And yes, we are excited to finally see .9 get close.

This is great news.  Good work Renanse.  This is about the best kind of update we can receive on a project such as this.  I'm it was a pain to do, but now that it's done we can all see the fruit of your labor.  Just wanna say thanks. :slight_smile:


I don't think anyone would disagree at this point in the jME lifecycle that cleaning and optimization of this API is about the most beneficial thing that can be done.

The jME API is quite featureful at this point, and although there are a lot of things we would all like to see, it's fully capable of writing good games with now.  The performance is the best enhancement I think we can have at this point in time.

Have there been any stress tests and/or memory tests done to benchmark between Xith and jME?  I think this would be a beneficial selling point as many people new this arena need some clear cut reasons why to switch, and performance is one of the best reasons we can give, right?



Could you elaborate on what you mean by removing index and normals etc for manual manipulation?

I've got some test code doing soft objects that needs to use these and was just concerned about what I'm in for to rewrok it.

Basically I import a base .obj and construct a new model I can manipulate from this, as it requires calculations similar to some of the springsystem work.



It's pretty simple, basically you would do your magic directly to the indexBuffer of your mesh instead of altering a bunch of Vector2f objects and then requiring an updateIndexBuffer call.

If it sounds daunting, don't fret… it's not.  There is a new helper util class called BufferUtils that makes working in the Buffers very simple.  Also you can look into the changes done in SpringSystem and Cloth to get an idea of how to port easily.

Furthermore, when we release these changes into cvs we'll post on tips and tricks for upgrading your code to the new standard.

Excellent. Thanks for the info.

Keep up the great work.


The changes will be uploaded to CVS tomorrow morning.  We want to make sure we write some very explanitive postings here to help everyone upgrade and there's no time left in the day.  :frowning:

The changes are in.  I'll start a new thread to discuss the changes.

That's awesome!



Heh, last time I promise…  Our numbers our now 1300, 1200 and 1100 respectively.  Boundings are pretty much no cost, in other words.