TGEA 1.7.0 Release - DTS render bug
by Bill Vee · in Torque Game Engine Advanced · 05/14/2008 (5:34 pm) · 6 replies
It appears that the further away from the world center dts objects, like the crossbow or vehicles, exhibit on odd rendering error.
This doesn't effect static dts objects. Just objects that move.
The further away from world center the worse the error becomes.
It appears that the error is related to the grouping of objects in a dts file.
For instance the crossbow arrow ,the bow pins ,stock and bow string appear to be "vibrating" when moving them around.
It is kinda hard to describe it so this video demonstrates the error.
This doesn't effect static dts objects. Just objects that move.
The further away from world center the worse the error becomes.
It appears that the error is related to the grouping of objects in a dts file.
For instance the crossbow arrow ,the bow pins ,stock and bow string appear to be "vibrating" when moving them around.
It is kinda hard to describe it so this video demonstrates the error.
#2
Your right about the site search. I thought I remembered something like this about a year ago but was unable to locate the thread.
I would be interested in hearing more on your segmented world.
05/14/2008 (7:27 pm)
I suspected it had something to do with floating point rounding but was unsure.Your right about the site search. I thought I remembered something like this about a year ago but was unable to locate the thread.
I would be interested in hearing more on your segmented world.
#3
* 1. Seamless transitions between segments in our world.
* 2. Seamless transitions between segments when editing the mission and ability to save out the full mission grid.
* 3. Ability to change the mission grid size on runtime.
* 4. Eliminate the floating point errors when you're far from the center.
We never got to implementing (3) but instead the grid is defined statically by the mission designer before exporting. We really wanted to be able to change the grid on runtime so we could spread load better, but it proved to be painful and too time-consuming.
Our segments are like missions in Torque. Each has a center at 0,0,0 where you have full precision and so forth. Each mission has an extent or size which is based on the grid mentioned earlier. For example, 5k or 10k in all three dimensions. As soon as you reach scoping distance to other segments, your current instance starts "ghosting" you to the adjacent one(s), and you receive ghosts from their area.
Removing the datablock transfer phase, and precaching Ghost Always objects makes transitions between segments unnoticable to the client and gives the illusion that you're travelling trough a world with no borders.
So it's not a one-mission solution and probably not what you're looking for.
05/15/2008 (5:05 am)
It's more than just segmented into different coordinate systems. Our game design required four things:* 1. Seamless transitions between segments in our world.
* 2. Seamless transitions between segments when editing the mission and ability to save out the full mission grid.
* 3. Ability to change the mission grid size on runtime.
* 4. Eliminate the floating point errors when you're far from the center.
We never got to implementing (3) but instead the grid is defined statically by the mission designer before exporting. We really wanted to be able to change the grid on runtime so we could spread load better, but it proved to be painful and too time-consuming.
Our segments are like missions in Torque. Each has a center at 0,0,0 where you have full precision and so forth. Each mission has an extent or size which is based on the grid mentioned earlier. For example, 5k or 10k in all three dimensions. As soon as you reach scoping distance to other segments, your current instance starts "ghosting" you to the adjacent one(s), and you receive ghosts from their area.
Removing the datablock transfer phase, and precaching Ghost Always objects makes transitions between segments unnoticable to the client and gives the illusion that you're travelling trough a world with no borders.
So it's not a one-mission solution and probably not what you're looking for.
#4
I guess I will have to be content with the limitation right now.
I just have to scale back my ambitions.
05/15/2008 (6:24 am)
Interesting solution.I guess I will have to be content with the limitation right now.
I just have to scale back my ambitions.
#5
05/15/2008 (4:09 pm)
Or design around it.
Torque Owner Stefan Lundmark
This has been up alot before, too bad the search function on this site pretty much sucks.
The "error" you're experiencing is due to floating point rounding errors when your shape and subshapes changes transforms. At 31k meters from the center, this is to be expected since you're losing alot of precision that far way.
Most massive outdoor games take the approach of segmentizing their world into manageable chunks, with their own local coordinate system. You just don't see it as a player.
Edit: Not going too deeply into this, but our game uses segments of 10k meters width. When you reach that far, you go into a new segment of the world at -10k meters in that local space. But 30k is really stretching it.