So instead of trying to compile opengl shaders to vulkan we compile vulkan shaders to opengl?

Something like

BIND (location=....) in vec2 texCoord;

that is transformed to

layout(location=...) in vec2 texCoord;

for vulkan
and

in vec2 texCoord;

for opengl

I personally do not see the current design very practical, also in terms of what happens if you are on ring 20? Are you required to pan around to get to the actual nodes. From a design point of view i like the current implementation however

But hard to say and largely opinion based topic.

Add: the displacement wave effect is superb

I like the idea of the seconds added, but will have to think if this will fit in the vision of the game.

I do have a question on the upgrade tree for you:

Currently the upgrade tree is kind of open to buy anything of you have the money. This is an open upgrade tree.

So my question is, do you think a more closed/linear type upgrade tree would work beter for gameplay? Like the upgrade trees we get in these other incremental games?

Or something that i have the feeling that staying alive longer is beneficial instead of making more runs.

But only my impression, the whole game itself feels very polished. Good work

Don’t really know what i would do. Maybe a info panel that states clearly the amount of time you have and other info?

Also, I see a lot of people give feedback about the game loop and timer and short battles.

So just to clear up something, this is an incremental game and does not have a lose state.

It is all about upgrading your ship to feel more powerful in a battle run.

For uniform style variables you have push constants in vulcan. If its a good idea to use it is a different topic, but you can.

https://docs.vulkan.org/guide/latest/push_constants.html

Note, i am referring to this attempt. Last time i checked codex’s approach i got the impression that it was ment to create a implementation that makes use of the enforced ways vulcan wants to render.

adi.barda:

Maybe I can help with that. I have some experience with ANTLR4 and can try write the transpiler. problem is that I’m not familiar with GLSL so there will be a learning curve. Question is whether it’s the right direction to solve the problem?

I’m not sure. I’m also learning and writing code at the same time. I can’t guarantee that this is correct.

When I have completed the development of the function to a certain extent, I will contribute the code to the community. However, currently the code is still rather rudimentary and the functions are not yet fully developed.

The screenshot looks like a bug with reading the property in the properties file. It is used for multi language support.

What do you mean by this? Because there is a lock and plus icon in the top right corner:

icyboxs:

This misalignment requires moving beyond “text substitution” to “semantic-level adaptation.

If I understand you correctly we need a real transpiler to convert from JME GLSL to Vulvan’s GLSL.
Maybe I can help with that. I have some experience with ANTLR4 and can try write the transpiler. problem is that I’m not familiar with GLSL so there will be a learning curve. Question is whether it’s the right direction to solve the problem?

In GLRenderer(jME’s OpenGL renderer):

• Renderer.setShader(shader)ensures the program is linked.

• Each Uniforminternally holds a uniform location (the result of glGetUniformLocation, or UBO block/offset information).

• uniform.setValue()ultimately calls glUniform*or writes to a UBO (depending on the implementation).

You do not need to know the offset / std140 alignment / stride, because:

• If using glUniform*: The driver finds the location and writes the value.

• If using UBOs: OpenGL also provides APIs to query offsets (glGetActiveUniformsiv(..., GL_UNIFORM_OFFSET, ...)), meaning the driver calculates and provides it for you.

Therefore, in OpenGL, “reflection” mainly manifests as location queries, not as you calculating the layout yourself.

What’s missing in Vulkan

Vulkan has no glUniform*. You can only:

1. Place all uniforms into a UBO/SSBO.

2. Write a block of memory yourself.

3. Have the shader read from that memory by offset.

Consequently, you must know:

• What is the offset of m_Color?

• What is the offset of g_WorldViewProjectionMatrix?

• What is the stride for a mat3?

This information must come from either SPIR-V reflection or your own layout rules.

This is also a function that needs to be completed at present.

icyboxs:

Currently, jMonkeyEngine’s shaders are filled with macro commands that prevent Vulkan from compiling properly

It would be interesting to unpack this statement.

