Pyramid (Dome) gets point light in wrong sides?

I was trying to create a pyramid dome to be viewed from outside the pyramid.

[java]Geometry geom = new Geometry(“ThePyramid”, new Dome(new Vector3f(0,0,0), 2, 4, 2, false));[/java]

All good, except that the sides further away from my PointLight are lit and the sides closer to the light are dark. Is it the curse of the pharaohs or something more mundane?

As far as I know hte dome is mostly used for skybox, might be that it is intended to be seen from the inside.

Inside view is indeed the default for com.jme3.scene.shape.Dome, but happily it provides a long-form constructor which permits you to specify outside view:

public Dome(Vector3f center, int planes, int radialSamples, float radius, boolean insideView)

Yes, I was using that long-form constructor. Dome shape is drawn correctly but lightning seems to go in the opposite sides. Perhaps a bug in jme3?

Here is a short test to prove my point. Sphere on the left is lit correctly, but dome on the right is not.

import com.jme3.light.PointLight;
import com.jme3.material.Material;
import com.jme3.math.ColorRGBA;
import com.jme3.math.Vector3f;
import com.jme3.scene.Geometry;
import com.jme3.scene.shape.Dome;
import com.jme3.scene.shape.Sphere;

public class DomeTestApp extends SimpleApplication {

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

public void simpleInitApp() {
    Material unshaded = new Material(assetManager, "Common/MatDefs/Misc/Unshaded.j3md");
    Material lighting = new Material(assetManager, "Common/MatDefs/Light/Lighting.j3md");
    lighting.setColor("Diffuse", ColorRGBA.Blue);

    // setup light
    Geometry geom = new Geometry("Light", new Sphere(16, 16, 1));
    PointLight light = new PointLight();

    // setup sphere
    geom = new Geometry("Sphere", new Sphere(16, 16, 1));
    geom.setLocalTranslation(-3, 0, 0);

    // setup dome
    geom = new Geometry("Dome", new Dome(new Vector3f(0,0,0), 16, 16, 1, false));
    geom.setLocalTranslation(3, 0, 0);



This does seem to indicate a bug in com.jme3.scene.shape.Dome

I took a quick look at the source and didn’t see anything obviously wrong, but as Phoenix noted, this class is mostly used to generate inward-facing domes, so i’s possible the code was never tested for outward-facing domes with lit material.

Luckily (and for reasons unrelated to this bug) I wrote my own dome mesh generator for SkyControl, which does not have this bug. You’re welcome to use it. Source code is at

The constructors differ somewhat from com.jme3.scene.shape.Dome. To generate the dome for your test app, I used “new DomeMesh(16, 16, 0.5f, 0.5f, 0.44f, false);” If you use textures, you may need to adjust them because the texture coordinate system of DomeMesh is different from that of com.jme3.scene.shape.Dome

Its not too difficult to explain whats going on with this, no bug, either the Dome was meant to be coded like this or it just wasn’t thought through.

If you take a look into the source of Dome class, setting insideView to false mostly just inverts the normals of the dome, the lights still going to shine on the same side, I think…

I made this image to try and explain…

And I will take another look at how to solve it tomorrow if nobody has done so by then, I need to look into geometries a bit more I think.

inverting the normals should change the lit side for lambertian lighting tho

PSpeed once told me normal only affect the side from which it can be rendered not the light… Maybe I’ve misinterpreted… Whats wrong with the dome them? To me it seems like the light carries on and hits the same faces even though the normal of those faces is flipped. Then is it a problem with the light?

I’ve done some more experiements, and I’m now even more convinced this is evidence of a bug in com.jme3.scene.shape.Dome. To be precise, it writes normals with incorrect signs near lines 251-257 and 269.

For instance, if insideView is true, at line 269 it writes (0, 1, 0) into the normal buffer for the pole vertex. However that’s clearly an outward-facing vector. The sense of the “if” should be reversed so that (0, -1, 0) is written in this case.

Similarly, if insideView is true, at line 254 it writes the normalized offset from center to the normal buffer. However, that’s clearly an outward-facing vector. Again, the sense of the “if” is backward.

At least the vertex indices appear to be in the correct order.

I suspect the reason this bug has been missed in the past is that few people use domes with lit materials. With unshaded material the vertex normals do not affect the render.

While I can’t commit the fix myself, I’ve opened a new issue (#615) to ensure this doesn’t get lost.

@javagame said: PSpeed once told me normal only affect the side from which it can be rendered not the light... Maybe I've misinterpreted... Whats wrong with the dome them? To me it seems like the light carries on and hits the same faces even though the normal of those faces is flipped. Then is it a problem with the light?

You must have misunderstood as that’s exactly backwards. Vertex winding controls what is ‘front’ and ‘back’. Normals control how the triangle is lit by light.

1 Like
@sgold said: While I can't commit the fix myself, I've opened a new issue (#615) to ensure this doesn't get lost.

Thanks for opening an issue.