I think it's a problem with the order in which you are doing things. The 3DS-loader will look for materials (i.e. texture names) in the file and then, it tries to get a matching texture from the TextureManager. If there is none, a new one with this name will be created. If you try to add another texture with this name later in the code, you'll get this error. So you either have to move the loading of your textures to a position before you load the object(s) or you have to use the replaceTexture()-method in the texture manager to replace the white dummy texture with that name with the correct texture.

Hope this helps.

That means that files is null, which means that dir.list() returns null, which means that your "textures"-directory doesn't exist. At least not there where you expect it to be. Try the complete path (i.e. "c:\blah\blubb\...\textures" or similar) and see if that works.

The exception happens somewhere in your code. What exactly is in line 238?

Well, getDocumentBase() returns an URL, which can simply be printed out. I doubt that this will reveal anything new, but i would like to know if getDocumentBase() really returns the same URL with and without the certificate. If it does and you say that the textures are loaded correctly, just not displayed, i suggest to double check your code. Maybe you are doing something when loading the file that causes this behaviour.

Strange...do you get an error message? Maybe signing the applet affects the document base?? I'm just guessing here, but it could be helpfull to know where getDocumentBase() points to in both situations.
Is your applet in a jar file? If so, maybe putting the textures into that jar and loading them from there using an InputStream will work...

Changes are documented here: http://www.jpct.net/changes.html

Have fun!

I don't think so. At least i don't know of a way to make Javascript on a web page run when triggered from inside the applet. I suggest to use polling instead. Do something like


window.setInterval("pollApplet()",250);
.
.
.
funtion pollApplet() {
   var temp = document.applets[0].feritoID;
   // Do stuff with "temp" here  
}

This will set temp to feritoID every 250ms.

Cooool...i'll have a look at your code for sure. The funny things is, that jPCT already has an OBB (i.e. the tranformed AABB) for each object. It's just not public. Maybe it should be...

Currently, it's used for collision detection in a way that rays/spheres/ellipsoids are checked against it before work starts on the polygon level (if it has to, i.e. if there is an intersection).

Anyway, i got the oriented ellipsoid stuff working too. At least i think i did...it requires some more testing. However, i think that your OBB-approach is very well suited for cars, because they are just boxes...basically... :wink:

Selectable is default. You don't have to enable selection on desired objects but disable it on all others. What i don't understand is, that the unselectable objects doesn't block the ray to prevent the "rest of the world" from being picked. Then again, i don't know how your world looks like exactly, so i guess that this is a correct behaviour in your case. I double checked the picking code and can't find anything wrong with it.

Fine, but i'll look into this 120-issue...i don't see a reason for this behaviour. If nothing has been selected, null should be returned. Not an array containing nonsense values.

Edit: Please let me know if an object with ID=120 really exists (even if you haven't created it yourself). Try to get the actual object with this ID from World by calling getObject(int id). If such object exists, please tell be the name of it (getName()). Or does getObject() returns null and prints out an error?

No, 120 isn't a default ID or whatever. If 120 is reported, an object with this ID has been selected, unless the method is faulty which i'm not aware of.
However, it may be related to the fact that you call the picking all the time, not just when a mouse button has been pressed. I assume that your mouse-click-method sets mouseX and mouseY? If so, let it set a flag like "clicked=true" too and do the picking only if this flag is set (and reset it afterwards). See if this fixes your problem.
The picking doesn't care if a mouse button has been pressed or not. It just fires a ray into the scene according to the coordinates you give it. If you do this every frame, so be it...
If the "120"-problem remains, please try to find out which object's ID this is and where it is located.

Have you implemented a KeyListener together with the MouseListener?

It's a fixed version that will work everywhere. The problem was, that i allocated a ByteBuffer in native order, where i should have one allocated in LITTLE_ENDIAN. This works for Intel, because native order is LITTLE_ENDIAN there...but on Mac, native order is BIG_ENDIAN. The ByteBuffer is now always LITTLE_ENDIAN regardless of the system.

About your input problems: This is most likely a LWJGL problem. The fps-example uses two different approaches to query the keyboard. The SUN-like approach is used when using software rendering and the LWJGL-approach when using LWJGL. If this doesn't work, it's either a problem of LWJGL for Mac or i'm doing something not 100% right to query the keyboard. Then again, there's not much room to do things wrong...

Have you tried fullscreen mode on Mac? Maybe the keyboard will work there!?

You are right: The ellipsoid doesn't get transformed like the object. It always remains "axis aligned". It's on my to-do list to see, if i can do something about it. Currently, the algorithm basically works like this:

The camera/object that should be checked for a collision is transformed into the collider's (the "target" of the collision) object space. The collision detection itself is taking place in ellipsoid space, which is a scaled variant of the collider's object space in which the ellipsoid is a unit sphere.
This translation from object into ellipsoid space is the problem. It happens for a lot of vertices of the collider multiple times (depending on the recursion depth of the collision) and therefor, it has to be fast. With the "axis aligned" ellipsoid, this is easy. It requires 3 divisions/vertex. If the ellipsoid should be tranformed too, it's no longer that simple.

However, i'll look into it and see what i can do. For the time being, can't you simply use some smaller spheres placed at the car's front and back (like one left and one right) to approximate it? I'm not sure how well this will work though...

I see...the method doesn't get called, because the component (the applet in this case) doesn't get mouse events by default. You may either implement your own mouse listener or, if you want to use the method above, enable this type of event in your applet by calling
this.enableEvents(AWTEvent.MOUSE_EVENT_MASK);
somewhere in the beginning.