Engine v3.4.0 beta testing

Development
21

This doesn’t occur with JME 3.3.2-stable on the same system?

1 Like
22

I am still using my local build v3.4.0-SNAPSHOT, but if you haven’t changed this shader file in the new 3.4.0 version then it would happen jme3.3.2 too.

23

I don’t think it’s connected with wireframes or physics debug visualization. More likely it’s connected with the VehiclePointsState used to visualize the vehicle cameras.

I am still using my local build v3.4.0-SNAPSHOT, but if you haven’t changed this shader file in the new 3.4.0 version then it would happen jme3.3.2 too.

The failing shader is in my Heart library. I’m worried there might be a regression between JME 3.3.2 and JME 3.4.0-beta1 that breaks certain shaders such as this one. Please check.

1 Like
24

I think that’s the issue based on some brief internet searching. Apparently gl_PointCoord is a 1.2 feature.

1 Like
25

what does the vehicle points does ?, from the error, it’s apparent that it enables wireframe debugging for the car, isn’t it ?

No. Wireframes (physics debug visualization) are enabled/disabled by “/” key, which is handled by the PhysicsMode appstate, which doesn’t use point sprites.

Vehicle points are enabled/disabled by a checkbox in the “Debug” tab. The VehiclePoints appstate visualizes 3 points:

  • the vehicle’s center of mass,
  • the location of the dash camera, and
  • the target location for the chase camera.

After all these years, I don’t know much about GLSL. Please help me understand what’s happening here.

1 Like
26

Device Spec :

Mar 10, 2021 8:24:33 PM com.jme3.renderer.opengl.GLRenderer loadCapabilitiesCommon
INFO: OpenGL Renderer Information
 * Vendor: Intel Open Source Technology Center
 * Renderer: Mesa DRI Intel(R) Kabylake GT2F 
 * OpenGL Version: 4.6 (Core Profile) Mesa 19.3.3
 * GLSL Version: 4.60
 * Profile: Core

I wonder why GLSL v4.60 isn’t listed in the table of gl_PointCoord & if it gets deprecated, there must be other alternatives ?

This works fine…

I have some questions :

→ Does the VehiclePoints work on your device, or other devices (if exist) at your workspace ? & what are their glsl versions ?!

→ Why gl_PointCoord isn’t defined here ?? , Is it a type of macro defined in GLSLCompat.glsllib ??

#import "Common/ShaderLib/GLSLCompat.glsllib"

#ifdef DISCARD_ALPHA
        uniform float m_AlphaDiscardThreshold;
#endif
#ifdef MATERIAL_COLOR
        uniform vec4 m_Color;
#endif
#ifdef POINT_SHAPE
        uniform sampler2D m_PointShape;
#endif
#ifdef VERTEX_COLOR
        varying vec4 vertexColor;
#endif

EDIT : I have navigated through the GLSLCompat.glsllib source, no gl_PointCoord isn’t a macro their…So from where it comes ?

1 Like
27

Yes, Particle.frag fragment shader uses the gl_PointCoord but if only POINT_SPRITE macro is defined (ie set to true) :

From Particle.frag :

#ifdef USE_TEXTURE
        #ifdef POINT_SPRITE
            vec2 uv = mix(texCoord.xy, texCoord.zw, gl_PointCoord.xy);
        #else
            vec2 uv = texCoord.xy;
        #endif
        gl_FragColor = texture2D(m_Texture, uv) * color;
    #else
        gl_FragColor = color;
    #endif

if i do :

        material.setBoolean("PointSprite",true);

i won’t get a crash, but rather an invisible not rendered particles (ie no particles).

