Thank you Egon. It works now. The problem was that I used this code from somewhere on this site when loading the object.

QuoteObject3D o3d = new Object3D(0);
       Object3D temp = null;
       for (int i = 0; i < m.length; i++) {
           temp = m;
           temp.setCenter(SimpleVector.ORIGIN);
           temp.rotateX((float)(-Math.PI/2));
           temp.rotateMesh();
           temp.setRotationMatrix(new Matrix());
           o3d = Object3D.mergeObjects(o3d, temp);
       }

As all my objects are made of one mesh anyway, I rotate the meshes in Blender now, throw out the part above and just return what loadSerializedObject returns. Everything looks fine now. Thanks again!

Okay, this is weird. I did cleartranslation and -rotation, and actually measured the positions with a tape
And what the heck, the child objects are actually in the same position whether 3ds or ser. But the ship itself moved!

Quote from: EgonOlsen on July 03, 2013, 11:03:17 AM
No, not setCenter() but maybe setRotationPivot(). However, the ser-files contain the rotation pivot since some version. It might be that your plugin uses another version of jPCT to serialize them, so that the pivot isn't taken from the file but rebuild when calling build(). This might cause this offset somehow.

Hi Egon, bringing this up once more, as my game is nearing completion and I still did not figure out a solution here.
Made sure to use the latest version of desktop JPCT to serialize, and I call setRotationPivot(SimpleVector.ORIGIN) after loading the 3DS into the serializer as well as after loading the .ser in my game. Still, the child objects are still at the same (wrong) positions. Kinda ran out of ideas now. Maybe you didn't..?

How do you do the drawing of the dialog?

I'd initialize the object in another thread and display a message while this thread is running. For longer load times, you even must do something like that if you want to avoid the dreaded "application deadlock" message.
Take a look at this pretty similar thread:
http://www.jpct.net/forum2/index.php/topic,3772.0.html

You can load your objects in a new thread and meanwhile, show a blinking "Loading" message or whatever on your main thread.

So, if you had a function like that before


private void initObjects() {
// ...load your objects
}


you can add another class (even in the same source file for convenience)


