Roadmap / Issue list

nice work, that gives a good overview of what's planned.



Regarding Issue 67: StandardGame already saves the properties in the registry, so that can be used as a start.

Core-Dump said:

nice work, that gives a good overview of what's planned.

Regarding Issue 67: StandardGame already saves the properties in the registry, so that can be used as a start.


I think my prefs save to the registry if i remember correctly i think it had something to do with

pref = new PreferencesGameSettings(Preferences.userRoot().node(SysInfo.gameTitle));

Yes I know what's supported by jME2  :slight_smile: The thing is, jME3 is written mostly from scratch and so I prefer to avoid using jME2 code. I know how to implement registry and file export myself so it's not really a problem.

Hello!



I have a few questions about jme3:


  1. Are you planning to use a matrix for the Spatial transform or is it going to stick with jme2 way of individual translation, rotation and scale components? (if matrix then we could use it!)


  2. Will it be possible to disable the scene graph and use jme3 as a "flat" JOGL renderer only? (we have our own scene graph and we don't want to switch… even if the new scene graph is MT safe)


  3. about this part of the jme2-jme3 comparison:

    Geometry handling?

    jme3: Geometry is a scene graph element, contains a Mesh object. Meshes contain VertexBuffers which specify # of components, type, float/int buffer. This allows a single mesh to be shared along many scene graph elements.

    jme2: Geometry/TriMesh a scene graph element contains float buffers and int buffers, VBO only supports static models, custom attributes are specified manually via GLSLShaderDataLogic and do not work if VBO is used.



    does this mean shader states in jme3 can be shared while being fed different parameters?


  4. render state inheritance approach of jme2 will be kept? will there be ways of sharing render states?


  5. Math… any chance jme3 will switch to vecmath?


  6. collision, physics, animation, spatial partitioning, shadows etc… how deeply integrated will those systems be into the engine? disable-able swappable?





    Thanks for your time!
1) Are you planning to use a matrix for the Spatial transform or is it going to stick with jme2 way of individual translation, rotation and scale components? (if matrix then we could use it!)

For efficiency's sake there's a 4x4 matrix cached in Geometry so it can be submitted to the renderer faster. It cannot be altered however as it will be overridden anyway on a transform refresh.

2) Will it be possible to disable the scene graph and use jme3 as a "flat" JOGL renderer only? (we have our own scene graph and we don't want to switch... even if the new scene graph is MT safe)

There is a direct method to essentially render geometry, unsuprisingly its the method RenderManager.renderGeometry(). You'll have to take care of frustum culling, sorting, and updating the relevant data by yourself though.

3) about this part of the jme2-jme3 comparison:
Geometry handling?
jme3: Geometry is a scene graph element, contains a Mesh object. Meshes contain VertexBuffers which specify # of components, type, float/int buffer. This allows a single mesh to be shared along many scene graph elements.
jme2: Geometry/TriMesh a scene graph element contains float buffers and int buffers, VBO only supports static models, custom attributes are specified manually via GLSLShaderDataLogic and do not work if VBO is used.

does this mean shader states in jme3 can be shared while being fed different parameters?

Yes.

4) render state inheritance approach of jme2 will be kept? will there be ways of sharing render states?

It's not kept. There's a single class RenderState that contains all the render states. Sharing render states is useless as it gains no efficiency.


5) Math... any chance jme3 will switch to vecmath?

Nope, don't see any reason to do that.

6) collision, physics, animation, spatial partitioning, shadows etc... how deeply integrated will those systems be into the engine? disable-able swappable?

They are in the core but you don't have to use them. The relevant classes simply won't be loaded.


Anyway from what you said it seems to me you're not looking for a game engine or even 3D engine. What is wrong with simply using JOGL or LWJGL directly? Trying to put all your code through an engine will only make the job harder I think.

Hi



it seems the lists do not exist anymore. :frowning:

Eggsworth said:

Hi

it seems the lists do not exist anymore. :(

Its just filtered issue views. There are links on the first page of the wiki on the googlecode page.