Wireframe rendering for GLES

User Code & Projects
1

Hi guys

I’ve just implemented a simple project including a geometry shader based wireframe rendering material for GLES (it also works also on desktop GL):

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

EDIT:

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 :wink:

Screen capture running on my phone:

Screenshot_20210121-180025
Screenshot_20210121-1800252340×1080 46.5 KB

EDIT: rework the post to reflect the current repositories properly

6 Likes
2

I’m not an Android developer, so I don’t feel qualified to judge your contribution.

1 Like
3

OpenGL has a default wireframe mode, OpenGLES does not have a wireframe mode (POLYGONMODE), so this needs to be implemented with GLSL. :male_detective:

4

Yes, that’s the point here, the material I posted in the linked github project implements it using geometry shaders :wink:

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

3 Likes
5

Well, I got some more spare time and I implemented also the barycentric coordinate approach for wireframe rendering, so, if using this technique instead, you can have wireframe on any openGLES release

It’s all detailed in the readme but… from left to right: Geometry shader approach, jME3 default wireframe mode (will render solid on android) and Barycentric coordinates approach:

Desktop

wireframe-desktop
wireframe-desktop800×600 19.5 KB

Android

wireframe-android
wireframe-android2340×1080 55.7 KB

5 Likes
6

looks more “chaotic”. but works on mobile.

is it possible make them look more similar to default JME one? (backface culling or something to make less chaos draw?)

7

Yes, sure. Just by leaving face culling and depth test by default instead of overwriting it as it’s doing now

Changing the j3md from:

    RenderState {
        Blend AlphaAdditive
        DepthWrite Off
        DepthTest Off
        FaceCull Off
    }

to:

    RenderState {
        Blend AlphaAdditive
    }

I set it up this way because I wanted to be coherent with the geometry shader render not jme’s default

EDIT:

Adding screenshot with the change to mimic jME3’s behaviour

wireframe-mimic-jme3
wireframe-mimic-jme3768×277 15 KB

2 Likes
8

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.

Desktop:

wireframe-desktop
wireframe-desktop1278×718 73.6 KB

Android:

wireframe-android
wireframe-android2340×1080 135 KB

6 Likes
9

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 :thinking: . 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

Thanks :wink:

2 Likes
10

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.

11

My reason for wanting to integrate it into jme is to properly support the physic debug shapes on android nowadays rendered solid. Probably it’s not a big issue for most people here…

And yes, for sure it could be kept as a library, in fact, if finally not included in any way, I may update the project as a library and add it to the store

2 Likes
12

Adding it to the Store sounds like a good plan.

At this time, I’m looking to reduce the amount of code maintained by the JMonkeyEngine “core team”. That includes (probably) cutting physics out entirely, which would of course include debug shapes.

13

Then physics will be removed? I thought you were adding minie as replacement of jme-bullet in the long term.

1 Like
14

They will be separate projects… so that they can have their own lifecycle not linked to the glacial JME releases.

2 Likes
15

Minie is an add-on, not part of JMonkeyEngine. I don’t see that changing anytime soon.

1 Like
16

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

Thanks for your comments

1 Like
17

That’s basically accurate.

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.

Recent discussion of this transition can be found in the Suggestions for v3.4 Forum topic.

2 Likes
18

This will sound as a really noob question but I’ve never needed to do it… Where and how can I upload the library so it can be downloaded when added to the gradle dependencies? :thinking:

2 Likes
19

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.

2 Likes
20

If you use gradle there are also ways to automate the publishing process once you have the accounts setup. JME does it… but has a beast of a build. All of my published projects also do it.

SimMath may be the easiest example… though I’m still using an older gradle:

2 Likes