I supposed there was going to be a performance problem about the distant stars background, but I wonder if it could be mitigated somehow, like drawing them like points instead of using a texture, for example (and perhaps not drawing many many stars). By the way, is there a way to draw points instead of polygons? Would it be faster if there was one? To apply a texture on the sphere would be the wiser approach?

Drawing points would still require a zbuffer read/compare. Maybe the best (or at least a reasonable) solution is to use actual objects placed on a sphere instead of the textured sphere. They can be stars, distant galaxies etc...that way, you are saving fillrate and are getting a higher flexibility. At least until you insist on hundreds of stars in the background, which i think you don't.

Another thing: My "Map" contains currently 40x40x2 Triangles. when I build a octree with it, I get a stackoverflow. isnt it meant to be used on big objects?

There are situations, where the subdivision of an object fails and the recursion never ends...i can't remember exactly when this happens, but there should be a thread about it IIRC. To prevent this, you may create the octree with a maxDepth (5 or 10 or whatever) by using the corresponding constructor. What's your setting for maxPoly for that tree (shouldn't be lower than 100 IMHO)?

Edit: A little more on this subject: jPCT doesn't split polygons for creating an octree. It just tries to decrease polygon count in a node by subdividing the node if needed. On some objects, this doesn't work, because the polygons already cover the whole node. There is no way to decrease their number by subdividing that node...they will just cover it even more. By limiting the depth, you make jPCT stop at a certain depth.

I see...your plane is quite huge. ATI's per pixel fog implementation is actually per vertex, which can produce strange results when polygons are quite huge. I've already noticed that but never investigated it further. I suggest to split the plane into smaller ones. The lighter/darker effect you are experiencing has the same source. It's linear interpolated across the polygon. Depending on where the actual vertex of a polygon is located, the result may change.
In a real world application, you shouldn't use planes that large anyway, because it will cause lighting to show similar problems.

If it's the same model (or maybe just with different textures), you can load it once and use cloneObject() in Object3D on it to create your additional instances. That will reuse the mesh and animation data. If the current state of the animation is different for all models, it's additionally required to clone the Mesh because otherwise a call to animate() on Object 1 will influence Object 2. So the idea is basically:


Object3D newAnimObj=oldAnimObj.cloneObject();
newAnimObj.setMesh(newAnimObj.getMesh().cloneMesh(true));


In addition, you may set Config.saveMemory=true.
For reference: Paradroidz runs with -Xmx256m and uses around 128m of this . It uses around 3100 Object3Ds which it holds in that memory all the time.
Keyframe animation, however, is expensive in terms of memory usage.

Edit: The current WIP of 1.09 already includes a change suggested by raft that strips some unused information from meshes that are used for animation only. I may add this change to Animation itself somehow. It should help too...

About drawing distant stars: they are just for decoration; the camera can move around, but I would set a limited volume in which it can do it, so these distant stars would remain always distant.

Then a skybox or -sphere should be sufficient. But that eats up your fill rate for the software renderer. Are you planning to use soft- or hardware rendering?

Something like using the Java API to draw the characters on an image and then applying the image as a texture on the billboarded quad would be the right approach?

I guess that you'll generate them once and use them from there on? Then you are fine to draw an image using standard Java2d stuff and upload that as a texture. If the text changes a lot, you should compose your texts from various texture parts instead (see below).

- Drawing distant stars as points (maybe on some huge sphere that contains the whole scene) that must rotate as the scene does.

Possible IMO, but the way i'm thinking of requires some work to do it. Are these stars actually reachable or just for decoration?

- Drawing each planet's name under it (so I need a way to draw characters that are always looking at the camera, whatever its position).

Possible . You could use a billboarded quad (will grow/shrink depending on the distance, text may be hard to read if too small) or blitted text (will always have the same size, always be readable but doesn't take overlapping into account). It depends on your needs which way is better.

Hope this helps.

Here's the hires version: http://www.jpct.net/download/jPCT_logo.png

Regarding mac os - i had similar problems and i thought they are somehow connected with javagamesfactory which goes down sometimes. Try again today

Javagamesfactory in its current is unusable IMHO. It's down very often. And if it isn't, just try to upload your files once or twice and see it stop responding. The administration is buggy as hell. I'm usually tearing my hair out to make it do what i want it to do. The JNLP created most be from hell. The only thing it does reliable is to blame others for their stupidity (have a look at the html sources). I would never rely on JGF alone to host my stuff. I love the idea behind it though.