Generating normals with custom meshes is being strange

I’m trying to make a simple, 4 sided plane. Here’s the code for the vertex positions, indices, and normals:
[java]
Vector3f[] vertices = {
new Vector3f(width / -2.0F, 0, height / -2.0F),
new Vector3f(width / 2.0F, 0, height / -2.0F),
new Vector3f(width / -2.0F, 0, height / 2.0F),
new Vector3f(width / 2.0F, 0, height / 2.0F)
};

        int[] indices = {
            0, 1, 2,
            2, 3, 1
        };

        float[] normals = {
            0, faceUp ? 1 : -1, 0,
            0, faceUp ? 1 : -1, 0,
            0, faceUp ? 1 : -1, 0,
            0, faceUp ? 1 : -1, 0
        };

        Vector2f[] texCoords = {
            new Vector2f(0, 0),
            new Vector2f(0, 1),
            new Vector2f(1, 0),
            new Vector2f(1, 1)
        };

[/java]

But for some reason, it’s not rendering right. Even with a light pointing straight on it, from both sides, it’s just shading solid black. I’ve tried with a directional light pointing right at it, and a point light just above it. Neither one worked. Any help?

How is your material set up?

@zarch I’ve tried with a material using “Lighting.j3md.” I’ve tried it with only a diffuse color, only a diffuse map, diffuse map with normal map, etc. and it doesn’t make a difference. Obviously it works perfectly fine with an Unshaded material, but with Lighting it doesn’t work.

@vinexgames my hunch is that implementing logic on your normals declaration is giving you the error. I guess java is ignoring the logic. I don’t know.

However the way I used to debug my normals was by creating a simple shape in blender, exporting it to .x3d file format and then copying those values (vertices, normals, faces) into my program. If everything else is correct, then you get the a proper rendering on JMonkey. Afterward you start tweaking your code as you wish, just this time you’ll spot the problem as soon it (they) appear(s).

@Pixelapp said: @vinexgames my hunch is that implementing logic on your normals declaration is giving you the error. I guess java is ignoring the logic. I don't know.

Java does not ignore logic. My guess is the material setup but we can’t see the material setup so the question goes unanswered.

This is probably going to be ruled as too obvious but here goes:

One way to debug this is to try it with a regular Quad. Then look at the difference between the manually generated quad and the JME Quad to spot the problem. If the JME Quad also fails then you know the material setup is messed up and/or there is no real light affecting the node.

@Pixelapp I tried it without the logic as well, it made no difference.

@pspeed I’ll try it on just a regular ol’ Box and see if that works. I’m pretty sure it’s not the Material though, because it’s just a Lighting.j3md with a diffuse texture.

A Quad would more closely approximate what you are doing since it’s also a quad. I assume your scene has a light in it at the root node or some node higher than your mesh?

The winding might cause half of the problem

int[] indices = {
0, 1, 2, <-- CCW
2, 3, 1 <-- CW
};

although I always find it hard to think about that so maybe I’m totally off :slight_smile:

@jmaasing said: The winding might cause half of the problem

int indices = {
0, 1, 2, <– CCW
2, 3, 1 <– CW
};

although I always find it hard to think about that so maybe I’m totally off :slight_smile:

No, you’re right but at least he should see a triangle.

I’m not sure why the OP didn’t use JME’s Quad as reference, actually… which has all of this setup right already.

@jmaasing You’re right, it is clockwise. I think that’s because when I was writing the code for this originally I wrote it all, then changed the vertex locations and never changed the indices. Even still though, pspeed is right. I should at least see a triangle.

@pspeed I didn’t use the Quad because it starts at the world origin, and is measured in screen units instead of world units. I didn’t want a bunch of complicated measurements to get it to fit what I’m doing so I made what I figured would be a very simple Plane class.

EDIT: I’ve fixed it. The problem with the indices was part of it. I also needed to run TangentBinormalGenerator on it, which is why it looked awful when I’d try to use a diffuse + normal map.

I meant look at the code. Your code is nearly identical to how a Quad sets itself up except you had the winding backwards for one triangle and yours is in centered x,z space instead of 0 based x,y space.