Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

point sprites render smaller with MSAA samples=16 than with other settings #878

stephengold opened this issue Aug 20, 2018 · 5 comments


None yet
3 participants
Copy link

commented Aug 20, 2018

I recently noticed that Points-mode meshes render differently when the app is configured for 16 samples-per-pixel than when it is configured for 2, 4, 6, or 8 samples-per-pixel.

When the test app (below) is run in a 640x480 window with anti-aliasing disabled, the points p1 and p2 render as barely-touching white squares. Likewise with 2-, 4-, 6-, or 8-sample anti-aliasing. But with 16 samples, the points render as squares about half as large, so that there is a noticeable gap between them.

I doubt this relates to my GPU's maximum point sprite size, since doubling the PointSize in the mesh causes the squares to touch with 16-sample anti-aliasing.

I discovered this issue in JME version 3.2.1-stable and verified that it also occurs with 3.2.0-stable.

package mygame;

import com.jme3.font.BitmapText;
import com.jme3.material.Material;
import com.jme3.math.ColorRGBA;
import com.jme3.scene.Geometry;
import com.jme3.scene.Mesh;
import com.jme3.scene.VertexBuffer;
import com.jme3.util.BufferUtils;
import java.nio.FloatBuffer;

public class Main extends SimpleApplication {

    class PointMesh extends Mesh {

        PointMesh() {
            FloatBuffer fPos = BufferUtils.createFloatBuffer(3);
            VertexBuffer vPos = new VertexBuffer(VertexBuffer.Type.Position);
            vPos.setupData(VertexBuffer.Usage.Stream, 3, VertexBuffer.Format.Float, fPos);

    public static void main(String[] args) {
        Main app = new Main();

    public void simpleInitApp() {

        Material white6 = new Material(assetManager, "Common/MatDefs/Misc/Unshaded.j3md");
        white6.setColor("Color", ColorRGBA.White);
        white6.setFloat("PointSize", 6f);

        Mesh mesh = new PointMesh();

        Geometry p1 = new Geometry("p1", mesh);

        Geometry p2 = new Geometry("p2", mesh);
        p2.setLocalTranslation(0.1f, 0.1f, 0f);

        int samples = settings.getSamples();
        int height = cam.getHeight();
        int width = cam.getWidth();
        float pointSize = (Float) white6.getParam("PointSize").getValue();
        BitmapText text = new BitmapText(guiFont, false);
        String message = String.format(
                "Samples=%d Height=%d Width=%d PointSize=%.0f",
                samples, height, width, pointSize);
        float centerX = (width - text.getLineWidth()) / 2;
        text.setLocalTranslation(centerX, height, 0f);

INFO: OpenGL Renderer Information

  • Vendor: NVIDIA Corporation
  • Renderer: GeForce GT 545/PCIe/SSE2
  • OpenGL Version: 4.6.0 NVIDIA 388.73
  • GLSL Version: 4.60 NVIDIA
  • Profile: Compatibility

This comment has been minimized.

Copy link
Contributor Author

commented Oct 1, 2018

Occurs with both v2.9.3 and v3.1.6 of LWJGL.


This comment has been minimized.

Copy link

commented Mar 18, 2019

Well, I was able to confirm on:

NVIDIA Quadro FX 880m/PCIe/SSE2
OpenGL 3.3.0
GLSL 3.30
Profile: compatibility.
Windows 10 PRO

I've not been able to figure out how to force my laptop to use the integrated chipset instead. (some variant on Intel HD)

I don't understand for certain why this is happening, but I suspect that some insight may come from the Khronos spec for how glPointSize is handled

Apparently, there is a multiple-step Round-and-clamp process when figuring out the actual rendered size.

In particular, I have not been able to figure out if JME enables GL_POINT_SMOOTH by default, which will affect how AA rendering handles points. GL_POINT_SMOOTH is disabled and MSAA is enabled, the render width of the point is reduced from the number specified in PointSize. The math on this is unclear. (formating issues on the page)
Note: PointSize (The variable) always remains at the size the code sets, even if the GL driver is monkeying with it behind the scenes. See also the notes on POINT_SIZE_RANGE and POINT_SIZE_GRANULARITY


This comment has been minimized.

Copy link

commented Mar 18, 2019

Brief Follow-up:

I added a Quad behind the points, and adjusted the colors to contrast and blend well. (Red and Blue)
I found that when using AA, the points' alpha is shifted to more transparent, but they are still rendered as squares.

This is consistent with GL_POINT_SMOOTH being disabled.

I Might be able to hack together an ARM build of LWJGL, and test this out on a RasberryPI, just to get a different GPU involved. That, however, may take a bit.


This comment has been minimized.

Copy link
Contributor Author

commented Mar 18, 2019

Thanks for pursuing this. Glad to know it's not just me!


This comment has been minimized.

Copy link

commented Mar 18, 2019

I might suggest using Vmware Player 14 + something like ubuntu and install the vmware tools on the guest, it uses a virtual gpu, that is enough to run jme somewhat, might be an easier way than to compile lwjgl for arm :)

Extended renderer info (GLX_MESA_query_renderer):
Vendor: VMware, Inc. (0x15ad)
Device: SVGA3D; build: RELEASE; LLVM; (0x405)
Version: 18.3.4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.