I made the ground texture as bright as possible to avoid this issue (no such luck). For some reason if instead of merging all the ground parts I add them as children of one of the parts (in order to test for what's the ground and not calling setTransparency(100) on it) I don't get a collision with the ground (and I am individually calling setTransparencyMode and setCollisionOptimization on the individual parts). Which brings us to this problem: all of the trees in this image are actually set behind the hills ahead and should therefore not be visible. What's odd is that the ground doesn't really appear to be transparent (seems more like a Z-buffer issue).
(http://ratto.co/jpctTransparency.jpg)
setTransparency(100) is almost opaque, so you won't see much of a transparency. But you still get the sorting and based on the midpoint, the terrain will be sorted behind the trees...and that's what you are getting here. Why do you set the terrain to transparent at all? Don't do this and the issue with the trees will go away.
Because the trees have to be part of the terrain. When I tried making them children, I got the aforementioned problem with collision. They HAVE to be merged to the ground, and, naturally, they need their transparency.
QuoteThey HAVE to be merged to the ground, and, naturally, they need their transparency.
No, they don't have to and shouldn't be part of the terrain. You'll never get correct sorting between the terrain and the trees that way plus you are killing fillrate for no reason by rendering everything with alpha. I don't get the actual problwm with collisions...who collides with what here and what doesn't work if the trees remain separate objects?
calcMinDistance, for some bizarre reason, doesn't work when I don't merge the trees to the ground. I don't get it either, but when I do merge everything collision works like a charm.
Quote from: AGP on June 18, 2012, 10:04:34 AM
calcMinDistance, for some bizarre reason, doesn't work when I don't merge the trees to the ground. I don't get it either, but when I do merge everything collision works like a charm.
Makes no sense to me. Maybe you are missing some operations you are doing on the terrain when merging anything that prevent the collisions from working like not setting the collision state by accident or setting it for the wrong object or something like this.
No, I looked it over for hours. Only thing that got them to be triggered was treating everything as one model. The loop which added the objects as children of the ground had an exact copy of the code for the merged ground.
That can't be. Something has to be different....
Here's my loop:
ground = Object3D.createDummyObj();
Object3D[] parts = Loader.loadOBJ("NewLevel/Forest.obj", "NewLevel/Forest.mtl", 1f);
for (int i = 0; i < parts.length; i++) {
if (!parts[i].getName().startsWith("ground"))
parts[i].setTransparency(100);
parts[i].setCollisionMode(Object3D.COLLISION_CHECK_OTHERS);
parts[i].setCollisionOptimization(true);
parts[i].addCollisionListener(this);
theWorld.addObject(parts[i]);
if (buffer.usesRenderer(IRenderer.RENDERER_OPENGL))
parts[i].compileAndStrip();
ground.addChild(parts[i]);
}
ground.rotateX((float)Math.PI);//WHY IS IT UPSIDE DOWN RIGHT OUT OF MAX?
ground.translate(0, 30f, 0);
for (int i = 0; i < parts.length; i++)
parts[i].enableLazyTransformations();
OK...and how does the merge part looks, i.e. the version in which you merge everything into one large lump?
BTW: Are you calling build() on each part of parts[] somewhere? I just want to be sure, because i don't see it in this code snippet.
Yes, I call world.buildAllObjects() much later in the method. The "original" code looked exactly like that. I'm sure I'm not missing anything. Am I? Perhaps the order of the operations is wrong?
Well...i meant the variant that merges all trees with the terrain. That can't be that code snippet, because i don't see any merge operation at all... ???
Like I said, exactly the same but with mergeAllObjects and without a loop. I didn't comment it out, I moved the original code, not necessarily in the same order, into the new loop (for an older version I have to go home and post it--but other than the order of the operations it is exactly the same).
This code works (but produces the transparency issue):
private void loadGround() {
ground = Object3D.mergeAll(Loader.loadOBJ("NewLevel/Forest.obj", "NewLevel/Forest.mtl", 1f));
ground.setTransparency(100);
ground.setCollisionMode(Object3D.COLLISION_CHECK_OTHERS);
ground.rotateAxis(ground.getXAxis(), (float)Math.toRadians(180));
ground.translate(0, 30f, 0);
ground.setCollisionOptimization(true);
ground.addCollisionListener(this);
theWorld.addObject(ground);
skyBox = new SkyBox(800);
if (buffer.usesRenderer(IRenderer.RENDERER_OPENGL)) {
skyBox.compile();
ground.compileAndStrip();
}
theWorld.buildAllObjects();
ground.enableLazyTransformations();
}
The main difference between the two seems to be the use of a common parent object in the upper one. Albeit this should work, maybe there is some problem related to it.
Please try:
- remove the calls to enableLazy...
- get rid of the common parent object
to see if any of that helps.
No change whatsoever. Still doesn't work as multiple parts.
I take it back: it worked. And it's not enableLazyTransformations() (I've since added it back and it still works).
So getting rid of the parent did the trick?
Yes, but it also created a new problem: since I have to rotate everything around the X axis by 180 degrees and I no longer have a parent, the trees are getting buried in the ground. Should I just rotate the trees around the the ground's X axis?
If that works...!? I'll try to find why it doesn't work with a parent being added. It actually should...
Naturally, that was a stupid before-I-went-to-sleep idea that didn't work. So if I could have my parent/child relationship back, I'd appreciate it.
What exactly are you using to trigger the collision?
calcMinDistance()
I can't verify this problem. I created a test case but it worked just fine. Are you sure that your direction vector in calcMinDistance is a unit vector (i.e. normalized)? If everything looks fine to you, i need a test case for this.
I'm sure. I'll send you one in a couple of hours.