Data driven materials with dynamically linked shaders
Content Management System that allows loading and locating of content/game data. Supports multithreaded loading and plugins
Input System that supports Keyboard, Mouse and Joystick under one easy API. Much easier and less convoluted than the original jME input system.
FlyByCamera class that uses new input system, included with SimpleApplication
Added DDS, HDR and TGA texture loading
Basic render Queue added with front-to-back sorting
Tested Linux and Windows 64 bit support
Half float data is supported for both textures and vertex buffers, reducing bandwidth needed to upload HDR images and small meshes.
Native libraries are now included seperately in a JAR file, can disable their copying using system property jnlp.g3d.nonativecopy, to allow WebStart deployment
Minor feature additions and fixes
More classes ported to use TempVars, mainly in math and bounding package
Matrix3f class now supports column major filling of FloatBuffer just like Matrix4f
Applied fix to Matrix4f.transposeLocal() from contrib forum to make it faster and create less garbage
Small fix added to Camera class to adjust the aspect ratio to match new resolution on resize
Camera class can now write direction/left/up vectors into provided storage vectors to reduce garbage
GLObjectManager class is no longer static. Each renderer has its own GLObjectManager with which it interfaces
Improved handling of vertex attributes and texture units, uses a specilized algorithm to reduce state changes
Added support for Vertex Array Objects in supporting video cards, reducing GL calls required for rendering a mesh.
Predefined renderer uniforms now integrated with material system
Geometry world transform automatically cached as Matrix4f on change
Shader uniforms will only be sent if their value has changed
Shader attribute locations are cached in the shader, will only have to lookup name once per shader
Removed shader validation, engine should no longer crash on ATI cards
DisplaySettings are now deeply copied into context, allows changes to settings without effecting context.
All GL objects are properly destroyed when the context is destroyed
Context class can now properly resize camera on context restart
G3D/jMEЗ version 0.05
Texture Y-flipping is no longer needed. Importers must conform to the GL specification of texture coordinates rather than the DX specification, therefore flipping of texture coordinates may be requried in the importer.
Thread-safety - No internal class is allowed to use static variables for storing temporary data. Instead the TempVars class should be used for storage. TempVars class stores temporary variables
No more "no lwjgl in java.library.path" errors. jMEЗ stores the natives inside the JAR file and extracts them when needed.
Simpler log formatter
Image memory requirement removed as it is not really accurate
Texture apply modes and combiners have been removed in favor of shaders
Better heightmap handling
Rendering context class added for more OOP and multi-canvas rendering.
Shaders are now first-class objects that must be used for rendering anything, this is done through the new Material system.
Better seperation between scene graph and geometry data, the scene graph node that represents a renderable 3D object is the Geometry class, while the data is the Mesh class. The mesh can be shared by many geometries inside the scene graph without data duplication.
All GL objects allocated will be properly disposed of from both the CPU and GPU when no longer used, thus preventing memory leaks. This is done through the new GLObject and GLObjectManager classes.
Scene graph updating is now much faster and user-friendly. Calling updateGeometricState() is no longer needed within user code. Changes to the scene graph are efficently tracked and applied when needed.
Camera changes are also automatically applied. Camera is now a renderer-independent class, completely thread-safe and free of GL calls.
Lighting is now controlled directly in the scene graph.
BaseGame/SimpleGame is now Application/SimpleApplication. Time per frame value is available on all application types.
I have no problem with adding branches and prototyping changes and new features, but unless I missed the discussion, I think its rather distasteful to assume that it will be adopted by the community as a whole to be the ‘next’ jME. Please, no offense.
Mind changing the name one more time to something more indicative of what it is?
Do you have a list of what is different so we know what to try out? I’m excited to see some work towards the future.
Can you rename this branch to something that better represents it's rather experimental nature?
Okay, I changed the name from З.0 to mf_jme3test. I would say that at this point it has gotten out of an experimental phase into something more like "alpha".
Do you have a list of what is different so we know what to try out? I'm excited to see some work towards the future.
Its not really based on jME, as in, the code has not been copied over and modified, rather some parts were created from scratch with other parts adopted from the existing jME2.
I hope this doesn't become a dispute over naming and where the code is, etc. I would appreciate some comments on the actual code.
So if I understand correctly this branch represents Momoko_Fan’s view on what JME З should look like, and is not the ‘official’ JM E З branch? If so, would it be possible to have any form of documentation about what has changed? I looked through the source, but from what I’ve seen it changes almost all core concepts of JME (DisplaySystem, AbstractGame, etc.).
Clearer geometry support ++, but no packed geometry, so as much overhead as previously (number of buffers = number meshes * number of attributes) -
No mapped VBO support from load to render -
The Material classes know to do one thing, there isn't a system to combine the features of different materials
Why is the list of children in Node a synchronizedList? How will that support concurrency?
As yourself said, no pass system.
Calculate an int ID for each Spatial in each queue, and use that ID for comparison instead of evaluating the comparison each time two Spatials are compared in the queue. Makes queue sorting faster, and that makes the use of queues more viable for different things.
No possibility for Materials to behave differently when used in different passes. For example a depth-only pass needs only a simplified version of the shader, and there could be different behaviors of the same Material when rendered with different ligths, or trough deferred lighting.
I still don't understand, why are you avoiding to use ideas/solutions/code from the VL engine? Anyway, good to see that there is progress.
Access to uniforms by names - Do you mean that uniform buffers should be supported? With OpenGL2, there's no other way to access uniforms but by name.
No state tracking - Actually there's quite a lot of state tracking, it's in the RenderContext class (just like in previous versions of jME).
No packed geometry - This is something that I planned to do but I didn't get to yet. If you want you can write that part yourself since you seem to understand it much better than me.
No mapped VBO support - Is there a way of properly adding support for them? I mean, obviously you can't use float buffers on the CPU so the user must write directly to the mapped VBO, how would that work?
No system to combine the features of different materials - Yeah, I realized this a bit after I finished the system. A data-driven material system is really the way to go with any next-gen engine.
List of children in Node a synchronizedList - This part I mostly copied from the original Node class. I think it's there to prevent exceptions when the scene graph is modified from another thread. I guess if we want to seriously support concurrency then we really wouldn't allow users modifying the scene graph while it is being rendered. I was thinking of the scene graph being "flattened" when it is added to the render queue, there you could use whatever methods you wish and as long as geometry data is not modified during rendering it would work fine.
Calculate an int ID for each Spatial in each queue […] - I don't really understand this part, but the render queue is not made yet so if you want you can try implementing your system.
Materials to behave differently when used in different passes. […] - Yeah, when we'll have "shader libraries" doing this sort of thing would be much easier. A single shader would consist of a few lines, all of them function calls This makes it both easier to understand and modify to support all sorts of flexible rendering.
I still don't understand, why are you avoiding to use ideas/solutions/code from the VL engine? Anyway, good to see that there is progress.
Actually I am not avoiding using ideas, there's actually quite a lot of ideas, many of them were from users of jME that voiced their complaints on the forums. I haven't taken a look at VL engine for quite a while but it's possible I used some ideas from there.
By the way, I added a change list in the first post (still incomplete).
Its good to see that people care :)
So the entire library (including math) is thread-safe? I really liked how you have enums, it to me makes the code more readable.
Some parts are still not entirely thread-safe. For example, some bounding volume classes have been ported to use the TempVars class while others were not. Though the end objective is to achieve complete thread-safety within all code.
Having SynchronizedList for Node children is not completely clear to me...
If this is done to overcome the problems caused by node controllers removing or adding child-nodes, I think this should be done externally (node controllers should not be run during the update() call on the scene graph, but externally on some controller manager).
If this is done to allow for a multithreaded model, I think the overhead is too high and doesn't really solve concurrency on the scene graph (children lists will be correct but a the scenegraph could still be broken at a particular moment in time).
Anyway, nice work and nice ideas there.
On the other hand, JME2 is still not stable and we need to know where to stop with JME2. Should we stop adding major features and stick to bug resolution, documentation, etc...?
On the other hand, JME2 is still not stable and we need to know where to stop with JME2. Should we stop adding major features and stick to bug resolution, documentation, etc...?
jME2 is probably more stable than jME1 at this point thanks to all the patches and fixes that users submitted. Also I have not seen anyone add "major features" except renanse when he released the pre-alpha version so we have already stopped adding major features at this point. IMHO attempting to add more features to jME2 will only make it more complicated at this point. Most complaints on the forum are regarding various quirks in the core which this project aims to fix. ;)
in the shaders the qualifier "in" throws up a compile error here...
Actually I expected this to happen. The original shaders were made for OpenGL3/GLSL1.3 and then ported to GL2, but for some reason the nvidia compiler doesn't complain about the in keyword being used with GLSL1.2.
since you seem to understand it much better than me.