Support for geometry and tesselation shaders (diff)

Well we will move to git some time soon when the gradle build is done but we still won’t let this become jME2 again. The general issue won’t go away though, people will leave some code that is made for an old version of the engine somewhere.

Can’t we just add this to shaderblow like all the other shader goodies? @mifth what do you think? :wink:

@erlend_sh said: Can't we just add this to shaderblow like all the other shader goodies? @mifth what do you think? ;)

As far as I know it needs 2-3 smaller change to the default rendering stuff, mostly additional types for some enums. At least it was necessary back then, so that part would need to be in the core, the rest can of course stay an external part.

@erlend_sh said: Can't we just add this to shaderblow like all the other shader goodies? @mifth what do you think? ;)

I think it should go to JME core. But ShaderBlow is always open in contributions repo.

It needs to be integrated to shaderNodes too.
That’s already on my todo guys

1 Like

Never used shaderNodes so i can’t say anything about them.
If you are on the way to add support for the new shaders you could also add compute shaders… :wink:

1 Like

Compute shaders aren’t necessarily going to be useful unless it was used to extend bullet.
Edit: Or actually, you could offload line-of-sight culling to a compute shader, would possibly speed things up.

@fabsterpal said: Compute shaders aren't necessarily going to be useful unless it was used to extend bullet. Edit: Or actually, you could offload line-of-sight culling to a compute shader, would possibly speed things up.

GPU Particles
Tiled Deferred Lighting
Physics
Raytracing
Procedural generation
Texture modifications

Just to name a few.

I would actually say that the compute shaders are going to be the biggest speed increasers in the latest time…

1 Like
@zzuegg said: GPU Particles Tiled Deferred Lighting Physics Raytracing Procedural generation Texture modifications

Just to name a few.

I would actually say that the compute shaders are going to be the biggest speed increasers in the latest time…

… Fair enough.

1 Like

Why compute shaders? I don’t get the benfit from it vs opencl wich is already usable due to lwjgl from inside jme.

1 Like
@Empire Phoenix said: Why compute shaders? I don't get the benfit from it vs opencl wich is already usable due to lwjgl from inside jme.

Well one major benefit is that compute shaders would be written in GLSL which cuts down on the learning curve for many…Compute shaders would be easier to integrate into an already existing application especially in terms of textures…using openCL with jMonkey to create textures is a pain as you have to write into a buffered image or a floatbuffer and then use that to create a texture.

Adding compute shaders would be incredible…in my opinion

Yeah but if you’re making a game for the general public, chances are not many ppl have opengl 4.3 support, or they have but lack the drivers

I have more faith in this: Main - Main - OpenJDK Wiki

Tested out rootbear compiler for cuda, and it works, pretty well in fact.

@okelly4408 said: Well one major benefit is that compute shaders would be written in GLSL which cuts down on the learning curve for many...Compute shaders would be easier to integrate into an already existing application especially in terms of textures...using openCL with jMonkey to create textures is a pain as you have to write into a buffered image or a floatbuffer and then use that to create a texture.

Adding compute shaders would be incredible…in my opinion

Well ok I see your point,
however you can directly share from opencl to opengl without going over the cpu.

Weiterleitungshinweis

I updated the Patch to the current git Version of jMonkey:

https://github.com/Perjin/jmonkeyengine/tree/openGL4

The last two commit contain the code changes and a test case.

Code:

Test case:

5 Likes

Nice thx for moving this to the repo…

I m reviving this topic to keep track of something important.

I ve tryed to make a Tesselation Shader and sucessed but the GeometryBatchFactory crash since it as no support for Mesh.Mode.Patch and The same crash happen with Ray Collision getting a UnsupportedOperationException();

Is there any other way to do Ray Collision? Or do i need to write my own Ray and Batching class?

public WrappedIndexBuffer(Mesh mesh){
    super(mesh.getVertexCount(), mesh.getMode());
    this.ib = mesh.getIndexBuffer();
    switch (meshMode){
        case Points:
            numIndices = mesh.getTriangleCount();
            break;
        case Lines:
        case LineLoop:
        case LineStrip:
            numIndices = mesh.getTriangleCount() * 2;
            break;
        case Triangles:
        case TriangleStrip:
        case TriangleFan:
            numIndices = mesh.getTriangleCount() * 3;
            break;
        default:
            throw new UnsupportedOperationException(); 
    }
}
1 Like

Well I guess it’s never been implemented. Could you make a simple test case? that would help.

I will try, this is the basic code that crash
Do you need a Tesselation Shader? I will need to make a new one and also the code is awful :frowning: You could use the one in the TestCase in the SDK It come with a Basic Tesselation. That should reproduce the problem.
Edit: I tested the same thing with the Jme3test in the material folder and it does the same thing, So i think you should probably use that one and add a Node and A Batch.

Edit2: Just to make sure i made an edit and added a Comment where i think the Flag is set for the crash, But the crash happen later when you Try to collide with the Geometry using Ray casting and/or Batching it since the Buffer isn’t supported? (I didn’t read all the code)

    tessellationMaterial = new Material(getAssetManager(), "MatDefs/Tesselation/Tesselation.j3md");
    tessellationMaterial.setInt("TessellationFactor", tessFactor);
    tessellationMaterial.setFloat("DisplaceFactor", 0.2f);
    tessellationMaterial.setBoolean("Corner", false);
    tessellationMaterial.getAdditionalRenderState().setWireframe(true);


    Texture diffuse = assetManager.loadTexture("Textures/Road/diffuse.png");
    //Texture normal = assetManager.loadTexture("Textures/Road/normal.png");
    Texture height = assetManager.loadTexture("Textures/Road/height.png");
    
    tessellationMaterial.setTexture("DiffuseMap", diffuse);
    //tessellationMaterial.setTexture("NormalMap", normal);
    tessellationMaterial.setTexture("NormalDisplacementMap", height);

    Quad quad = new Quad(10, 10);
    quad.clearBuffer(VertexBuffer.Type.Index);
    //Crashing part
    quad.setBuffer(VertexBuffer.Type.Index, 4, BufferUtils.createIntBuffer(0, 1, 2, 3, 4));
    quad.setMode(Mesh.Mode.Patch);
    quad.setPatchVertexCount(4);

    Vector2f[] texCoord = new Vector2f[4];
    texCoord[0] = new Vector2f(0, 0);
    texCoord[1] = new Vector2f(1f, 0);
    texCoord[2] = new Vector2f(0, 1f);
    texCoord[3] = new Vector2f(1f, 1f);

    quad.clearBuffer(Type.TexCoord);
    quad.setBuffer(Type.TexCoord, 2, BufferUtils.createFloatBuffer(texCoord));

    Geometry geometry = new Geometry("tessTest", quad);
    geometry.setMaterial(tessellationMaterial);
    geometry.rotate(-90 * FastMath.DEG_TO_RAD, 0, 0);
    Node batch = new Node("Batch");

    for (int i = 0; i < 10; i++) {
        for (int j = 0; j < 10; j++) {
            Geometry instance = geometry.clone();
            instance.setMaterial(tessellationMaterial);
            instance.setLocalTranslation(i * 10 - 50, 0, j * 10 - 50);
            batch.attachChild(instance);
        }
    }
    GeometryBatchFactory.optimize(batch);
    
    Geometry geo =(Geometry) batch.getChild(0);
    
    rootNode.attachChild(batch);
1 Like

Thanks, I will try this

Thank you for helping out. I will turn off my tesselation until you get this fix. If you need help just ask!

1 Like