JME uses macro commands as a compatibility layer… which presumably can be leveraged even for vulkan. At least, it seemed like many of the errors in your original shader compiler failure could have been worked around with a new set of vulkan-compatible macros.

Caveat: I don’t really know much about vulkan specifics.

Vulkan requires “explicit layout/binding”, whereas most jME GLSL relies on implicit conventions.
Vulkan GLSL/SPIR-V typically requires:
layout(location=…) in/out
layout(set=…, binding=…) uniform …
Fragment shader output: layout(location=0) out vec4 …(cannot rely on gl_FragColor)
However, jME’s shader generation, for compatibility with older GLSL, commonly uses:
attribute/varying(legacy syntax)
gl_FragColor
uniform sampler2D m_ColorMap;(without layout qualifiers)
Many #ifdefmacro branches that determine whether variables are declared or used.
Therefore, you must “guess” and inject layout qualifiers. Without structured parsing at this stage, it’s prone to issues like:
Duplicate injection
Incorrect injection order
Mismatch between locationand the actual mesh buffer
Compilation failures due to declaration/usage inconsistencies within macro branches.

OpenGL provides a “driver-managed parameter submission interface” (glUniform, state machine, texture units). The application only needs to set values by name/location, without needing to know the memory layout or binding tables.

Vulkan makes all these implicit mechanisms explicit: the application must create layouts, write buffers, bind descriptors, and must know the shader interface ABI. Therefore, reflection becomes a necessary tool.

Currently, we are considering modifying the Material in jme-core and establishing a new mapping for Vulkan.

Of course, I’m still learning to see if there are any better ways.

-I would like to have a visual clue of the upgrade i can buy. currently i have to hover over all slots to see which i can afford.
-Initially i tough i missed something or there is a bug because of the short game time.
-It feels strange that you have to go to the upgrade menu to be able to go to the main menu.

There is a property called distributionUrl and the url gives the version of the gradle. What version do you have? Perhaps editing it to a lower version (i.e. 7.6.6, or 8.14.4) and reload the build may help

icyboxs:

From the current perspective, the best approach seems to be using regular expressions to replace parts of the GLSL code. However, this would require writing multi-layer nested content, which could make future maintenance difficult

Can you explain this statement more? what exactly do you want to achieve? give an example if you can for something that would be hard to achieve with the regex you mentioned

Some parts are still quite raw opengl, but thats how it is at the moment.

in case anyone is interested in playing with the features: GitHub - zzuegg/jmonkeyengine: A complete 3D game development suite written purely in Java. · GitHub

Compute Shaders:

  // Create output texture and upload to GPU
  Texture2D tex = new Texture2D(new Image(Image.Format.RGBA8, 256, 256, data, null, ColorSpace.Linear));

  // Dispatch compute via Material
  Material compute = new Material(assetManager, "Common/MatDefs/Compute/MyCompute.j3md");
  compute.setInt("Width", 256);
  compute.setImage("OutputImage", tex, TextureImage.Access.WriteOnly);
  compute.dispatch("TechniqueName", renderManager, 16, 16, 1);

  renderer.memoryBarrier(GL4.GL_ALL_BARRIER_BITS);

  // Use result as a regular texture
  displayMat.setTexture("ColorMap", tex);

Bindless Textures:

//Enabling Bindless support 
AppSettings.setBindlessTextures(true);


  // 2. Load textures and force GPU upload to create handles
  Texture2D[] textures = new Texture2D[4];
  for (int i = 0; i < textures.length; i++) {
      textures[i] = (Texture2D) assetManager.loadTexture(paths[i]);
      renderer.preloadTexture(textures[i]);
  }

  // 3. Write 64-bit handles into an SSBO
  BufferObject ssbo = new BufferObject();
  ssbo.initializeEmpty(textures.length * 8);  // 8 bytes per handle (long)
  ByteBuffer buf = ssbo.getData();
  for (Texture2D tex : textures) {
      buf.putLong(tex.getImage().getBindlessHandle());
  }
  buf.rewind();


  // 4. Bind SSBO to material
  Material mat = new Material(assetManager, "MyBindlessMaterial.j3md");
  mat.setShaderStorageBufferObject("TextureHandles", ssbo);

 // 5. Then in the fragment shader (GLSL):
  layout(std430, binding = 0) buffer TextureHandles {
      sampler2D texHandles[];
  };

  in vec2 texCoord;
  flat in int instanceId;
  out vec4 fragColor;

  void main() {
      fragColor = texture(texHandles[instanceId], texCoord);
  }