Seems the vec2 uv = mix(texCoord.xy, texCoord.zw, gl_PointCoord.xy); does mix the coordinates from the defined instances only(ie, it uses the macros guard or #ifdef....#endif, before applying any calculations, so my laptop ignores it & mix the 2 other coordinates which results in displaying nothing)…

if i do :

        material.setBoolean("PointSprite",false);

Everything runs normally.

But for the texture2D inside the multicolor2.frag seems it’s mandatory to have gl_PointCoord not a nullptr macro, or you will have a crash.

1 Like
28

When doing a google search I saw that the spec was wrong in some post… but apparently the post is wrong because I’ve used gl_PointCoord in tons of shaders with version 110.

They do have to have PointSprite on in the render state, though.

        RenderState {
            PointSprite On
        }
1 Like
29

Yes, it works on my desktop, which has “GLSL Version: 4.60 NVIDIA”.

1 Like
30

I wonder why GLSL v4.60 isn’t listed in the table of gl_PointCoord & if it gets deprecated, there must be other alternatives ?

v4.60 wasn’t indicated because the reference I cited was for OpenGL 4.5

It hasn’t been deprecated in v4.60. It’s mentioned on pages 144 and 145 of the 4.60 specification: https://www.khronos.org/registry/OpenGL/specs/gl/GLSLangSpec.4.60.pdf

Why gl_PointCoord isn’t defined here ??

The specification (cited above) calls it a built-in special variable.

1 Like
31

So, it’s a system incomptability issue, I mean there’s no issue then ? If it works on other devices ?

1 Like
32

I suspect it’s an issue with the video drivers on your system. But in that case:

  • you should see the same issue with both JME v3.3.2 and JME 3.4.0-beta1 and
  • you shouldn’t see the issue on systems with different video hardware.

Until someone else reproduces the issue, I’m relying on you to investigate it.

1 Like
33

yes the same issue, just tested it now…

I don’t have currently other hw devices supporting jme, other than my Android device & the RPI, do you have a simple example of using multiColor2.j3md ? , but i do have windows on the same laptop, would that matter ? the drivers support…

1 Like
34

I have tested this now on my Android device, Android 10 API 29, OGLES 3.2, i can see the particles rendered, but i can see no difference between settling point sprite to true & to false…what does mixing coordinates do anyway ? i hate magic :-)).

I don’t know why jme GLRenderer detects it as OpenGL 2 (this shouldn’t be the case) , may be the equivalent :

2021-04-22 20:01:50.814 20637-25254/com.scrappers.dbcodecamp I/GLRenderer: OpenGL Renderer Information
     * Vendor: {0}
     * Renderer: {1}
     * OpenGL Version: {2}
     * GLSL Version: {3}
     * Profile: {4}
35

mix() interpolates. It’s not magic. It’s figuring out which ‘texel’ to paint on that fragment.

1 Like
36

Here’s one: https://github.com/stephengold/Heart/blob/master/HeartExamples/src/main/java/jme3utilities/debug/test/TestSkeletonVisualizer.java

1 Like
37

Fortunately, i have a windows image on the same device (dual boot), so it works on windows :smile: for both jme3.3.2-stable & jme3.4.0-beta1,

Device Specs showing :

INFO: OpenGL Renderer Information
 * Vendor: Intel
 * Renderer: Intel(R) HD Graphics 620
 * OpenGL Version: 4.6.0 - Build 26.20.100.7262
 * GLSL Version: 4.60 - Build 26.20.100.7262
 * Profile: Compatibility

It’s my issue now or Parrot’s, not the engine one, i will search for updates for gpu drivers in parrot.

EDIT : After reading the specs given from Linux Runtime VS Windows Runtime, I have spotted the Profile: Core in Linux, Profile: Compatibility in windows, may be that what causes the crash, that windows drivers are more capable of running in a compatibility mode for that kinda of hardware !
& my actual driver that is stated by the distributor & manufacturer is Intel HD 620 not mesa 19.3.3, that’s why I thought that the problem comes from the Linux drivers !

2 Likes
38

@Pavl_G I’ve faced multiple random GL rendering issues with the intel UHD 620 of my laptop in linux. I’ve solved not all but most of them using the configuration I stated here and also setting MESA_LOADER_DRIVER_OVERRIDE=i965 in /etc/environment

I don’t know if this will help you with the gl_PointCoord issue but it may worth a try (I’ve not tested it myself)

1 Like
39

Thanks @joliver82 , I would check that.

1 Like
40

JMonkeyEngine v3.4.0-beta2 was released today. It’s basically beta1 with PR 1527 integrated.

If those pesky NPEs were discouraging anyone from testing v3.4 (or solving other bugs), now would be a great time to jump in and do your part for JMonkeyEngine!

6 Likes