Egon, I have a game that uses a sky sphere object that I wrote years ago. Now I want to convert it to the util.Skybox, because it's so much easier to deal the textures (not to mention easier to find stuff for). Problem is that this game requires me to collide with the sky. I could keep the sphere just for the collision bit, but I'd much rather be able to collide straight with the skybox (for one thing, it would save a good deal of polygons and for another it would be better for future games!). The best way to do this, I think, would be to get a method like Skybox.getObject3D(). Would you be willing to do that?
The SkyBox-class has a getWorld()-method. You can access the skyboy object from this world.
How?
Just use the Enumeration of Object3Ds. The first (and only) one is the skybox.
To be perfectly honest, I never used it. Could you just point me in the right direction?
Something like:
Object3D boxObj=(Object3D) skybox.getWorld().getObjects().nextElement();
Thanks a lot. But the question that follows is: isn't this a little clumsy? After all, I have no way of testing for whether I got the right object.
Yes, it is. But you can simply extend SkyBox and add a getObject3D()-method that does this internally, if you want to hide it from the rest of the application. But "what if" this changes?...well, it won't. You can rely on the fact that the first object returned will be the sky box.
OK, thanks. Would you add that to the docs for future reference?
Yes, i already did that.
Thanks.
Scratch what I just wrote afterwards, I just got it. :- )
Now I'm really going to sound like an idiot (it's a Java 5 quirk that I've never used too much):
theWorld.getObjects().nextElement().addCollisionListener(this);
doesn't work. I don't know whether I should (and where as I've tried on both ends of theWorld.getObjects().nextElement() put <Object3D>. And it can't find addCollisionListener without it.
I typecast it hope it works. Now here's another question: what happens when I replace the skybox (to change between levels)? Do I just keep calling nextElement()?
Again, I'm going to emphasize how clumsy this is.
If you replace the instance, the world inside will be replaced too. If you can't get used to use the Enumeration (it's exists since Java 1.1...i'm not sure what you mean with Java 5 quirk...), just extend the SkyBox class, implement it once and forget about it.
What do you mean? When I change levels, I call World.removeAll(). I don't reinitialize the world.
The <...> stuff (instead of good old typecasting) is a Java 5+ thing.
By the way, I'm not having any success in rotating the Skybox to match the game's orientation (the X/Y plane instead of the X/Z one).
You might call that on your world, but not on the SkyBox' world, don't you? I wouldn't make any sense. Just create a new SkyBox instance, don't fiddle around with its internal world for this.
The sky box is static, it doesn't move at all. All that happens is that the internal world's camera will be adjusted to match the rotation of the one in your world when you call render(..) on the sky box. It should be possible to rotate the sky in any way you like. At least i've no idea why it shouldn't.... ???
Quote from: AGP on December 18, 2011, 09:22:12 PM
The <...> stuff (instead of good old typecasting) is a Java 5+ thing.
Yes...and i would have used that, but that would have broken compatibility with older Java versions. I lost 1.1 compatibility anyway because you can't compile to 1.1 with anything higher than the 1.4 compiler and i can't use the 1.4 compiler any longer, because it can't read the latest lwjgl-jars. So jPCT is now compatible to 1.4 and up instead of 1.1 and up. But still no generics support. When you look at jPCT-AE, you'll notice that the i'm using them there.
I didn't know it was on a separate World instance. Seems counter-intuitive. Would you add that to the docs? The code
skyboxObject.rotateZ((float)Math.PI*-.5f);
skyboxObject.rotateMesh();
skyboxObject.clearRotation();
skyboxObject.build();//JUST IN CASE BUT PROBABLY UNECESSARY (AND UNDESIRED)
doesn't work.
No, doing a rotateMesh() won't work, because the sky box is a compiled object and it already has been compiled at that stage. Just do the rotation and leave out the rest.
That makes sense. So the rotateMesh() wasn't doing anything and clearRotation() was undoing the rotation.
Here's another question: is collision with the Skybox possible for the player character? It seems to me that it's translating along with the camera (which it probably is, come to think of it).
Anyway, to circumvent the issue, I'm cloning it. The initial skybox will have the size of the entire level, then I apply the following code:
skyboxObject.rotateX((float)Math.PI*.5f);//CAN'T rotateMesh() OR clearRotation(): IT'S COMPILED
skyboxObject = skyboxObject.cloneObject();//CLONE IT SO skyboxObject IS A SNAPSHOT OF THE Skybox AS IT WAS CREATED AND DOESN'T MOVE ALONG WITH THE CAMERA
skyboxObject.setCulling(false);
skyboxObject.setCollisionMode(Object3D.COLLISION_CHECK_OTHERS | Object3D.COLLISION_CHECK_SELF );
skyboxObject.setCollisionOptimization(true);
skyboxObject.addCollisionListener(this);//Skybox.addCollisionListener()
And I am setting the skybox visibility to true before checking for collision. No collision is happening.
Yes, in theory it's possible. The sky box rotates with the camera, but it doesn't move. However, if you are in a situation where you collide with the sky box, your sky box was probably too small...
Quote from: AGP on December 19, 2011, 07:39:00 PM
And I am setting the skybox visibility to true before checking for collision. No collision is happening.
Keep in mind that the sky box consist of some very large polygons. You need a pretty high collision offset in Config to detect a collision with that. However, why do you want to detect collisions with the sky box in the first place? Wouldn't it be sufficient to make a simple distance check instead?
Sure, if you want to be rational. :- ) But this was a game I made some six or seven years ago (jpct was way under version 1 then). That must have been the first idea I had. I was just trying to do a straight conversion just now, but I suppose I may as well change it now.