Author
Topic: How to Instantiate an Object and all Its Children (Read 3196 times)

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?

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.

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.

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.

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.

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.

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?

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.