I came across with the idea of trying to implement it after reading that physics debug meshes were rendered solid here
@sgold if you think it’s good enough to have it integrated in jme3 core to fix the debug shapes issue, tell me.
If there’s anyone needing something similar, just feel free to use it
I forgot to mention that this should work properly with instancing, skinning and morphing. If there’s anyone using any of those jme3 functionalities wanting to test it and give me feedback is much appreciated
Yes, that’s the point here, the material I posted in the linked github project implements it using geometry shaders
Obviiously it’s mostly useless for desktop but if you want to use the exact same code in all your binaries either using openGL or openGLES, instead of having to check when to use one material (or flag) or the other, you can directly use this one
I made a little improvement over it with better line rendering when using barycentric coordinates. Now from left to right, top to bottom: jME3 default wireframe mode (will render solid on android), Barycentric coordinates approach mimicing jME3’s default, Geometry shader approach and Barycentric coordinates approach mimicing geometry shader approach.
I’ve been having a look at how to integrate the wireframe I implemented with jme3 to solve issue 1345.
I have some doubts on which would be the best way to go
I’m using Heart’s library MyMesh.expand to have the mesh in the required state for barycentric, so I would need to add this to jme3 somehow. I’m not sure which would be the best class to add this. Maybe the mesh class itself as expandSelf() or other external helper class as it’s done in heart . Also, @sgold are you OK with copying your code into jme? as it’s from your library…
Same for the method setting the bary coords, not sure if Mesh would be the class to add it or any other class.
Currently I’m using the normal buffer for bary coords, in this case when rendering wireframe normals are useless but maybe I should add a new buffer to the mesh for this instead. Not sure but I think normals are used or even overwritten when animating a mesh
In my opinion, the GLES wireframe renderer should be an add-on library for now and not become part of JMonkeyEngine, at least until it’s in widespread use. As an add-on library, there shouldn’t be any issue with it depending on the Heart library.
Anyone could copy code from Heart to JMonkeyEngine, subject to the terms of the BSD license. Those terms include keeping the copyright notice intact. In the case of MyMesh, the copyright holder is Stephen Gold (not jMonkeyEngine). Generally we like to have jMonkeyEngine as the copyright holder for Engine source files, though doubtless exceptions have been made in the past.
oook, I see. So jme-bullet and minie will be projects fully independant of jme and they both could use my wireframe stuff to render the debug shapes if required. Then I’ll change this to be an addon library for jme
The plan (as I understand it) is to move jme3-bullet and its related libraries to a new repository in the jMonkeyEngine-Contributions project, alongside jme3tools.navigation, BlenderLoader, and shaderblowlib. Unless someone volunteers to maintain it, it will then cease to be maintained.
The usual path is to create an open-source account at BinTray, create a Maven repo, create a package in the repo, create a version of the package, upload a POM and a JAR for the version, and then request that the package be linked to JCenter.
There are many potential pitfalls, so don’t be shy about asking for help.