We had a little discussion about how to do lighting in jPCT here:

http://www.jpct.net/forum/viewtopic.php?t=70

As you can see from the thread above, lightmaps (or multiple u/v-coordinates) are not supported ATM. You may ask yourself, why both features you asked for are not present in the current version. Maybe this thread can answer this:

http://www.jpct.net/forum/viewtopic.php?t=89

Hope this helps.

Mir ist nicht ganz klar, was du mit "GUI für Applets" meinst? Eine Entwicklungsumgebung für Java? Evtl. mit einem GUI-Builder drin? Falls ja, dann empfehle ich JBuilder9 in der Personal Edition. Die gibt es (kostenlos) hier:

http://www.borland.com/products/downloads/download_jbuilder.html

Du musst den JBuilder (leider recht groß) und den Schlüssel runterladen. Damit bekommst eine ,wie ich finde, nette Entwicklungsumgebung, in die man dann auch die jar-Files in jPCTs lib-Verzeichnis einbinden kann und dann kannst du damit loslegen.
Ansonten gibt es nicht Ellipse und Netbeans, aber ich persönlich kann dazu nicht viel sagen, da ich sie kaum verwendet habe.
256MB sollten es für jede dieser Umgebungen aber schon sein. Was die Tutorials angeht: Die sind nicht von mir und ich weiß nicht, wie da der Stand ist und ob da noch was passiert. Ich habe hier zwei Vorversionen davon rumliegen, aber die möchte ich nicht einfach ohne Einverständnis des Erstellers "freischalten".

Calling build() on anything that isn't a dummy object is required in almost every case (or call World.buildAllObjects()...but that can only build the objects that have already been attached to the world). I thought about handling this internally, but there are too many places in the code, where a correctly "builded" object is required, so this would result in a gazillion of "if (!hasBeenBuild) {this.build();} in the code and that's quite ugly.
Another problem is, that the engine can't decide if it's a good time to build an object or not.
That's why it's up to the user to call build(). However, calling build on the template is sufficient. There's no need to call it on cloned objects because they inherit the mesh data from the source.

I just installed a Linux on a spare machine and got jPCT to work without a hassle. The command line looks like this:

java -Djava.library.path=lib/lwjgl-0.8/ -cp lib/lwjgl-0.8/lwjgl.jar:jpct.jar ......

You still need to download the Linux binaries for LWJGL of course.

Not sure I understand - it's seems very complex! I wasn't sure how the problem manifests itself - are you saying that the collision detection becomes inaccurate when it exceeds a tick?

No, it doesn't get inaccurate and yes, it seems to be complex...but it isn't. The problem lies in the way the movement of the camera and/or objects is synchronized with the framerate. The current approach assumes that collision detection doesn't consume much time compared to the rendering itself. It's a bit difficult to understand...that's why i wasn't aware of it for some time (and maybe why i killed a thread in another forum with this question... :wink: ). An example: Imagine your job is to make one step forward for every second that has elapsed (that's the "collision detection") and then say "blahblah" (that's the "rendering"). You start at 0, so you just say "blahblah". After that, 1 second has passed and you make one step (which takes a second too in this example) and say "blahblah" again. Now you have to make 2 steps, because two seconds have passed since the last time you moved forward (one during the first step and one while saying "blahblah")...then you have to make three steps, then four...and finally, you are just walking forward without saying "blahblah" in a reasonable time. If we modify this example and assume that the step takes not one second, but 1/10th of a second, it's no longer a problem.
I think a solution would be to ignore the time spent in the collision detection and just count the rendering time. This may lead to slower movement in some situations where a lot of collisions are taking place, but does that really matter...
Anyway, i don't think that this will happen to you...i never happened to me except in a special test case. But if it ever does, you may remember this thread... :wink:

I haven't implemented any collision detection yet

Oh, you actually did: the camera-world collision detection.

I've moved all the movement code into the main thread, just before performing rendering and all the other draw operations.

All the jerkiness has disappeared. *much* better.

Yes, it's much better this way. However, movement speed seems to depend on framerate now. It's a good idea to keep the timer thread but only to generate "game ticks" and move according to the number of ticks passed since the last frame. The fps-example is doing this for example.

Well, it's possible to set an additional color for an object (using Object3D.setAdditionalColor(java.awt.Color col)). But lighting is multiplicative when using the OpenGL/SoftGL-renderer and so the object will look like fully illuminated even if it isn't...but it won't look white.
The only way to achieve this, is to replace the texture for the object with a white one (but that's rather slow and works only if the object has one texture only (like an MD2-model or similar)) or by replacing the texture of the object in the TextureManager using TextureManager.replaceTexture(...). Problem with this is, that you'll replace the texture for all objects using this texture. It could be possible to do something like this:



// init
Texture t=new Texture(...);
texMan.addTexture("tex1", t);
texMan.addTexture("tex2", t);
texMan.addTexture("tex3", t);

obj1.setTexture("tex1");
obj1.setTexture("tex2");
obj1.setTexture("tex3");

// replace

texMan.replaceTexture("tex1", whiteTexture);
texMan.replaceTexture("tex2", redTexture);
texMan.replaceTexture("tex3", blueTexture);

...

// replace again

texMan.replaceTexture("tex1", t);
texMan.replaceTexture("tex2", t);
texMan.replaceTexture("tex3", t);



But i never tried to add the same texture multiple times to the Manager that way...it should work, but i'm not sure.

Hope this helps.

0.98 is out and therefor i've removed the beta-jar. Now you can use the official version of it...it includes the refresh()-method as well as some other stuff.