//The required extension is automatically added to the shader if bindless is enabled and supported
#extension GL_ARB_bindless_texture : require

I am still working on how to create a nicer to use api for drawindirect, but you can look at the screenshot tests to see it in action. The key classes are:

IndirectCommandBuffer
MeshCombiner
renderManager.renderGeometryIndirect(geom, cmdBuf);

I will remove now.

Did you mean to include email address as a required field in the feedback form? It might discourage people from filling in the feedback form

If those green start buttons aren’t there are there any warnings (like “SDK not set up”).

What happens when you try to build, any errors?

Hope you are all well. For the past few weeks I have been working on what I hope to be my very first Steam game. I’ve got the game at a level where I want to share it with people to play test and validate.

This is where I need your help, I need some play testing of the game.

Currently it is available on itch.io at the following location:

There is a feedback button on the main menu, when done playing, please quickly complete the form, it would make this game what I want it to be.

Thanks in advance.

Did you create your project with the initializer or created a gradle project in intelliJ and added the dependencies?

Please paste of the error messages you are getting when you try to run the project. I use IntelliJ as well but I make my gradle project without the initializer and I may be able to help.

package com.jme3.lwjgl.test;

import com.jme3.app.FlyCamAppState;
import com.jme3.app.LegacyApplication;
import com.jme3.asset.plugins.ClasspathLocator;
import com.jme3.input.FlyByCamera;
import com.jme3.input.RawInputListener;
import com.jme3.input.event.JoyAxisEvent;
import com.jme3.input.event.JoyButtonEvent;
import com.jme3.input.event.KeyInputEvent;
import com.jme3.input.event.MouseButtonEvent;
import com.jme3.input.event.MouseMotionEvent;
import com.jme3.input.event.TouchEvent;
import com.jme3.material.Material;
import com.jme3.material.plugins.J3MLoader;
import com.jme3.math.ColorRGBA;
import com.jme3.math.Vector3f;
import com.jme3.renderer.Camera;
import com.jme3.renderer.ViewPort;

import com.jme3.scene.Geometry;
import com.jme3.scene.Node;
import com.jme3.scene.shape.Box;
import com.jme3.scene.shape.Quad;
import com.jme3.system.AppSettings;
import com.jme3.system.JmeSystem;
import com.jme3.system.VulkanSystemDelegate;

public class VulkanMaterialUnshadedApp extends LegacyApplication {

    private Node rootNode = new Node("Root");
    private ViewPort viewPort;
    private Camera cam;

    private FlyCamAppState flyCamState;
    private boolean flyConfigured = false;

