I have been wresting to make my own meshes show up well using the lighting shader (more on that later). While doing so I found something strange in the standard shapes. Might be a bug consuming more memory than it should.
This is what I found in Box.java. I see the same in Line and Quad.
[java] protected void duUpdateGeometryIndices() {
if (getBuffer(Type.Index) == null){
setBuffer(Type.Index, 3, BufferUtils.createShortBuffer(GEOMETRY_INDICES_DATA));
}
}
[/java]
For the indices, shouldn’t the 3 above be a 1? (thats the ‘components’ field for whatever that may mean - i think number of numbers for a unit, eg 3 for a vector3)
At least, the Custom Mesh example seems to agree with me.
(By the way, that example neglects to include normals. Why? - Should I edit the wiki? how can I add sections to the page; can only edit sections)
An umm, what does mesh.setVertexCount(n) do? I see it used in Cube but not in Quad.
So, anyway, when displaying my own shapes (simple home made quads that I can rotate) all looks well with a simple texture shader. However once I put the Lighting shader on, they look much darker than they should (compared to the standard Box I put next to them).
Could this have something todo with the normals on my meshes not being right?
Now, I made a method to rotate my shapes (which i use) around the x,y and z axis (which works for the vertices). I am also rotating the normals. Is that a correct assumption?
I could use any tips here because I’m hiting a wall.
The TangentBiNormalGenerator.generate(mesh) doesn’t fix it (but then again I don’t know what it does exactly).
Leaves me with the normals themselves. I think they’re for calculating the amount of lighting on the receiving trimesh. I also think they’re attached to the vertices, and should be going out perpendicularly from the surface on the visible (counterclockwise) side of the trimesh, and have a length of 1.
Is that correct?
For the indices, shouldn’t the 3 above be a 1? (thats the ‘components’ field for whatever that may mean – i think number of numbers for a unit, eg 3 for a vector3)
If I recall correctly, that value does nothing for index buffers. The only reason its 3 is because I thought of 3 indices per triangle .. It doesn't matter.
By the way, that example neglects to include normals. Why?
I am not sure. Maybe because they are only required for the Lighting shader which is not used in the example.
An umm, what does mesh.setVertexCount(n) do? I see it used in Cube but not in Quad.
The vertex count is automatically calculated based on the buffers of the mesh. So setting is not necessary. I guess it stayed there since I ported the class from jME2.
So, anyway, when displaying my own shapes (simple home made quads that I can rotate) all looks well with a simple texture shader. However once I put the Lighting shader on, they look much darker than they should (compared to the standard Box I put next to them).
Could this have something todo with the normals on my meshes not being right?
Quads are generally not the best model to test Lighting on. All the normals face the same direction, so you will get somewhat of a flat lighting on it. If your light is not facing the quad then it will look dark.
Now, I made a method to rotate my shapes (which i use) around the x,y and z axis (which works for the vertices). I am also rotating the normals. Is that a correct assumption?
Yes.
The TangentBiNormalGenerator.generate(mesh) doesn’t fix it (but then again I don’t know what it does exactly).
You only need to use it when you're using normal mapping.
Leaves me with the normals themselves. I think they’re for calculating the amount of lighting on the receiving trimesh. I also think they’re attached to the vertices, and should be going out perpendicularly from the surface on the visible (counterclockwise) side of the trimesh, and have a length of 1.
Is that correct?
Yes.
Thanks for your answers Momoko 
I’d like to follow up on two of them.
So, anyway, when displaying my own shapes (simple home made quads that I can rotate) all looks well with a simple texture shader. However once I put the Lighting shader on, they look much darker than they should (compared to the standard Box I put next to them).
Could this have something todo with the normals on my meshes not being right?
Quads are generally not the best model to test Lighting on. All the normals face the same direction, so you will get somewhat of a flat lighting on it. If your light is not facing the quad then it will look dark.
The TangentBiNormalGenerator.generate(mesh) doesn’t fix it (but then again I don’t know what it does exactly).
You only need to use it when you’re using normal mapping.
ok after some investigation, i've not been entirely fair (my code has grown somewhat). Let me extrapolate. I've a standard Box with the Lighting material. It looks ok.
Next to that I have some of my handmade quads in different rotations, but all horizontal or vertical along the x or z axis aligned just like the box. Now they initially look fine too; their luminosity is equal to that of the corresponding faces of the standard Box next to it.
(I understand that the angle of the quads should influence lighting, but I have all 6 orientations just like the standard Box next to it. You could call it a box with detached sides.)
So, it looked ok, but then i moved the camera around a bit and i saw some (definately a few but not always the same) quads abruptly loose much of their brightness and back to normal again when i rotate the camera back. Diferent camera angles->different quads loose their brightness. Most often near the edges.
I thought it was about camera culling so I tried a bounding box (use a box on a quad?) but that didn't help.
Next step was to use TangentBiNormalGenerator.generate(mesh) on my quads which helped, although I loose about half of my brightness on all the quads.
I have just printed out the normals before and after I use the TangentBinormalGenerator and they all look the same, and all look like what normals should look like to me. (except for the fact that i see 0.0's and -0.0's.. negative zeros, could that be a problem?)
Back to the question then. I am using the lighting shader on my quads, which uses normal mapping afaik (ive added a normal texture).
That means I should use the TangentBiNormalGenerator then? But what does it do exactly, and why do I end up with a loss of lighting on my faces?
Also, I am using TBNG.generate() but it also has other methods - maybe I'm using the wrong one.
What about the loosing of brightness in relation to the camera angle (see above) that didn't want to get solved by a bounding box. What could cause that and do you think it can have a relation to the TangentBiNormalGenerator?
As you see i'm a bit confused. I'm getting to grips with 3D and its nomenclature but that TBNG is still a mistery as are the cause of some effects I see.
Thanks in advance.
Edit: last question (tm) : If I rotate a mesh (yes by hand, cos and sin stuff), do I need to rotate more than only the vertice and the normals buffer?
I also noticed strange behavior on angle changes… Just saying… 
normen said:
I also noticed strange behavior on angle changes.. Just saying... :)
Specifically with the Lighting material? And is that without using TangentBiNormalGenerator? Do you still have the issues after using that, and have you lost luminosity after using it?
Dont know, I dont have a test case. I just noticed it some time.
And while you wrote that, I was making a test case 
[java]import com.jme3.app.SimpleApplication;
import com.jme3.bounding.BoundingSphere;
import com.jme3.light.DirectionalLight;
import com.jme3.material.Material;
import com.jme3.material.RenderState.FaceCullMode;
import com.jme3.math.ColorRGBA;
import com.jme3.math.Vector3f;
import com.jme3.scene.Geometry;
import com.jme3.scene.Node;
import com.jme3.scene.Spatial.CullHint;
import com.jme3.scene.shape.Box;
import com.jme3.scene.shape.Quad;
import com.jme3.system.AppSettings;
import com.jme3.util.TangentBinormalGenerator;
/**
- This test shows Lighting not working properly.
- You see 2 cubes, one with TangentBinormalGenerator, one without. Both look fine.
- Above those 2 Quads, both TBNGenerators disables but the right quad is darker. Same mat.
*
- Look up (move the objects down) to see the right Quad suddenly brighten up as
- it gets close to the window bottom, then darken again.
*
-
@author Durandal
*/
public class LightingProblemTest extends SimpleApplication {
public static void main(String[] args) {
LightingProblemTest app = new LightingProblemTest();
AppSettings settings = new AppSettings(true);
settings.setTitle(“Test”);
settings.setRenderer(AppSettings.LWJGL_OPENGL2);
settings.setWidth(1024);
settings.setHeight(768);
app.setShowSettings(false);
app.setSettings(settings);
app.start();
}
@Override
public void simpleInitApp() {
Material mat = new Material(assetManager, “Common/MatDefs/Light/Lighting.j3md”);
mat.setTexture(“m_DiffuseMap”, assetManager.loadTexture(“Textures/Terrain/Pond/Pond.png”));
mat.setTexture(“m_NormalMap”, assetManager.loadTexture(“Textures/Terrain/Pond/Pond_normal.png”));
mat.setFloat(“m_Shininess”, 15f); // [0,128]
mat.setActiveTechnique(null);
// trimeshes visible both sides
mat.getAdditionalRenderState().setFaceCullMode(FaceCullMode.Off);
Box b = new Box(5,5,5);
Geometry g = new Geometry(“box”,b);
g.setMaterial(mat);
rootNode.attachChild(g);
Geometry g2 = new Geometry(“box2”,b);
g2.setMaterial(mat);
g2.setLocalTranslation(14, 0, 0);
TangentBinormalGenerator.generate(g2); // in contrast to a Quad, a box doesnt get too dark
// after using this.
rootNode.attachChild(g2);
Quad q = new Quad(10,10);
Geometry g3 = new Geometry(“quad”,q);
g3.setMaterial(mat);
// TangentBinormalGenerator.generate(g3); // activating will darken both quads (same mesh?)
g3.setLocalTranslation(-5, 7, 0);
rootNode.attachChild(g3);
// top-right: Quad - will change lighting if looking up or to the left
Quad q2 = new Quad(10,10);
Geometry g4 = new Geometry(“quad2”,q2);
g4.setMaterial(mat);
g4.setLocalTranslation(9, 7, 0);
// TangentBinormalGenerator.generate(g4); // activate this and lighting is stable but too dark
g4.updateModelBound(); // doesnt help
g4.setModelBound(new BoundingSphere(10,new Vector3f(4,12,0))); // doesnt help
g4.setCullHint(CullHint.Never); // doesnt help
rootNode.attachChild(g4);
// light & cam
addSun(100, rootNode);
cam.setLocation(new Vector3f(65,25,65));
cam.lookAt(new Vector3f(50,15,50), Vector3f.UNIT_Y);
flyCam.setMoveSpeed(10); // control camera the with WSAD camera, not the player!
}
private void addSun(float distance, Node attachTo){
Vector3f sunPos = new Vector3f(distance,distance,distance); // sunlight goes-to this point
DirectionalLight s1,s2;
s1 = new DirectionalLight();
s1.setDirection(sunPos.negate()); // what does normaliseLocal do here?
s1.setColor(ColorRGBA.White);
attachTo.addLight(s1);
s2 = new DirectionalLight();
s2.setDirection(sunPos);
s2.setColor(ColorRGBA.White);
attachTo.addLight(s2);
}
}
[/java]
The Class comment explains what you need to do to see the sudden changes in lighting.
Just starting the test case will show you that the quads lost a lot of their luminance compared to the cubes (= what they should have).
I’m beginning to guess there is a problem in the shader that causes the loss of brightness (or gain of brightmness if youve lready lost it).
Using the TangentBinormalGenerator ‘fixes’ it by clamping down the brightness level to the low value, which is not what you want either.
That, or a camera issue but you’d expect complete culling, or something else… Weird problem with no solution sofar except using simple textures which would be a real waste for my game.
Can you test and give me your thoughs/advice?
Anyone else having this issue?
I’m revisiting this problem I have and would still like to know if it’s a jme3 thing or if it’s a problem on my side.
Could anyone run the above code and tell me if they have the same issue (as described in the header) ?
Thanks.
I’ve tested it, quads and qubes look the same when I move, when I come closer and strafe to side while looking at quads, one of them “blinks” becomes lighter for sec or two and then goes back to normal. Same thing happens to the second quad when if I keep moving past it…
Note: just in case it turns out to be part of the issue… in the latest code, I think lighting.j3md makes everything not directly lit super dark unless you also have an ambient light in your scene.
…though if it isn’t yelling at you about all of the “m_” prefixes in your materials then you may not be running the latest… in which case you may want to upgrade.
…and actually, curious, which jme3 version are you running? Stock alpha 3 or a nightly of some sort?
Edit: of course I just notice how old the original topic is. Still an issue?
moonkey said:
I've tested it, quads and qubes look the same when I move, when I come closer and strafe to side while looking at quads, one of them "blinks" becomes lighter for sec or two and then goes back to normal. Same thing happens to the second quad when if I keep moving past it...
The test case given doesn't call TangentBinormalGenerator.generate() which is required to achieve correct results.
With the calls uncommented, the result appears as expected. The "brightness" issue doesn't exactly make sense either, if the scene is too dark, you can add an AmbientLight or double the brightness of your directional lights.
This is not a jME3 only thing. I’m having similar ‘blinking’ happening in jME2