Feature "requests" (4 posts)

  • Profile picture of bdieterich bdieterich said 2 years, 8 months ago:

    Hi there,
    I'm kind of new to 3D graphics in general and JME in special (just playing around a bit with JME2.0). However I always found the topic fascinating and even if this is my first post in this forum, I have been an interested reader for months.

    I have some feature "requests" for JME3.0 (propositions, that is), is this the right place to post them?
    Mainly, it's stuff I read in "GPU gems" :-)

    1. z-only-Pass
    First rendering only the z-Buffer with all material (= shaders) turned off and then doing a second pass with material is supposed to save a lot of shader time because the fragment shader runs only for actually visible pixels. This will be especially true for scenes with 1. GPU-intensive shaders and 2. high depth complexity.
    Having a property to turn this behaviour just on/off in the engine would be nice.

    2. Hardware occlusion culling
    Another one from "GPU gems". Support for this ARB_… feature could be automatically detected by the engine and hardware culling be used to reduce the overdraw in scenes with high depth complexity.

    3. Automated striping of meshes
    I'm unaware of as to which degree JME already supports this one: I understand that rendering TRIANGLE_STRIPEs is much more efficient than rendering lists of fully qualified triangles. If a mesh doesn't provide striping information, this information should be automatically deduced (e.g. at load time) and the mesh subsequently be rendered as stripes.

    #
  • Profile picture of Momoko_Fan Momoko_Fan366p said 2 years, 8 months ago:

    I also read GPU gems  :-) I know about these features and considered all of them at some point for jME3, but not all of them fit with jME3's design.
    1) Z-only pass: I tried doing this, its very easy, but it doesn't always improve performance (you stress video card to reduce its stress). It's more preferable to generate PVS (potentially visible set) for the scene so that overdraw is reduced. This can be done with octree and other scene partitioning techniques. Since z-only pass is easy, I might make it available as an option.

    2) occlusion culling: its a good feature (can be used to generate PVS), but not so good for real time. It requires too much work from the user. You need to have a low-res offscreen buffer, you need to define "occluders" and "occluded objects" in the scene which will be tested. This doesn't fit with jME3, which needs to be user-friendly.

    3) Triangle strips: although jME3 supports rendering triangle strips, its unpreferable to use them as triangle lists are usually better. The main reason is that triangle strips require you to "restart" the gpu to render each strip. You can find more info in this thread: http://www.ogre3d.org/forums/viewtopic.php?f=5&t=9025

    #
  • Profile picture of abies abies34p said 1 year, 5 months ago:

    Re: Triangle strips

    As far as I remember from old times, trick for triangle strips was to connect separate strips with degenerate triangles – this way you could avoid resetting batches.

    Things might have changed over last 6 years, but please take a look here

    http://jmonkeyengine.org/groups/user-code-projects/forum/topic/stripifier/

    Back then, using separate triangles was the worst option, with continous or chunked strips being generally the best, depending on the complexity. Chunked strip in this case means number of triangle strips, restarting for each batch, continous was connecting batches with degenerate triangles.

    From what I have seen, some form of Stripifier code has survived in jme3 code, so somebody could give it a try on contemporary graphic card…

    P.S.
    Just noticed the timestamp on the thread, sorry for resurrecting this…

    #
  • Profile picture of Momoko_Fan Momoko_Fan366p said 1 year, 5 months ago:

    The reason I left stripifier in jME3 is for Android. There’s no other use for it anymore.
    Modern GPUs will usually operate slower on strips than triangle lists.

    #