class InitObject extends Thread {

public void run() {
loading=true;
// ...load your objects
                loading=false;
        }

and change initObjects() to


private void initObjects() {
    InitObject i = new InitObject();
    i.start();
}



and check for "loading" in the render thread. Something like that.



   

Thanks for the feedback guys

Quote from: Lobby on December 30, 2013, 10:56:14 AM
I think so. Could you also add a link there to this Topic? Then it would make a lot more sense .

Nice code snippet, but don't forget that it is possible to determine a difference between a really far object and a not that far, scaled object. The really far object will look more flat than the other one (but I think nobody will ever notice that in a real program).

Thought it would be easy enough to find but here you go
http://www.jpct.net/wiki/index.php/Fake_unlimited_viewing_distance

About your objection: Are you sure this effect isn't only present in stereoscopic (real) 3D?

Added to the Wiki. I think we should still keep this thread open in case there any questions.

Added to the Wiki. I think we should still keep this thread open in case there any questions.

Sure!

A nine-patch is a bitmap that is very useful for GUI elements.
Usually, when you blit-scale your buttons for different resolutions, they may look like that:



Wouldn't it be much nicer if they looked like that:



You can do this with a 9Patch, where only the inner area gets scaled in two directions; the corners do not get scaled at all, while the borders only scale in one direction (horizontally or vertical).




There is no built-in support in JPCT-AE for it, so I adapted the blit function to write my own implementation. It's not a 1:1 adaptation (scaleable area is supported, but not fill area).

First, you will need a source bitmap like this:



Zoomed in to better show the black borders. They need to be on the first horizontal and vertical stripe of the image and show where the inner zone begins and ends. The borders themselves do not get blitted.
I made the button translucent inside, but that is not mandatory.




Here is the code:



class NinePatch {

private int[]X = new int[2];
private int[]Y = new int[2]; //These hold the scale zone coordinates
private int W, H;  // Input bitmap dimensions
private Texture tex;
private String name;

public Space9Patch(Bitmap b, String name) {  // Make sure b is not scaled! It is best to use a white picture so you can blit it in any color later on
this.name = name;

W = b.getWidth();
H = b.getHeight();
X[0] = X[1] = Y[0] = Y[1] = -1; //Start and end positions of inner scale zone

for (int x=0; x<W; x++) { // Analyze first horizontal stripe of bitmap
if (b.getPixel(x, 0) == Color.BLACK && X[0] == -1) { // Look for black pixel
X[0] = x;   //Save position of first black pixel
}
else if (b.getPixel(x, 0) == Color.TRANSPARENT && X[0]>=0) {  //Look for first transparent pixel after black stripe
X[1] = x-1;  //Save position of last black pixel
break;
}
}

for (int y=0; y<H; y++) { // Analyze first vertical stripe
if (b.getPixel(0, y) == Color.BLACK && Y[0] == -1) { //same as above but in vertical direction
Y[0] = y;
}
else if (b.getPixel(0, y) == Color.TRANSPARENT && Y[0]>=0) {
Y[1] = y-1;
break;
}
}

//Create texture from bitmap
TextureManager tm = TextureManager.getInstance();
if (!tm.containsTexture(name)) tm.addTexture(name, new Texture(b, true));
tex = tm.getTexture(name);
}

//Draw 9-patch in abitrary size and additional color
public void blit(FrameBuffer fb, int x, int y, int w, int h, int transp, RGBColor col) {
fb.blit(tex, 1, 1, x, y, X[0]-1, Y[0]-1, X[0], Y[0], transp, false, col);
            fb.blit(tex, X[0], 1, x+X[0], y, X[1] - X[0]+1, Y[0]-1, w- X[0]- (W-X[1])+1, Y[0], transp, false, col);
fb.blit(tex, X[1]+1, 1, x+w-(W-X[1])+1, y, W-X[1]-1, Y[0]-1, W-X[1]-1, Y[0], transp, false, col);

fb.blit(tex, 1, Y[0], x, y+Y[0], X[0]-1, Y[1] - Y[0]+1, X[0], h - Y[0] - (H-Y[1]) + 1, transp, false, col);
fb.blit(tex, X[0], Y[0], x+X[0], y+Y[0], X[1]-X[0]+1, Y[1]-Y[0]+1, w-X[0] - (W-X[1])+1, h - Y[0] - (H-Y[1])+1, transp, false, col);
fb.blit(tex, X[1]+1, Y[0], x+w-(W-X[1])+1, y+Y[0], W-X[1]-1, Y[1] - Y[0]+1, W-X[1]-1, h - Y[0] - (H-Y[1])+1, transp, false, col);

fb.blit(tex, 1, Y[1]+1, x, y+h-(H-Y[1])+1, X[0], H-Y[1]-1, X[0], H-Y[1]-1, transp, false, col);
fb.blit(tex, X[0], Y[1]+1, x+X[0], y+h-(H-Y[1])+1, X[1] - X[0]+1, H-Y[1]-2, w - X[0] - (W-X[1])+1, H-Y[1]-1, transp, false, col);
fb.blit(tex, X[1]+1, Y[1]+1, x+w-(W-X[1])+1, y+h-(H-Y[1])+1, W-X[1]-1, H-Y[1]-2, W-X[1]-1, H-Y[1]-1, transp, false, col);
}

//Blit using original color
public void blit(FrameBuffer fb, int x, int y, int w, int h, int transp) {
blit(fb, x, y, w, h, transp, RGBColor.WHITE);
}
}



From time to time, I will post a few code snippets that proved useful while working on Armada. Maybe someone can use something for their own projects.

One problem that I ran into was the limited viewing distance. I thought that just setting the farplane value high enough would solve it, but there is actually a hard limit given by the hardware and/or OpenGl (not sure about that).
I wanted to have a planet that is far away but still visible (and approachable). While it would be possible to fake something with billboards, I found a solution that uses real geometry and actually pretty simple.


public class Planet extends Object3D { //It's better to not use Object3D directly for your game objects, but I do it here for simplicity

  private SimpleVector realPosition, camPos = new SimpleVector();
  private SimpleVector v = new SimpleVector; // temporary vector
  private final static MAX_VIEWING_DISTANCE = 5000; //this should be a safe value for most devices; make sure your farplane value is higher than this

  public Planet(SimpleVector position) {
      ... // init Object3D here

     translate(position);
     realPosition = new SimpleVector(position); //Save "real" position of planet in another vector as the object's physical position will change
  }

  // this is called in every frame update
  public void update() {
   
    world.getCamera().getPosition(camPos); //position of used camera

    float dist = realPosition.distance(camPos);  //calculate distance camera<->Planet

    if (dist>MAX_VIEWING_DISTANCE) { //outside of the viewing distance -> do projection magic

setScale(MAX_VIEWING_DISTANCE / dist);    //shrink the object

     // Now that we made the object smaller, put it closer to the camera

v.set(realPosition); //Set helper vector to planet position
v.sub(camPos); //calculate direction vector from camera to planet
v.normalize(v); //and normalize it
v.scalarMul(MAX_VIEWING_DISTANCE); // Calculate new position within viewing distance
        v.add(camPos);  // add camera vector to get final object position

  //Move it!
        clearTranslation();
        translate(v);
   }

   else { //planet is within viewing distance; reset size and position to real values
setScale(1);
        clearTranslation();
translate(realPosition);
  }


Yes, warnings seem to be treated as fatal errors in Proguard, at least when executed from Eclipse.

I managed the steering somewhat, but constantly drove through the walls and then sank into the ground. Also, if the car does crash into a wall, it bounces back like some overly bouncy thing. You should really fix stuff like this before publishing your app, your ratings will thank you!
To add something positive, I really like the graphics, menus and different camera settings.