Quote from: "tomzwo"Did I get this right: applying VertexController Things and other transformations go together quite well? That would make things very easy: translate and rotate with the standard methods - (btw: being able to set the rotation pivot spot is very useful) and do some non-uniform scaling with VertexController.

That's the way it's supposed to work.

QuoteSomething else: I found a - in my eyes - rather smart solution for the obstacle of not being able to apply colors to objects. Interested, anyone? if(InterestList.length > 0) postExample();

I'm not sure what you mean, but i think that i'm interested... :wink:

Well, the example that i've written in that thread ommits an important step: How to apply the assigned controller... :wink: But it's quite simple. Just call
applyVertexController(); on the Object3D's Mesh and it will be applied.
Vertices and normals in the controller are all in object space, so that transformations don't matter. If you need to pre-transform the object, have a look at rotateMesh() and translateMesh() in Object3D.

10 seconds for a 500*500 image :?: That's way too much. I'm using a PixelGrabber to access the texture data after loading...and i'm loading a lot of 512*512 textures. Can you post some code?

Is it supposed to show a single plane only? Or am i doing something wrong?

The examples don't have any sound. Paradroidz has (http://www.jpct.net/paradroidz). I'm using a two way approach in this game as i'm using OpenAL (provided by LWJGL) where available and JavaSound where not (or where OpenAL doesn't work). This works fine so far. If you intend to do an applet, you may be limited to JavaSound anyway...i don't know if LWJGL's OpenAL stuff will work in an applet.
Just keep in mind that JavaSound in Java5 is totally screwed up and that you have to use a workaround to get it running correctly.

Für Applets ist es nicht anders, als für Applikationen, wenn man von den naturgegebenen Unterschieden einmal absieht. Es gab mal ein Applet-Beispiel, aber in 0.97 ist es rausgeflogen. Die Version 0.96 mit dem Beispiel gibt es noch hier drin: http://www.jpct.net/download/
Aber nimm davon nur das Beispiel, nicht die API selber..0.96 ist uralt. Ob das Beispiel noch mit 1.05 compiliert weiß ich nicht genau, aber wenn nicht, dann sollte nicht viel zu ändern sein.
Um ein einfaches Object zu erzeugen, musst du einfach ein Object3D mit der gewünschten Polygonanzahl erzeugen und mit addTriangle(...) deine Dreiecke hinzufügen. Hier ein Beispiel für einen Ring:

private static Object3D buildRing(float maxSize, float minSize, float texSize) {
     final float rot=2*0.19634954084936207740391521145497f;

     Object3D obj=new Object3D(16*2);
     float div=Math.abs(maxSize)*2;

     SimpleVector s1=new SimpleVector(-maxSize, 0, 0);
     SimpleVector s2=new SimpleVector(-minSize, 0, 0);
     SimpleVector st=new SimpleVector(-texSize, 0, 0);
     SimpleVector e1=null;
     SimpleVector e2=null;
     SimpleVector et=null;

     int i=0;
     while (i<16) {
        i++;
        e1=new SimpleVector(s1);
        e2=new SimpleVector(s2);
        et=new SimpleVector(st);

        e1.rotateY(rot);
        e2.rotateY(rot);
        et.rotateY(rot);

        if (i==16) {
           e1=new SimpleVector(-maxSize, 0, 0);
           e2=new SimpleVector(-minSize, 0, 0);
           et=new SimpleVector(-texSize, 0, 0);
        }

        float us1=s1.x/div+0.5f;
        float vs1=s1.z/div+0.5f;
        float us2=st.x/div+0.5f;
        float vs2=st.z/div+0.5f;

        float ue1=e1.x/div+0.5f;
        float ve1=e1.z/div+0.5f;
        float ue2=et.x/div+0.5f;
        float ve2=et.z/div+0.5f;

        obj.addTriangle(s1, us1, vs1, e1, ue1, ve1, s2, us2, vs2);
        obj.addTriangle(e1, ue1, ve1, e2, ue2, ve2, s2, us2, vs2);

        s1=e1;
        s2=e2;
        st=et;
     }
     return obj;
  }

Für ein Band ist es noch eine ganze Ecke einfacher.

Again, this should fix some security problems.

Quote from: "raft"here it is. one must reset rotation matrix after rotating mesh, without it the result is as rotating it twice  

Yes, i should have mentioned this... :wink:

What is "direction"? A SimpleVector like (0,1,0)? The behaviour that it moves according to moveSpeed is correct. The ellipsoid just defines the bounds of the object/camera, not the translation that it makes when moving. That's what moveSpeed is for.
Regarding your directional problem, i assume that you are applying a rotation to the level, so that object space and world space don't match anymore (for example: You do a rotateZ(a) on an object and the same on the camera (explicit of implicit (lookAt() or similar may cause this). This looks exactly the same as if you hadn't rotated anything at all, but when moving in world space (which the camera does), the outcome will be different).  If this is the case, you either have to apply this rotation to your direction vector too, or rotate the level object permanently by using the rotateMesh()-approach.

Edit: As a rule of thumb: Make sure that object space and world space match (except for translations..they don't matter in this case) for your world/level/main object. That makes life a lot easier.

Could be that 3DS merges some vertices on the one model but not on the other...maybe loading them into an MD2 editor will fix the problem. However, i don't know very much about MD2 editors, but Milkshape can export to MD2. Maybe it's worth a try.

I've changed the field to protected in jPCT 1.05, which has been released today. To access it, do something like this:

import com.threed.jpct.*;

public class BetterBuffer extends FrameBuffer {

 public BetterBuffer(int x, int y, int os) {
   super(x,y,os);
 }

 public int[] getZBuffer() {
   return zbuffer;
 }
}

But remember: This is a somehow unsupported hack and it won't work with the OpenGL renderer.

You can find the changes here:

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

What this version basically tries to do, is to reduce memory usage. By default, this is already the case but the more aggressive optimizations are disabled for compatibility reasons. However, here's a brief description what to do to maximize the effect:

Set Config.saveMemory to true.  Object3Ds should use less memory with this setting until they really need it (what may never happen). In that case, the memory will be allocated at runtime, what may cause hick-ups...then again, i never experienced them.

If you are using multiple Worlds but are not rendering them at a time, try to set Config.shareVisibilityList to true.

Set Config.polygonBufferSize to something between 10 and 100. Even 10 should be sufficient in most cases (if it's not, it will automatically be resized, but that may happen at times where you don't want it).

Have fun.

P.S.: It comes bundled with LWJGL 0.95 for Windows.

It's not possible to do this in the current version, i'm afraid. Even in software mode, you would have to deal with the zTrick jPCT can use.  I don't think that i'll add a getZBuffer() method to FrameBuffer, but i can imagine to change the int[] that the zBuffer is protected. That way, you could access it, but only by extending FrameBuffer. That makes it clearer, that it's actually a hacky thing to do.
Would that help?

Quote from: "Necormancer"mmmm people
can i'm use you 3d engine fro my?

:?: I'm not really sure, what you are trying to ask here...

Seems to run better now regarding memory usage...at least it doesn't bomb out with "out of memory", which the former version did for me. The upcoming jPCT 1.05 version may be able to improve this even further, because it uses less memory by default and you can even tweak some things in addition.
Should be ready within a week...i hope...