How are you starting your application? From inside an IDE? Which one? In JBuilder for example, you can add additional command line parameters to the project. You just have to add that -Xmx128m there and you are done. In Eclipse or Netbeans, it should be similar.

That's not an engine limitation, it's caused by the fact that the JVM defaults to 64mb max. To change this, start your application with the additional command line switch "-Xmx128m" or "-Xmx256m" or whatever you prefer. The VM won't grab all that memory from the beginning, so don't worry.

Which limit? You are giving the maximum number of triangles for an Object3D in the constructor, that's true. But what prevents you from creating an Object3D with let's say 100000 triangles? Or am i not understanding your question correctly?

If you find jPCT easier than xith3d or jME, then the idea worked. jPCT's goals were ease of use and a small size. That's the reason why its whole functionality is build around the two monoliths World and Object3D. This may also have some drawbacks and it doesn't look very "stylish" but it's easier to understand and its clear where to search for specific methods IMHO.
It also tries to hide the difficult stuff from the user as long as he doesn't need it. That's something where the other approaches fail IMO. It's ridiculous to follow a discussion in the xith-forums if xith should come with a normal generator or not, or why the collision system is broken and won't be fixed and ODEJava is much better anyway...there's no question that there should be a normal generator in a 3D engine (in fact, it was one of the first things that i've added to jPCT) and it's mandatory to have a working collision system. With jPCT, you don't even have to know that normals exist and what they are good for. The same for collisions: It's one line of code to check for a collision. If you want more info about the collision, implement a CollisionListener and you are done. But you don't have to...
I agree, that the current website has its problems to promote the project. On your first visit, it looks like just another applet demo. The frontpage doesn't tell you anything about what this really is all about. That's partly due to the fact that it wasn't much more than a just another applet demo when i designed the page. I think i could do much better now, but it's a question of motivation. I think i have to do it sooner or later though.
However, when you search for "java 3d engine" on google, jPCT comes second with no trace of xith3d and jME...but obviously, this isn't enough to make people think that it's actually a mature and stable product.

You mean a method that takes an array of vertices and creates the triangles from that like you do in your code "by hand"? No, there is no such thing ATM. I may add it, if it's really needed.
Alpha or transparency is only supported on a per Object3D base. That's mainly a tribut to the software rendering.
The order of the vertices that form a triangle counts, because it's used for backface culling. If your order is wrong, the triangle will de visible from the other side.
About the tiled terrain...i would say that it doesn't matter. jPCT will take care of the vertex sharing itself, you don't have to worry about it.

Amazing...this really is the most advanced applet game that i've ever seen...

What happened to your server? It seems to be down for some days now... :cry:

Finally...here are the changes:

http://www.jpct.net/changes.html

Have fun!

I had to delete your last post (and mine too) because somehow my answer appeared in your question

Anyway, what i mean about the framerate is, that you wouldn't ask this question if your framerate would be constant, because it wouldn't be a problem then.

1.) Should work. You have to set the parameter before initializing the OpenGL renderer.

2.) A very slow performance in OpenGL mode is not a normal behaviour unless your OpenGL card is very crappy. What graphics card are you using and in which display mode are you running?  Are you sure that you've really initialized the renderer in Hardware OpenGL mode and not just in the software renderer's OpenGL "emulation"?
Despite of this, you should base you movement on the time passed in the last frame(s) or ensure a constant framerate somehow (which obviously isn't possible in your case).

Config.farPlane should do the trick. Unless you are using fog with has to be adjusted separately using the setFogParameters()-method in World. It's also possible that you are scratching the maximum polygon count. In that case, adjust Config.maxPolysVisible. You have to do this before instantiating a World.

You can paint the crosshair yourself, save it as a gif (to avoid jpg's compression artifacts), load it as a texture and blit it transparent on screen (using the blitting methods from FrameBuffer) after drawing your actual scene. The car example does something similar for the red dots in the upper right corner.

Naja, etwa so:

SimpleVector p=...;// Der Punkt, auf den das Objekt gerichtet werden soll
SimpleVector la=p.calcSub(obj.getTransformedCenter());
Matrix m=la.getRotationMatrix();
obj.setRotationMatrix(m);

Habe ich jetzt aber nicht getestet...

Du muesstest den (Simple-)Vector zwischen vom Mittelpunkt des Objektes (o) und dem Punkt im Raum (p) ausrechnen (also -o+p). Dann kannst du von diesem die Rotationsmatrize generieren lassen (getRotationMatrix() in SimpleVector) und diese Matrix als neue Rotationsmatrix des Objektes setzen. Das sollte es tun.

Quote from: "Melssj5"

Quote from: "EgonOlsen".

I think that somthing is worng with the code of the engine

Very very unlikely. jPCT takes whatever name you give it to load the file and that's all it does. If anything goes wrong with loading your files, it's most likely your own fault.