    @Override
    public void initialize() {
        super.initialize();
        assetManager.registerLocator("/", ClasspathLocator.class);
        assetManager.registerLoader(J3MLoader.class, "j3md", "j3m");

        cam = getCamera();
        viewPort = renderManager.createMainView("Main", cam);
        viewPort.attachScene(rootNode);

        Quad q = new Quad(1f, 1f);
        Geometry g = new Geometry("quad", q);

        Material m = new Material(assetManager, "Common/MatDefs/Misc/Unshaded.j3md");
        m.setColor("Color", ColorRGBA.White);
        g.setMaterial(m);
        rootNode.attachChild(g);

        cam.setLocation(new Vector3f(0, 0, 10f));
        cam.lookAt(Vector3f.ZERO, Vector3f.UNIT_Y);
        cam.setFrustumPerspective(45f, (float) cam.getWidth() / cam.getHeight(), 0.1f, 100f);

        flyCamState = new FlyCamAppState();
        flyCamState.initialize(stateManager, this);
        stateManager.attach(flyCamState);

        // 不要在这里立刻 getCamera() 配置
        // 验证输入对象是否为 GLFW 真实实现
        inputManager.addRawInputListener(new RawInputListener() {
            @Override
            public void beginInput() {
            }

            @Override
            public void endInput() {
            }

            @Override
            public void onKeyEvent(KeyInputEvent evt) {
                if (evt.isPressed()) {
                    System.out.println("KEY pressed: " + evt.getKeyCode());
                }
            }

            @Override
            public void onMouseMotionEvent(MouseMotionEvent evt) {
            }

            @Override
            public void onMouseButtonEvent(MouseButtonEvent evt) {
            }

            @Override
            public void onJoyAxisEvent(JoyAxisEvent evt) {
            }

            @Override
            public void onJoyButtonEvent(JoyButtonEvent evt) {
            }

            @Override
            public void onTouchEvent(TouchEvent evt) {
            }
        });
//        FlyByCamera flyCam = flyCamState.getCamera();
//        flyCam.setMoveSpeed(5f);
//        flyCam.setDragToRotate(false);
//        flyCam.registerWithInput(inputManager);
        
    }

    @Override
    public void update() {
        super.update();

        float tpf = timer.getTimePerFrame();



        // 3) scene 更新 + 渲染
        rootNode.updateLogicalState(tpf);
        rootNode.updateGeometricState();

        if (context != null && context.isRenderable()) {
            renderManager.render(tpf, true);
        }
    }

    public static void main(String[] args) {
        JmeSystem.setSystemDelegate(new VulkanSystemDelegate());

        AppSettings s = new AppSettings(true);
        s.setCustomRenderer(com.jme3.renderer.vulkan.LwjglVulkanContext.class);
        s.setWidth(1280);
        s.setHeight(720);

        VulkanMaterialUnshadedApp app = new VulkanMaterialUnshadedApp();
        app.setSettings(s);
        app.start();
    }
}

The current issue is how to handle the shaders. I might need to go to the library as I haven’t found any information about OpenGL compatibility with Vulkan on the internet. If anyone else has any findings, please let me know.

He added this fix to the main Swing app:
```

public static void main(String[] args) {

    // Fix HiDPI gap in JME3/LWJGL2 canvas: Java 9+ declares the process
    // as DPI-aware, so the GL framebuffer is at physical pixel resolution
    // but Canvas.getWidth()/getHeight() report logical pixels.  This causes
    // glViewport to cover only (1/scale) of the framebuffer, leaving gaps
    // on the right and bottom edges.  Disabling Java's DPI scaling makes
    // logical == physical so the viewport fills the entire framebuffer.
    System.setProperty("sun.java2d.uiScale", "1");

    // Compensate by letting FlatLaf scale the Swing UI independently.
    // Toolkit.getScreenResolution() returns the OS DPI (e.g. 120 for 125%)
    // via the native GetDeviceCaps API, unaffected by sun.java2d.uiScale.
    try {
        int dpi = Toolkit.getDefaultToolkit().getScreenResolution();
        float scale = dpi / 96f;
        if (scale > 1f) {
            System.setProperty("flatlaf.uiScale", String.valueOf(scale));
        }
    } catch (Exception ignored) {
    }
``` 

This made my revisions extremely difficult.

My current idea is to perform the check at the front end rather than at the Vulkan backend.

That is to say: Before the Shader is handed over to the Renderer, you have already obtained the source and defines for each stage.

