Using jME for a commercial project

Development
1

Hello Guys!



I'm evaluating jME for use in our upcoming project, and so far it looks pretty solid. However some features are implemented in an unusual way or non-existent. Before implementing them ourselves I'd prefer to get some answers here.


  1. Model format converters actually create scene tree while loading, but then serialize this scene tree, discard it and load it back. These saving/loading steps look highly redundant and unnecessary, is there some specific reason for them? Other then testing jME native model format functionality.


  2. Texture management is ugly. There's practically no nice way of disposing textures other then kill em all. Also no way to async load textures. Setting up texture management will be our priority task, or maybe I miss something here?


  3. Shader object management is worse then texture management. There's no such thing as 'shader object' at all, looks like setting up two nodes with different uniform values will load and compile shaders twice. Do I miss some nice way of doing things here? Say if I need to splat terrain using a couple of different shaders for 10 or so passes?


  4. Would be great to decouple uniforms from shaders altogether. So we can setup uniform values at any scene level and they will all be applied to current shader on geometry rendering. It's nice to control ligths & environment uniforms at the root level, while set up individual material values at Geometry level.


  5. Queue performance tip: in complex scenes with low depth complexity (like strategy or simulation games), it's much more efficient to minimize state changes instead of rendering opaque objects front to back. Can improve frame rates 2-3 times.



    Would be great to get some feedback,

    Best regards

    Grisha
2

hiya,

i can’t answer any of your questions, but i would like to point you to the

jME2.1 design document thread.

There is currently an ongoing discussion of what features should be added / changed in the next jme versions.

3
  1. importing is slow (even without the redundant save/load cycle ;)), thus the common strategy would be to load the native file format in production code after converting it e.g. on build time. Thus jME has format converters not loaders.


  2. I did not investigate on this, but it's very likely that you're correct.

    3+4. see 2. :slight_smile:


  3. right - nobody optimized this usecase yet
4
  1. I agree with the sentiment, however you can delete textures from the card and the cache using TextureManager's deleteTextureFromCard(Texture) and releaseTexture(Texture) methods



    3 & 4. Again, I agree with the sentiment (see my recent history).  Generally I've gotten around #3 by using a Pass object that holds a single shader state and applies it across multiple nodes.


  2. It already does texture state sorting for the opaque queue (generally the most expensive and frequent state switch operation.)  It only falls back to opaque distance comparisons if you render an opaque Spatial that is not a Geometry (which would be a custom stateless object of some kind… so not likely.)
5

Thanks for replies!



I'm toying with replacing textureId with TextureObjects, and collecting them via PhantomReferences for removal from OpenGL. So texture handles will be disposed of in a native Java way. I'll post a patch as soon as it'll be ready.



The problem with 3. is that shader states are not identical: naturally I need different uniform values for different passes.

6

grisha, that's a good idea. Where do you plan on checking the phantom references?



Just make sure you are executing the removal from OpenGL in the OpenGL thread.

7
darkfrog said:

grisha, that's a good idea. Where do you plan on checking the phantom references?

Just make sure you are executing the removal from OpenGL in the OpenGL thread.


hehe, sure! I'm doing it in texture bind/creation, so the whole stuff works from OpenGL thread and is incapsulated in one class. That is: on any texture bind I first destroy non-referenced textures.

This is somewhat temporary decision, while jME doesn't really support multiple render threads/contexts, when it does the phantom rendering queue will go into the context object, so only current context textures get cleaned up.
8

Anything multiplying the FPS two to three times would be helpful. Then I could accomplish my ultimate goal easier.