jMEЗ project

Home Forum Development Engine Development Discussion jMEЗ project

This topic contains 31 replies, has 14 voices, and was last updated by  Kirill Vainer 5 years, 6 months ago.

Viewing 15 posts - 1 through 15 (of 32 total)
  • Author
    Posts
  • #12856

    Kirill Vainer
    563p
    Keymaster

    I started a З.0 branch with my prototype code. It’s still in pre-alpha, only basic features are supported. Have fun.  :)
    http://code.google.com/p/jmonkeyengine/source/browse/#svn/branches/mf_jme3test

    G3D/jMEЗ Version 0.07

    Major feature additions

    • 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.
    #94246
    +1

    llama
    1p
    Member

    Can you rename this branch to something that better represents it's rather experimental nature?

    #94247

    renanse
    2p
    Member

    Why is it called G3D?

    #94248

    nymon
    1p
    Member

    Why is it called З.0?

    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.

    #94249

    Kirill Vainer
    563p
    Keymaster

    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.

    #94250
    +1

    llama
    1p
    Member

    Alright, that name change is good enough for me.

    #94251

    ncomp
    1p
    Member

    i'm really liking this…
    looks alot cleaner and simpler to get objects up and running…
    plus the geometry mesh relationship is very understandable…
    looking forward to seeing where this will lead to….
    also looking forward to what the senior devs will add to this discussion….

    #94252

    keeskist
    0p
    Member

    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.).

    #94253

    nymon
    1p
    Member

    I haven't tried it out yet, but just browsing through the code its looking really nice. I like your material shaders too.

    #94254

    vear
    1p
    Participant

    First impressions:

    OGL matrices supported trough uniforms +
    Moved stuff to LWJGLRenderer +
    Access to uniforms by names -
    Simplified materials +, but no state tracking -
    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.

    #94255

    Kirill Vainer
    563p
    Keymaster

    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  :)

    #94256

    SomethingNew
    6p
    Participant

    So the entire library (including math) is thread-safe?  I really liked how you have enums, it to me makes the code more readable.

    #94257

    Starnick
    1p
    Participant

    Very interesting…tho Im curious on what the G in GЗD stands for too :)

    #94258

    Kirill Vainer
    563p
    Keymaster

    SomethingNew said:

    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.

    #94259

    Lim, YongHoon
    30p
    Participant

    Maybe controversial but good step to jmeЗ. I like it.
    I’m not an expert in jme but 1 and a half year’s experience on jme,
    I feel jme has still a long way to go.
    Of course I praise all the efforts of jme developers and thanks a lot for me to have this wonderful engine.
    But in practice I have many obstacles to overcome when using jme.
    Maybe it is because I don’t understand this engine / OpenGL well,
    But sometime performance / memory handling is not sufficient enough and
    it is too hard to meet the requirements for a commercial game.

    jme2 is now stable and it is good time to have a discussion and implementation of version З.

Viewing 15 posts - 1 through 15 (of 32 total)

You must be logged in to reply to this topic.