How to Instantiate an Object and all Its Children

Started by AGP, July 11, 2013, 07:51:50 AM

Previous topic - Next topic

AGP

I'm trying to make a simple endless running game. The city has to keep repeating itself. Since it has transparent objects (such as trees), it can't all be merged into a single Object3D (nor have I enabled lazy transformations). What is the most efficient way to copy the city before we run out of it?

EgonOlsen

I did something similar in Alien Runner (albeit less complex). I did it by rendering two copies of the scene in a row and moving the first one back behind the second one (so that the second one becomes the new first one) once the first ones moves out of view (i.e. is behind the player). You can make all trees children of the copy of the city object to which they belong to easier move everything at once.

AGP

OK, if the following variable cityClone were to be initialized as cityClone = city.cloneObject() and simply added to the world, the endless runner would forever run seamlessly. Alas, Chunk2.obj is of the exact same size as City.obj and it's in the exact same place in Max, but when I reach it in my game it's always lower and slightly to its left. Only significant difference in the handling of the two, as far as I can tell, is that not all parts of the city variable are merged onto it (and it has, as its child, treesRoot) whereas for cityClone I call mergeAll right from the start. But as I'm not even looking for its transformed center, just translating it by the same amount as I translated city, I can't see how this would be an issue.


Object3D[] parts = Loader.loadOBJ("City5/City.obj", "City5/City.mtl", .05f);
int numberOfSubParts = 0;
treesRoot = Object3D.createDummyObj();
for (int i = 0; i < parts.length; i++) {
     if (parts[i].getName().toLowerCase().startsWith("tree")) {
parts[i].setTransparency(100);
parts[i].setCulling(false);
theWorld.addObject(parts[i]);
treesRoot.addChild(parts[i]);
parts[i].build();
     }
     else numberOfSubParts++;
}
Object3D[] subParts = new Object3D[numberOfSubParts];
int h = 0;
for (int i = 0; i < parts.length; i++) {
     if (!parts[i].getName().toLowerCase().startsWith("tree"))
subParts[h++] = parts[i];
}
city = Object3D.mergeAll(subParts);
city.addChild(treesRoot);
city.build();
city.rotateX((float)Math.PI*-.5f);//-.5f
final SimpleVector center = city.getTransformedCenter();
city.translate(-center.x, -center.y, -center.z);
cityClone = Object3D.mergeAll(Loader.loadOBJ("City5/Chunk2.obj", "City5/Chunk2.mtl", .05f));
cityClone.build();
cityClone.rotateX((float)Math.PI*-.5f);//-.5f
cityClone.translate(-center.x, -center.y, -center.z);
cityClone.translate(character.getZ().x*-59700f, 0, character.getZ().z*-59700f);
theWorld.addObject(cityClone);
theWorld.addObject(city);

AGP

Egon, have you no suggestions?

Also, the same game ported to jpct-ae has slightly different proportions (I have to translate the city chunks by a different, smaller, value).

EgonOlsen

Might be caused by the rotation pivots being different? You can try to savr them in 3ds format instead and set this config to true that makes jPCT use the rotation Picot from a 3ds file instead of the calculated one.

Regarding differencey between AE and desktop: There are none, because the transformations are some by the hardware anyway. The different look might be caused by a different horizontal fov caused by the different aspect ratios.

AGP

How do I test for that? Camera.getFOV() returns 1.25 on both desktop and Android (on a Galaxy S4).

EgonOlsen

That's the horizontal fov. The vertical fov is derived from that value as runtime, there's no getter for it. Maybe to can post two screen shots for comparison, to See of that's really the point here?!

AGP

I don't have a screenshot button on my phone. For some reason, when I tried the palm swipe thing, it rotated the camera by ninety degree intervals. I took several very weird (useless for this purpose) screenshots. The desktop version, obviously, was no problem.

EgonOlsen

You can take screen shots directly in the Eclipse plugin.

AGP

I did not know that, thank you. This little game, by the way, I'm just making for my 5-year old son. Here are the screenshots:


EgonOlsen

You are loading the objects, calling build on the merged object and then rotate it. That will most likely create different rotation pivots, which will lead to different positions in space after the rotations.
That should be the reason for the different chunk positions. Try to set the rotation pivot to the origin after calling build and see if that helps. I'm not sure if it's also responsible for the different translations on Android. It might as well be a difference in the ported code. I'm doing desktop/Android hybrides all the time and have never seen such a difference nor can i see any reason for it.

AGP

That did it for the chunk 2 displacement. Bur as for the difference in translation between Android and desktop, do you no longer think it's related to field-of-view? Because that's the only thing that I can see making sense. And if you think that it still might be, how could we test this?

EgonOlsen

No, it's not fov related. I misunderstood the issue first so that i thought that it might be fov related, but it isn't. Any chance that you are not calling build() on some of these objects? Because the Android version does this automatically but the desktop version doesn't.

AGP


EgonOlsen

I've no idea what should cause it then. Are you loading both objects from the same files or is the Android version using serialized objects?