Try to disable backface culling by using the setCulling()-method in Object3D. Do the objects show then? This is of course not a good solution, just a quick test if vertex ordering is really your problem.

Quote from: "Uija"Works great!
Just the OcTrees take forever and the "createTriangleStrips" you are using in the FPS example.
What exactly does it? and is it important for Terrains?

Creating an octree takes it's time...it's already quite optimized. Creating triangle strips isn't...but it may be usefull on the terrain depending on how you are creating it. Google for "triangle strips" to see what they actually are and build your terrain accordingly. jPCT will recognize it and so there should be no need to call createTriangleStrips anymore.

Maybe that is his z axis then? What happens if you translate it along the getXAxis()?

Quote from: "Uija"THIS is how it looks like.

i think you linked to the wrong picture. Is this the correct one: http://uija.net/images/error_rotation.jpg?

QuoteI hope you understand better now

Well...uhmm...no... :?:

If you move the dragon into its local z axis' direction, it should move to the right (given the picture is the correct one). If you move it into the direction of the global z axis, it should move into the screen. I still don't get what you expect it to do instead... :?:

ASC is an old 3DS variant and 3DS is limited to 2^16 vertices per object. If you are using more, this may cause trouble. Are you?

Edit: You don't have to use the conversion step to ASC/3DS/whatever as you can create the triangles directly from your PNG and add them to the object "by hand" using addTriangle in Obejct3D.

u and v are a textures x and y with 0,0 being the upper left corner and 1,1 being the lower right. To map the upper right triangle of a quad with it's corresponding "triangle" of the texture for example, one would use (0,0), (1,0),(1,1)...and (0,0),(0,1),(1,1) for the lower left triangle.

Quote from: "Uija"But now I am strafing all the time
Rotating the Model doesn't help, als it rotates the movement axis too.

I don't quite understand...movement can either be relative to the object's orientation (as you are doing it by using getZAxis() for example) or absolute (for example by 0,0,1 to move 'inside' the screen). What's the actual problem with strafing now?

I got this one from time to time...:

Exception in thread "AWT-EventQueue-0" java.util.ConcurrentModificationException
at java.util.AbstractList$Itr.checkForComodification(Unknown Source)
at java.util.AbstractList$Itr.next(Unknown Source)
at aD.a(Unknown Source)
at aD.paint(Unknown Source)
at java.awt.GraphicsCallback$PaintCallback.run(Unknown Source)
at sun.awt.SunGraphicsCallback.runOneComponent(Unknown Source)
at sun.awt.SunGraphicsCallback.runComponents(Unknown Source)
at java.awt.Container.paint(Unknown Source)
at y.paint(Unknown Source)
at y.update(Unknown Source)
at sun.awt.RepaintArea.updateComponent(Unknown Source)
at sun.awt.RepaintArea.paint(Unknown Source)
at sun.awt.windows.WComponentPeer.handleEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)

It's a show stopper, because it bails out of the AWT event dispatch thread which causes some problems in the AWTGLRenderer.

All modes are reporting 24bit for the zbuffer because that's what Config says by default. LWJGL doesn't report this value any longer since version 0.idontknow, so i had to take it from Config. Try to set it to 16 or even 0 in Config before getting the video modes and see if that helps.

Quote from: "raft"i've also made some performance tests with AWTGLRenderer. for small worlds it is far more faster than software renderer, but as the world gets bigger the difference gets smaller. strange

Because the processing overhead increases. Are you using octrees? And if you are using the AWTGLRenderer, make sure to enable Config.glVertexArrays is possible. It takes much load off from the command queue of the renderer.

Quote from: "raft"and one more thing: although GLCanvasRenderer initializes fine on my box, OpenGL renderer doesnt. it complains about the VideoMode. (i tried all available modes FrameBuffer.getVideoModes(..) returns) lwjgl demos also work fine. i find this strange since  both GLCanvasRenderer and OpenGL renderer uses lwgl

I don't really know about the active rendering stuff...i *think* there isn't a good solution to that but i'm not a SWING guy, so i don't really know much about it.
About the video modes...is this still a Voodoo3 you are using? If it is, you can only do 16bit color depth and z-buffer depth. The difference between the AWTGLRenderer and the normal OpenGL renderer is, that the first one simply uses the desktop settings and the latter has to set it all explicitly. Why this doesn't work on you box...i don't know, but *if* you are talking about the V3 here, it's not wondering me either. Does it work in windowed mode?

ASC is better anyway. However, i've updated the pre-release JAR of 1.07 with a quick fix for the JAW problem. It can be found here: http://www.jpct.net/download/jpct107a2.jar

That's a hard coded, undocumented  limitation in the loader... :oops:
The code of the jaw-loader is around 6 years old and i've never touched it since then. There is a configuration variable for it, but it's not public. I'll try to get this fixed somehow in the next version or at least exit more gracefully than with an ArrayOutOfBounds from deep inside the Loader.
JAW isn't a very good format anyway...
(3DS and ASC have such limitations too, but they are implied by the format specs themselves).

...it's @ 2.0.17 now!

It works fine now. Even if it wasn't a problem in jPCT, it made me rework some parts of the AWTGLRenderer and discover some bugs. Speaking of bugs: On my machine, the blitted text is gone (happens on some machines  and/or in some resolutions due to some weird zbuffer/clipping plane stuff). Set Config.glFixedBlitting=true and it will appear again. I'll enable this by default in the next release anyway.
About the blinking: There's not much you can do about that, i'm afraid. Sorting is always an issue with transparency. The polygons are sorted by the painter algorithm using their z-midpoint (roughly) but this won't give you correct sorting in all cases. And a zbuffer is pointless for transparent polygons (i had this enabled once and it looked even worse)...so you have to live with that. It's not that bad anyway, IMHO.

Edit: I like the talking bots...add some "personality" to them.