Not sure if this will help you much, because the bubbles are managed in a reeeeaaalll simple way, but anyway:

for (int i=0; i<NUMBER_OF_BOXES; i++) {
         Object3D box=Primitives.getSphere(4,1);
         box.calcTextureWrapSpherical();
         box.setTexture("wood");
         box.setTransparency(0);
         box.setEnvmapped(Object3D.ENVMAP_ENABLED);
         box.setCollisionMode(Object3D.COLLISION_CHECK_SELF);
         box.setOrigin(new SimpleVector(140,0,-117));
         setBox(box, i);
         box.translate((float)Math.random()*-140, 0, (float) Math.random()*117);
         theWorld.addObject(box);
         boxes[i]=box;
}

And the code for setBox():

private void setBox(Object3D box, int i) {
      float x=15f-30f*(float) Math.random();
      float y=20f-40f*(float) Math.random();
      float z=15f-30f*(float) Math.random();
      box.setTranslationMatrix(new Matrix());
      box.translate(new SimpleVector(x, y, z));
      float trXn=1.5f+2f*(float) Math.random();
      float trZn=1.1f+2f*(float) Math.random();
      trX[i]=trXn/2f;
      trZ[i]=trZn/2f;
      lifeTime[i]=0;
      box.rotateX(x);
      box.rotateY(y);
      box.rotateZ(z);
}

The bubbles are stored in the array named boxes (they were boxes in the first version... :wink: ) and their current translation in X and Z direction in trX and trZ. In addition, the lifetime of each bubble is stored in the lifeTime[]-array. But this is ugly code written to serve a single purpose. It would be better to wrap this information into an object (or maybe to extend Object3D, which sadly isn't possible in 0.97 but will be possible in 0.98 because i'll get rid of the useless final-stuff) and manage these objects by a simple Manager-class. If you don't want to write such a wrapper class and go with the array-approach, the Manager is still a good idea because it can hide this fact from the rest of the code.

Hope this helps.

There's some bad poly overlap in places, mainly due to my abilities with 3dsMAX - I'm still getting to grips with it. My next effort should be considerably cleaner.
.......by the way - that fps source was fantastic.

Yes...i noticed that there seems to be one (or some) large polygon below the street's actual polygons which "shines through" due to inaccuracies in the zBuffer (caused by the nature of it...nothing i can do about it). That's causing most of the z-fighting problems and it hurts fillrate and the octree. You should try to get rid of it IMHO.
The newer versions of the fps-code are even better... :wink: (No multi-threading issues anymore).
Keep up the good work. I really like the mood of this level.

No, it doesn't support lightmaps/multitexturing but vertex lighting. You can bake your static lighting into the textures if you want to, but you have to do this yourself. The reason for not supporting lightmaps/multitexturing is performance of the software renderer. It's the price you pay for the flexibility.
About the animation: You can do keyframed animations by either creating the animation in your code (by combining several meshes into an Animation) or by using the MD2-loader to load MD2-models. Using the animation out of a 3DS-file is not supported as it would require a completely different animation framework.

Hope this helps.

BTW: What kind of game are you planning to make?

Testing the ships for collision with the player should be fine. The demo i mentioned above does the same between the bubbles and the alien. It displays approx. 100 bubbles.

The amount of objects that may belong to a world is unlimited (in theory...in practise, memory usage and performance will limit it of course). However, letting the engine determine which objects are visible among 1,000s of them is not a good idea performance wise. Maybe it's possible for you to use a pre-processing stage based on the logic of your game to determine what may be visible and what isn't (divide the space into sectors or whatever...). With this information, you can either set some objects to visible/invisible as needed or remove them from the collection of objects if not needed and add them again if needed. The second solution may not be a good idea if it happens a lot, because removing them is not that cheap.
Note that you have to call build() only once on an object. It's not required to be called everytime you add it.
How much is "infinitely" in your case?

Another possible solution is to place the camera behind the object by getting the object's transformed center and translate it somehow (i.e. as needed in your case) by evaluating the results from the get?Axis()-methods of the object. Somehow like:


SimpleVector tc=object.getTransformedCenter();
SimpleVector pos=new SimpleVector(tc);
SimpleVector zAxis=object.getZAxis();
SimpleVector yAxis=object.getYAxis();
zAxis.scalarMul(5f);
yAxis.scalarMul(2f);
pos.add(zAxis);
pos.add(yAxis);
theWorld.getCamera().setPosition(pos);
theWorld.getCamera().lookAt(tc);


Please note that i haven't tested this and typed it out of my head, so i could be totally wrong here...

"Riding around" on moving entities actually isn't a problem that can be solved with collision detection alone. It's  something the game logic has to handle. Albeit i haven't implemented it myself yet, i suggest to simply apply the transformations of the moving entity to the camera (or the object, which can be done using object hierarchies) if the camera/object collides (and that's where the collision detection can be helpfull) with the entity or is close to it or has activated a trigger or whatever.
Where the recent changes of the collision detection code help is when an entity itself moves into the radius of the collider's ellipsoid in the opposite direction of the collider's translation. Like an elevator that moves up and the collider standing on the elevator moves down due to gravity. The former code couldn't handle this case, because the ellipsoid collision detection tries to avoid collisions before they happen, but in this case there could already  be a collision when the detection starts. Now, the ellipsoid collision detection will adjust the colliders translation so that it moves out of the collision first. Due to the way how ellipsoid collision detection works in jPCT, this can only work fine when it's possible to avoid the collision by translating the collider in the direction of its current translation vector (or in the opposite direction, i.e. by multiplying it with a scalar). This is due to the fact that this method usually uses sliding planes and not (like the spherical collision approach) the face normals to adjust the translation. Well, it's kinda hard to explain.. :? ..to summarize this: You can do elevators with this modification (look at the updated fps-example) but it doesn't work as a "push me out of any collision there is"-approach. That's what the spherical approach is for.

Hope this helps!

At the moment: No, i'm sorry. This isn't possible. But i was thinking about this topic yesterday (what a coincidence... :shock: ) but i'm still a bit undecided how to do it. I think i have to use an approach similar to the vertexcontroller. A kind of "TriangleController".
Is this a vital feature for you or "just" nice to have.