May be a dumb question - I couldn’t find anything here on the forums or in the documentation:
If I am to learn shaders, is lwjgl or jogl (or a completely different one) the way to go with JME? Just want to make sure I end up on the right path (sort of easiest to get started when relying on JME).
Thanks
I don’t know that it matters… but I think most folks here probably use lwjgl. So if there are any inconsistencies then that might slow down trouble shooting. Otherwise, they should behave the same with respect to shaders.
I suspect that if you want to “learn shaders… with JME” you probably want to read up on glsl and not worry about lwjgl/jogl as these layers are abstracted away from you.
Thanks. Is it correct understood that JOGL and LWJGL are GLSL wrappers?
And if so - which version of Open GL does JME 3.1 / 3.2 support? (am I asking the right questions? 
)
Another question: In the fragment shader, is there any tpf information available? I want to create a shader, that alters the TexCoords based on framerate/timing.
If you pass it in there is.
JME also provides a standard g_Time or g_Tpf (pretty sure on that last one) if you enable them in your matdef.
No. They’re OpenGL wrappers… sort of. You should not care about them in this discussion. It’s just about literally like talking about OpenJDK versus Oracle JDK.
All of them since OpenGL 2. Maybe you should step back and tell us why you asked the question because that kind of question feels like you’ve already painted the floor behind you and are asking where the doors out of the room are.
Haha. No - I’m merely curious. Passionate about learning on the subject. I feel my goal is pretty simple - I’m just trying to learn as I go. I know it, with all likelyhood, wont matter for my intent
A question asked without context usually leads to an answer that won’t be remembered when needed.
Learn by doing. Fork unshaded… break and fix it with purpose, over and over.
I guess the context would be that I am reading tutorials, guides and background information now, so if I come across anything that says ‘supported only in version X.Y’ - I would have a sense of whether or not the information can be used in my application.
I agree with the learn by doing approach. We all take in information in different ways and I feel that curiosity should never by dissuaded (even if its my own).
Essentially you should look into jme’s MaterialDef since it defines the shaders and also the possible input parameters which in turn are valued by the Material Instance.
The wiki has some tutorials about own shaders in jme however you might learn faster when using this shader eclipse fork whose Name i dont remember.
Also: the Version only depends on your Hardware (jme 3.1 needs 2.0 at least and uses some 3.x Features or extensions where possible and if not Fallback or manuelly work around)
Start the SDK or a jme game and Check the first Lines of Log for the Versions and extensions
Question: The method: setBuffer on a mesh, is that a way to feed values to the corresponding attributes inside the Vertex Shader?
A bit confused here - do these two somehow do the same?
quad.setBuffer(VertexBuffer.Type type, int components, <type> value)
material.set*(String name, <type> value)No. One is setting vertex attributes. The other is setting uniforms…
I have a feeling if you opened Unshaded.j3md and then Unshaded.vert then a lot of your questions will be answered (or at least lead to more specific questions) as you try to figure out what the heck is going on and why there is a Color material parameter but an m_Color uniform and so on.
Not really, setBuffer is for mesh data such as the Vertex Buffer and the Index Buffer.
You wouldn’t pass a color like this but with Material.set. The equivalent to a Buffer would possibly be a texture or rather an Array.
It could be that you can set custom buffers for compute shaders but keep in mind the difference between Material and Mesh.
Mesh effects the Form and Material mainly the shading
Ah, I had a feeling that was the case. Cool.
Already been there. I am not so vexed by the inside of the Vertex and Fragment shader, nor the Attributes, Uniforms or Varyings or general syntax. I am trying to catch up on how JME integrates (or how I feed or do not feed the shaders) so to speak. My aim is to have the shader update texture coordinates itself (basically: set texture, maybe set rows/columns, and in the shader then update position to show each piece of the texture one by one based on timings) - and I’ll get there in time I think.
Yeah, you’ll get there. Depending on how you want the coordinates to change it’s really trivially easy once you know your way around.
…a good easy goal.
I found out the JME already passes the uniform Tpf into the shader (accessible then via g_Tpf). Great stuff
The Shader documentation has broken links to UniformBinding.java and to VertexBuffer.java - I commented on the documentation. Not sure how else to report them.
Yes, which was mentioned directly in my full quote:
You have to add Time or Tpf to your matdef’s WorldParameter’s section or they won’t be set.
I have to improve my reading of replies to my posts. Its beginning to feel embarrassing 
Do I understand it correctly, when saying that I cannot in a J3M file specify a Vector2f[] array as TexCoords? I want to replace this:
quad.setBuffer(VertexBuffer.Type.TexCoord, 2, spriteCoords);
With an equivalent in the material file, like:
TexCoord : 0.0 0.0 0.1 0.0 0.1 1.0 0.0 1.0
Is that possible? I think not (according to https://docs.jmonkeyengine.org/advanced/j3m_material_files.html) just want to be sure.
TexCoord is a vertex attribute, not a material parameter.
…and it’s very strange to want to use it as a material parameter since that implies forever and ever that you will have one material per quad.