T3D, Existing Object and Terrain System, and Terrain Paging
by Demolishun · in Torque 3D Professional · 09/04/2013 (7:17 pm) · 31 replies
Okay, I got to thinking about T3D, the existing object system, and the terrain system. I was thinking in terms of terrain paging. To me, terrain paging is a really good concept that is only gaining speed. However, after thinking about how the engine is setup as is T3D may not cut it out of the box. Why? Simply put, because T3D does not place the camera at the center of the Video Card's universe terrain paging will never function properly. This is because of the floating point number issue. So what to do?
First I need to find where the assumptions are made:
As I ponder this I wonder if to do terrain paging of any kind will the entire object system and rendering system need a complete overhaul? At the very least the object system does. It is based upon the assumption that the camera is not in the center of the graphics cards rendering space. So at some point (probably SceneObject) this assumption will have to changed. I am thinking that the actual position of objects should be a either a 32 bit or 64 bit integer. This data should either be in the object as additional position data or tracked outside using the object ID or hash of some sort to access this information for rendering. The reason I would represent position with an integer is that it is an absolute position that suffers no issues from large values and accuracy. This could be sub-mapped for rendering using floating point representations in the video card scene.
After thinking this through I came to one startling revelation. Most FPS style games are designed to be a in small space that are easily represented by 32 bit floating point numbers. So from a technical perspective T3D is very much locked into an FPS style mission implementation. So the criticism that the engine is an FPS engine may not be an emotional argument, but a technical one.
First I need to find where the assumptions are made:
- At what point in the engine is the assumption made that the player is not the center of the graphics card universe?
- Is it in the SceneObject, the TerrainObject, the Camera?
- Should the position of the SceneObjects even be stored in the object?
- Should physics and position be tracked outside of the objects themselves?
As I ponder this I wonder if to do terrain paging of any kind will the entire object system and rendering system need a complete overhaul? At the very least the object system does. It is based upon the assumption that the camera is not in the center of the graphics cards rendering space. So at some point (probably SceneObject) this assumption will have to changed. I am thinking that the actual position of objects should be a either a 32 bit or 64 bit integer. This data should either be in the object as additional position data or tracked outside using the object ID or hash of some sort to access this information for rendering. The reason I would represent position with an integer is that it is an absolute position that suffers no issues from large values and accuracy. This could be sub-mapped for rendering using floating point representations in the video card scene.
After thinking this through I came to one startling revelation. Most FPS style games are designed to be a in small space that are easily represented by 32 bit floating point numbers. So from a technical perspective T3D is very much locked into an FPS style mission implementation. So the criticism that the engine is an FPS engine may not be an emotional argument, but a technical one.
About the author
I love programming, I love programming things that go click, whirr, boom. For organized T3D Links visit: http://demolishun.com/?page_id=67
#22
The video card uses stricly 32-bit floating point math for its matrixes internally. Newer DX11-grade cards can use 64-bit. But as Daniel says above, the best approach is relative rendering.
09/06/2013 (1:23 am)
Quote:
Actually a double won't cut it. It is what the video card uses for coordinates that matters. If it could be changed to a double it might just make things a lot easier. I have no idea of any video cards support this though. I think they assume that you should abstract the view rather than support huge high precision numbers.
The video card uses stricly 32-bit floating point math for its matrixes internally. Newer DX11-grade cards can use 64-bit. But as Daniel says above, the best approach is relative rendering.
#23
09/06/2013 (6:43 am)
Quote:Rezeroing is a great solution, but you're still back to the start if you want to consider multiplayer.Pretty much, but perhaps it could be adapted to multiplayer use if the server were designed for it. Something has to keep the actual world position of each player and at least a basic model of the whole world available (or perhaps just relative chunks if it's a procedural world). <shrug> That's why I leave the clever bits to you young'uns - you're all in school or fresh out of school and "the mind of a child is a wondrous thing" (to quote my favorite person of all time).
#24
You could have several servers running, and so when you enter the new zone and rezero your coordinates, you actually connect to a new server working with another worldcenter position.
I'd imagine it could work by giving each server it's own square, as you approach the border of a zone, you connect to a second server and merge the information of both servers into the client's world. (Ofc you should make sure not to have overlapping content to avoid conflicts) then at some border, you transfer the player from one server to the other, and let the new server handle the players coordinates.
09/06/2013 (6:55 am)
Quote:Rezeroing is a great solution, but you're still back to the start if you want to consider multiplayer.Heres my thoughts on that, this is mostly for MMO's thos, don't know if it would work for smaller scale games.
You could have several servers running, and so when you enter the new zone and rezero your coordinates, you actually connect to a new server working with another worldcenter position.
I'd imagine it could work by giving each server it's own square, as you approach the border of a zone, you connect to a second server and merge the information of both servers into the client's world. (Ofc you should make sure not to have overlapping content to avoid conflicts) then at some border, you transfer the player from one server to the other, and let the new server handle the players coordinates.
#25
A while back I came across a book called Game Programming Gems which can be downloaded here. There is a chapter called "Solving Accuracy Problems In Large World Coordinates" that describes your issue and provides one possible solution. It basically involves eliminating the world space transformation from the graphics pipeline and repositioning the origin dynamically by a predetermined segment length. I've never tried this myself, but maybe this will give you some ideas, or at least help familiarize you more with what is involved.
09/06/2013 (10:17 pm)
@Demolishun,A while back I came across a book called Game Programming Gems which can be downloaded here. There is a chapter called "Solving Accuracy Problems In Large World Coordinates" that describes your issue and provides one possible solution. It basically involves eliminating the world space transformation from the graphics pipeline and repositioning the origin dynamically by a predetermined segment length. I've never tried this myself, but maybe this will give you some ideas, or at least help familiarize you more with what is involved.
#26
09/07/2013 (6:22 am)
@Joseph - Aw hell, I have that whole set (1 - 7 anyway). Now I need to go pull them out of storage....
#27
I'm sure you've got them memorized by now :) I have to reread most of the stuff in there 3 or 4 times before it starts to sink in.
09/07/2013 (7:41 am)
@Richard,I'm sure you've got them memorized by now :) I have to reread most of the stuff in there 3 or 4 times before it starts to sink in.
#28
There was some odd behavior where it wasn't wanting to go backwards, but forwards was fine, etc, but it wouldn't let me just 'walk' past that 1 mil point, unsurprisingly.
So there may be some oddities with container updates and the like at those extreme ranges, but it seems like server-wise the core of it is fairly stable, at least in a local connection.
However, the client-side stuff like rendering didn't fare nearly as well. Stuttering, glitches, etc. The camera didn't have any problems, but stuff like the mesh geometry or the skybox stuttered or had parts clip in and out.
So given that lightweight testing, you'd probably want to
a) double check container updates and the like to ensure there's no weird behavior at those ranges, though as far as I can tell, there wasn't much
b) switch the scene object position to double precision if you need further than 1 million in either direction
c) move client side stuff like rendering to local space, or camera re-zeroed worldspace
I'm also going to read up on the article from that book as that sounds right up this sort of thing's alley, but given what all I'm already working on, I can't really do much more than this right now ;)
09/08/2013 (7:45 am)
So, I did some messing with how well torque actually DOES handle out at extremes and placed my control object at 1 million along the x axis, which is about the max your 32bit float is going to handle 'properly'.There was some odd behavior where it wasn't wanting to go backwards, but forwards was fine, etc, but it wouldn't let me just 'walk' past that 1 mil point, unsurprisingly.
So there may be some oddities with container updates and the like at those extreme ranges, but it seems like server-wise the core of it is fairly stable, at least in a local connection.
However, the client-side stuff like rendering didn't fare nearly as well. Stuttering, glitches, etc. The camera didn't have any problems, but stuff like the mesh geometry or the skybox stuttered or had parts clip in and out.
So given that lightweight testing, you'd probably want to
a) double check container updates and the like to ensure there's no weird behavior at those ranges, though as far as I can tell, there wasn't much
b) switch the scene object position to double precision if you need further than 1 million in either direction
c) move client side stuff like rendering to local space, or camera re-zeroed worldspace
I'm also going to read up on the article from that book as that sounds right up this sort of thing's alley, but given what all I'm already working on, I can't really do much more than this right now ;)
#29
One advantage this would have is the ability to seamlessly swap players between servers (machines or server instances) running separate missions. I am not going to try to merge the missions from different terrain areas. So once you leave an area it no longer exists in the players view. Part of the reason for this decision is the reality that in Minecraft I rarely go very far within a world. Most of the time I spend building my main base. So it is not a big deal that I would have mission loading and actually be in separate missions. I can live with that.
09/17/2013 (3:12 pm)
Well, for the short term I am going to look at voxel terrain inside the mission structure. I will still have to zone chunks of voxel data so that will prepare me for eventually going to a completely open terrain system. One advantage this would have is the ability to seamlessly swap players between servers (machines or server instances) running separate missions. I am not going to try to merge the missions from different terrain areas. So once you leave an area it no longer exists in the players view. Part of the reason for this decision is the reality that in Minecraft I rarely go very far within a world. Most of the time I spend building my main base. So it is not a big deal that I would have mission loading and actually be in separate missions. I can live with that.
#30
I dont know if this would be possible but.. I was thinking maybe using a 2d map that the server uses to keep track of objects, player positions, while any or all 3d world content is loaded client side this way its less load on the server, and all on the client as in games with huge worlds like Morrowind. I kind of remember this from the older isometric 2d games like Ultima Online where the 2d map moved while the player was stationary, but somehow improve on this idea to work 2d server side, while 3d client side. If any game world object, items, house would change the client can probably send the information to the server, the server can test if this is acceptable design, placement, position, make its calculations, and then store the information that will be passed back down to other players on an as need basis if they enter the area. Kind of like block data definition chunks.
I also thought maybe just allowing the client full control over the 3d world based on players location chunks, and peer matching if other players were to enter their area. So would pretty much work like Lan death match games. So say a player would enter an area where no one else was, a new instance of that area would be created with all server chunk information blocks that are downloaded and passed on to that client, while waiting for new player connections to be matched into. So a players client can ultimately become a ghost server so to speak but for only 3d content, other players, and objects. All major traffic areas like huge cities, dungeons, player, and congregation points of interest can be controlled by the main server.
09/18/2013 (4:16 am)
This is an interesting read for me. Terrain paging, and massive worlds. I havent gotten to this point yet, but Ive been throwing some ideas around in my head. Which one was as Robert pointed out as far as loading different mission zones and interconnecting them. I thought maybe to give the player a choice to choose locations from a larger map for larger region jumps say from continent to continent. Since most player times is spent building living in their zone of control. The only thing I can see why a player would leave that zone would be to explore for resources, creatures,dungeons,or to find a new home.I dont know if this would be possible but.. I was thinking maybe using a 2d map that the server uses to keep track of objects, player positions, while any or all 3d world content is loaded client side this way its less load on the server, and all on the client as in games with huge worlds like Morrowind. I kind of remember this from the older isometric 2d games like Ultima Online where the 2d map moved while the player was stationary, but somehow improve on this idea to work 2d server side, while 3d client side. If any game world object, items, house would change the client can probably send the information to the server, the server can test if this is acceptable design, placement, position, make its calculations, and then store the information that will be passed back down to other players on an as need basis if they enter the area. Kind of like block data definition chunks.
I also thought maybe just allowing the client full control over the 3d world based on players location chunks, and peer matching if other players were to enter their area. So would pretty much work like Lan death match games. So say a player would enter an area where no one else was, a new instance of that area would be created with all server chunk information blocks that are downloaded and passed on to that client, while waiting for new player connections to be matched into. So a players client can ultimately become a ghost server so to speak but for only 3d content, other players, and objects. All major traffic areas like huge cities, dungeons, player, and congregation points of interest can be controlled by the main server.
#31
Yeah, I have been pondering the "chunk ownership" angle of this as well. I have noticed on MC servers that you can buy and own chunks. This also allows you to control who can do what where. In addition there are ownership rules for devices too. That will be a whole other ball of wax in addition to the terrain.
09/18/2013 (12:44 pm)
@Zeph,Yeah, I have been pondering the "chunk ownership" angle of this as well. I have noticed on MC servers that you can buy and own chunks. This also allows you to control who can do what where. In addition there are ownership rules for devices too. That will be a whole other ball of wax in addition to the terrain.
Torque Owner Daniel Buckmaster
T3D Steering Committee
Frank: for double precision positions to have any effect, the game needs to render the world as if the camera is at the origin. You calculate the relative positions of all the rendered objects in double precision, then these relative positions are turned into floats for the graphics card. This means the precision doesn't actually matter since it will only manifest in objects that are way far away where you can't see it. As opposed to manifesting right next to you.