Size of world when NOT using terrain - what limits?

#1 I don't see why this wouldn't work. On the other hand, I've seen Torque do some really strange things when you don't use the terrain.

#2 It uses floats for doing positional stuff. There might be some hardcoded world bounding box issues - you can easily up those in code - and beyond that you can just go. You have 32bits of positional accuracy.

#3 Also, would it be possible to modify how terrain works, so you could apply it around a sphere? Or make a sphere shape of the terrain? Thinking shuttle mission control thing here... launch shuttle, land shuttle... planet would need to be spherical ;)
Guess it would be a lot of work to make terrain work like that.

#4 Its all down to the accuracy of the floating point values youre using. You can also do some interesting tricks (like setting a "relative" point, so that you can extend the space.

Frankly, I dont think its THAT much of an issue, you can keep going for a LONG time on a floating point value :)

Try it, see how it works out.

#5 I've heard about precision oddities if you're not careful, but it all depends on what scale you need to operate and so forth. Check GD-Algorithms for details, there have been some good threads there on the subject.

#6 @Thomas, search the resources...there was a "space" mod posted a year or two ago that ripped out the terrain and used a database for setting up stars/planets.

#7 Depending on underpinnings, 32 bits *is* a problem for large scale games, such as if you try to bring two shapes into precise position near each other at some point far from the origin and then move the assembly close to the camera, you will quickly see the effects of granular representation.

I hope to be able to work around any such issues with TGE, and will explain the strategy I will first try.

The solution I used in my prototype is probably much like Phil is alluding to: I kept "World" position dimensions as 64 bit values, and regarded those "absolute" positions in the engine I had not as "world positions" but as "stage positions". These were 32 bit, and I kept a global "stage offset" (in 64 bits) which represented the position in world-space of the origin of my stage. Therefore, to obtain the world position of any object in my world, I added its 32-bit "absolute" (or stage) position to the current value of the 64-bit stage offset.

To get around the native 32-bit precision issue, I realized that this was most crucial when constructing shapes from smaller components and even then, only when the camera was near them (who cares how perfect such things are when they are 2 pixels on your screen?). I kept a "maximum camera offset" tolerance variable which represented the greatest distance from the STAGE ORIGIN I would permit the camera to get to -- that is, I'd choose a distance from 0,0,0 at which the granularity of a 32 bit float was becoming too coarse for my fancy. Every render cycle, if the current native position of the camera object exceeded this distance, I undertook a loop in which each shape 1 level off the engine's "stage geometry root" was translated by -cameraStagePosition. At the same time, the corresponding correction was made to the global variable recording the offset of the stage origin in the 64-bit world space. This had the effect of moving everything closer to the center of the 32-bit geometry space used by the engine without altering the logical position within the world of anything at all.

The issues of how to implement this in any given engine will vary a lot. I fear that Torque's features for interpolation and such will cause considerable heart-ache and complexity -- it would be really great if the engine someday had this optional meta-dimensional world space added into its mainline.

tone

#8 You realize you responded to a thread that is a year old?