At this point, pure string patches (such as replacing macro guards, correcting attributes/varyings, inserting layouts, etc.) can be performed.
Static checks can also be conducted (such as balancing #if/#endif, checking for bare uniforms, and verifying if there are duplicate locations, etc.)

Of course, this is just a theory.

My current thinking is to try to avoid modifying the current OpenGL as much as possible.

I plan to complete the minimal modifications first.

Here is the initialization code for reference:
```

private void initJME3() {
    app = new DesignerApp();
    app.setProjectPath(projectPath);
    app.setDesignerFile(designerFile);

    // Load document
    if (designerFile.exists() && designerFile.length() > 0) {
        try {
            app.setDocument(DesignerDocument.load(designerFile));
        } catch (IOException e) {
            System.err.println("Failed to load designer document: " + e.getMessage());
            app.setDocument(new DesignerDocument(designerFile.getAbsolutePath()));
        }
    } else {
        app.setDocument(new DesignerDocument(designerFile.getAbsolutePath()));
    }

    // Forward the scripts tree refresh callback to the app
    if (scriptsTreeRefreshCallback != null) {
        app.setScriptsTreeRefreshCallback(scriptsTreeRefreshCallback);
    }

    // Forward the code file updated callback to the app
    if (codeFileUpdatedCallback != null) {
        app.setCodeFileUpdatedCallback(codeFileUpdatedCallback);
    }

    // Set callback so the app can notify us of changes
    app.setDesignerPanelCallback(new DesignerApp.DesignerPanelCallback() {
        @Override
        public void onSelectionChanged(DesignerEntity entity) {
            SwingUtilities.invokeLater(() -> updatePropertiesPanel(entity));
        }

        @Override
        public void onSceneChanged() {
            SwingUtilities.invokeLater(() -> refreshSceneTree());
        }
    });

    AppSettings settings = new AppSettings(true);
    settings.setWidth(800);
    settings.setHeight(600);
    settings.setSamples(4);
    settings.setVSync(true);
    settings.setFrameRate(60);
    settings.setGammaCorrection(false);

    app.setSettings(settings);
    app.setPauseOnLostFocus(false);
    app.setShowSettings(false);
    app.createCanvas();

    JmeCanvasContext ctx = (JmeCanvasContext) app.getContext();
    ctx.setSystemListener(app);
    canvas = ctx.getCanvas();
    // Let the canvas fill all available space - no fixed preferred size
    canvas.setMinimumSize(new Dimension(100, 100));

    // Insert canvas into the right side of the main split
    JSplitPane mainSplit = (JSplitPane) ((BorderLayout) getLayout()).getLayoutComponent(BorderLayout.CENTER);
    JPanel canvasPanel = (JPanel) mainSplit.getRightComponent();
    canvasPanel.add(canvas, BorderLayout.CENTER);

    // Resize JME3 viewport when the canvas is resized
    canvas.addComponentListener(new ComponentAdapter() {
        @Override
        public void componentResized(ComponentEvent e) {
            int w = canvas.getWidth();
            int h = canvas.getHeight();
            if (w > 0 && h > 0 && app != null) {
                app.enqueue(() -> {
                    app.onCanvasResized(w, h);
                    return null;
                });
            }
        }
    });

    app.startCanvas();

```
So far I tried to modify the AppSettings (Width / Height), The canvas settings (setPreferredSize, setMinimumSize), the canvas listener code (on componentResized modified the width / height).
I searched the forum and found some issues with the canvas inside Swing applications. Not sure what is the best approach for dealing with my issue.
The canvas works just fine and resized just fine. It’s just this unwanted padding.
It’s not a deal breaker but it’s annoying

WDYT?
Thanks in advance

It seems that I have reached a crossroads regarding shaders. It seems that I can only choose to modify the writing method of the shaders or to abstract them to achieve compatibility between OpenGL and Vulkan.
It seems a bit challenging to simultaneously support GLSL inputs for both OpenGL and Vulkan. I need to look into how other engines achieve this.

The only true benefit of the verified subscription was “boosted replies” however there’s also a higher subscription tier (that costs a whopping 40 a month, easily veering into scam territory in my opinion) that gives users even more of a “reply boost” (effectively making the boost for our cheaper tier less effective) and if any of you use twitter, then you likely know how much of a spam-fest the replies on any trending/viral post tend to be. The amount of time it would take replying to game dev related posts to get users’ attention simply isn’t worth it, not by a long shot.

A single 8 dollar promoted post would vastly outweigh the benefits of the X/Twitter subscription for a month. So I likely will never revisit the X/Twitter verified subscription for my own game either, and I will be reserving the limited marketing budget I have for more effective forms of marketing.

I’d ultimately call it useless for marketing any product/service unless you really have the time to spam replies all day, and even then, I question how effective that marketing strategy is considering some people tend to find that type of behavior annoying if done too much. There’s also a negative stigma that many people have toward profiles that pay for the verified badge, viewing it as a badge of shame of some sorts. Although I think this is truer for average joes and wannabe content creators with the verified subscription who spam every trending post with memes and rage bait in an attempt to get noticed, and being verified likely isn’t viewed as negatively for game devs or organizations like jME that actually have a product/service to provide, but the fact that there is a negative stigma at all is still an important aspect to consider.

So the verified subscription was worth trying, but in hindsight it is definitely not worth it, and there’s much better uses of a marketing budget that would yield better results for marketing a game engine or an indie game.

Currently, my plan is to temporarily disregard the issues related to performance and design. At each step, we should try to minimize any modifications until we can ensure that the JME front-end can function properly using Vulkan.

From a theoretical perspective, all OpenGL functions should be achievable.

My current plan is to first complete the necessary content for the JME front-end, and then look into the performance issues.

I know this is a very large project, but I would rather it be an attempt to explore modern graphics APIs so that I can gain a deeper understanding of Vulkan.

My personal opinion is that OpenGL should gradually be abandoned rather than being abandoned immediately.

Based on the current development trend, it will still take some time before the performance level can surpass that of OpenGL.

OpenGL is still a very good choice for beginners as an entry-level learning tool.
The learning curve of Vulkan is extremely steep.

If you play Minecraft, please keep an eye on the latest version of Vulkan.

I suspect that Vulkan will not significantly enhance the performance of many games.

I really like this idea. It would help maintain OpenGL-based games without having to deal with aging OpenGL drivers. That is the same reasoning that led me to start working on implementing ANGLE as a backend in 2585.

The key difference in your approach is that we would have access to Vulkan inside JME, which would give us the opportunity to progressively implement Vulkan functionality directly into the engine over time.

It seems like a big project, if it can help make it more feasible, I believe you could consider targeting the smaller GLES 3.0 subset instead of full OpenGL. The engine is already essentially a GLES-based engine due to Android support, and everything that is OpenGL-only already has a GLES fallback.

package com.jme3.lwjgl.test;

import com.jme3.renderer.Renderer;
import com.jme3.renderer.vulkan.LwjglVulkanContext;
import com.jme3.renderer.vulkan.VKRenderer;
import com.jme3.scene.Mesh;
import com.jme3.scene.VertexBuffer;
import com.jme3.system.AppSettings;
import com.jme3.system.SystemListener;
import com.jme3.util.BufferUtils;

import java.nio.FloatBuffer;

public class VulkanMainMeshTest implements SystemListener {

    private LwjglVulkanContext context;

    private Mesh triMesh;
    private FloatBuffer posBuf;
    private FloatBuffer colBuf;

    private long lastTimeNs;
    private float angleRad = 0f;

    // 初始三角形（未旋转）
// 正方形（2 triangles = 6 verts）
    private final float[] basePos = new float[]{
        // tri 1
        -0.6f, -0.6f, 0f,
        0.6f, -0.6f, 0f,
        0.6f, 0.6f, 0f,
        // tri 2
        0.6f, 0.6f, 0f,
        -0.6f, 0.6f, 0f,
        -0.6f, -0.6f, 0f
    };

    public static void main(String[] args) {
        VulkanMainMeshTest app = new VulkanMainMeshTest();
        app.start();
    }

    public void start() {
        AppSettings settings = new AppSettings(true);
        settings.setTitle("Vulkan Rotating Triangle");
        settings.setWidth(900);
        settings.setHeight(700);
        settings.setSamples(1);

        context = new LwjglVulkanContext();
        context.setSettings(settings);
        context.setSystemListener(this);

        context.create(false);
    }

    @Override
    public void initialize() {
        System.out.println("Vulkan System Initialized.");

        triMesh = new Mesh();
        triMesh.setMode(Mesh.Mode.Triangles);

        // 位置/颜色 buffer（3 verts * 3 comps）
        posBuf = BufferUtils.createFloatBuffer(18);
        colBuf = BufferUtils.createFloatBuffer(new float[]{
            // tri 1 colors
            1f, 0f, 0f,
            0f, 1f, 0f,
            0f, 0f, 1f,
            // tri 2 colors
            0f, 0f, 1f,
            1f, 1f, 0f,
            1f, 0f, 0f
        });

        // 写入初始位置
        posBuf.put(basePos).rewind();
        colBuf.rewind();

        triMesh.setBuffer(VertexBuffer.Type.Position, 3, VertexBuffer.Format.Float, posBuf);
        triMesh.setBuffer(VertexBuffer.Type.Color, 3, VertexBuffer.Format.Float, colBuf);

        triMesh.updateBound();
        triMesh.updateCounts();

        lastTimeNs = System.nanoTime();
    }

    @Override
    public void update() {
        // 计算 dt
        long now = System.nanoTime();
        float dt = (now - lastTimeNs) / 1_000_000_000f;
        lastTimeNs = now;

        // 累积角度（1 rad/s，可自行调）
        angleRad += dt;

        // CPU 侧旋转三角形（绕 Z）
        float c = (float) Math.cos(angleRad);
        float s = (float) Math.sin(angleRad);

        posBuf.rewind();
        for (int i = 0; i < 6; i++) {
            float x = basePos[i * 3];
            float y = basePos[i * 3 + 1];
            float z = basePos[i * 3 + 2];

            float rx = x * c - y * s;
            float ry = x * s + y * c;

            posBuf.put(rx).put(ry).put(z);
        }
        posBuf.rewind();

        // 提交给 Vulkan renderer
        Renderer r = context.getRenderer();
        if (r instanceof VKRenderer) {
            ((VKRenderer) r).renderMesh(triMesh, 0, 1, null);
        }
    }

    @Override
    public void reshape(int width, int height) {
    }

    @Override
    public void destroy() {
    }

    public void pause() {
    }

    public void resume() {
    }

    @Override
    public void requestClose(boolean esc) {
    }

    @Override
    public void gainFocus() {
    }

    @Override
    public void loseFocus() {
    }

    @Override
    public void handleError(String errorMsg, Throwable t) {
        System.err.println(errorMsg);
        if (t != null) {
            t.printStackTrace();
        }
    }
}

Currently, I can use the mesh（class） to transfer vertices to Vulkan. However, I am unable to utilize functions like Geometry at the moment. I haven’t yet studied the material section. Once I am available next week, I will try to figure out a way to create a material backend so that the frontend of JME can directly use it (of course, this is an ideal situation and I’m not sure if it can be accomplished yet).

1. convert VerextBuffer.Type to a real class with a set of constants representing the current enum values.
2. deal with the collateral damage
3. add the binding name to VertexBuffer.Type and stop auto-generating it. (I wouldn’t even automatically prefix ‘in’, personally.)

This is one of a couple places where JME abused ‘enum’ when old style constants would have been better and more flexible. (Off the top of my head, blend mode was another one.)

In this way, overtime, we can deprecate the fixed vertexbuffer types, that are a weird jme specific thing, anyway

Currently the buffer type, aka name is not bound to an actual type. And only InstanceData is allowed to have more then 4 components. (It is a mat4 in the case of instancing)