When calling lockMeshes() on instances of Point and Line, those objects are no longer rendered.
I've tried calling lockMeshes() and unlockMeshes() in simpleUpdate() method with a time interval of several seconds between toggling locked-unlocked. The results are: when the meshes are unlocked the object can be seen, when the meshes are locked several seconds later, the object disappears and does not reappear until the meshes are unlocked again.
Since the testing was done using SimpleGame with only one thread, this cannot be the OpenGL-thread issue. I suspect this could be a bug.
but it expensive and so instead, if you use lighting without normals, the results are unspecified.
Fair enough! A nice Javadoc section in a couple of places explaining this would be nice ;)
I have retested the same code with a quad:
When lockingMeshes on a quad, the quad is still rendered, while locking meshes on points and lines causes them to disappear.
lockMeshes… (not called lockLines/Points) :P No but seriously, if you would kindly whip up a quick test case I'll solve it.
One test case coming up… (10 mins) 
Ok, here a test that every few seconds toggles "lockMeshes() - unlockMeshes()" on a box, some lines and some points. The box stays intact, while lines and points blink.
import java.util.logging.Level;
import java.util.logging.Logger;
import com.jme.app.SimpleGame;
import com.jme.bounding.BoundingBox;
import com.jme.math.Vector3f;
import com.jme.renderer.ColorRGBA;
import com.jme.scene.Line;
import com.jme.scene.Point;
import com.jme.scene.shape.Box;
import com.jme.scene.state.MaterialState;
public class LockTest extends SimpleGame {
private float runningTime;
private float toggleDelay = 2;
private float toggleTime = toggleDelay;
private boolean locked;
private Line lines;
private Point points;
private Box box;
public static void main(String[] args) throws Exception {
Logger.getLogger("").setLevel(Level.WARNING);
LockTest game = new LockTest();
game.setDialogBehaviour(LockTest.ALWAYS_SHOW_PROPS_DIALOG);
game.start();
}
@Override
protected void simpleInitGame() {
Vector3f[] samples = new Vector3f[3];
samples[0] = new Vector3f(0, 0, 0);
samples[1] = new Vector3f(10, 10, 0);
samples[2] = new Vector3f(0, 5, 10);
// lines
lines = new Line("lines", samples, null, null, null);
lines.setMode(Line.CONNECTED);
lines.setDefaultColor(ColorRGBA.blue.clone());
MaterialState ms = display.getRenderer().createMaterialState();
ms.setColorMaterial(MaterialState.CM_EMISSIVE);
lines.setRenderState(ms);
lines.setModelBound(new BoundingBox());
lines.updateModelBound();
rootNode.attachChild(lines);
// points
points = new Point("points", samples, null, null, null);
points.setDefaultColor(ColorRGBA.red.clone());
points.setPointSize(10);
points.setRenderState(ms);
points.setModelBound(new BoundingBox());
points.updateModelBound();
rootNode.attachChild(points);
// polygonal object
box = new Box("box", new Vector3f(0, -10, 0), 5, 5, 5);
box.setModelBound(new BoundingBox());
box.updateModelBound();
rootNode.attachChild(box);
}
protected void simpleUpdate() {
runningTime += tpf;
if (runningTime > toggleTime) {
toggleTime += toggleDelay;
if (locked) {
lines.unlockMeshes();
points.unlockMeshes();
box.unlockMeshes();
locked = false;
} else {
lines.lockMeshes();
points.lockMeshes();
box.lockMeshes();
locked = true;
}
}
}
}
Thanks for taking the time. It really makes development a lot easier.
Ok, was an easy fix. Still see an interesting color shift in lines which may require further eval, but it'll do for now. Expect it in CVS soon.
Hmm… in the process of tracking down the color issue, I found a color bleed problem with all locked meshes. This is fixed. Now tracking down an issue with mesh and line lists being called one after the other.
Yeah, there were some differences: when i had lines and point but no box, they were visible without setting colorMaterial. But after adding a box, lines and points became very dark, so i had to add colorMaterial state.
Yeah, it is because the box's normals are bleeding into the lines/points somehow. I have not figured out how yet.
Ok, finished troubleshooting this. There were a few things in lists we could handle better, but the color shift is due to using lighting without specifying normals. In the case of your lines and points you'd probably want to just set the lightcombine mode to LightState.OFF. We could do some things in the renderer to preserve the default current normal value, but it expensive and so instead, if you use lighting without normals, the results are unspecified.
I think so too. Any suggestions on where you'd look first if you were having this issue? Perhaps the FAQ. OpenGL's FAQ has similar lighting bullets.
The first place I would look is Javadoc for the lockMesh() and lock() methon on Line and Point classes.
Yeah, except that those classes do not override those methods… plus this is a problem anywhere you use lighting without defining normals. You can see it for yourself by nulling the normals on your box. It's also really "undefined" for non-locked objects.
As far as lines and pionts go, you can say in javadoc of the constructor "when specifying null for normals, LightState.OFF should be used". You can also put a comment like that on constructors for Geometry and/or GeomBatch classes and also for get/set methods for normal buffers.