TorqueX equals an incomplete TGEA
by James Brad Barnette · in Torque Game Engine Advanced · 06/14/2007 (11:31 am) · 150 replies
I have noticed click here that it seams that the features of TGEA are being ported. to torqueX. I understand this from a business perspective. I think that TorqueX is prolly the way of the furture. But I feel that it is comming at a cost to customers that have already bought TGEA.
Just curious. if someone at GG would care to elaborate about the percentage or numbers of their staff that is now working on torqueX vs TGEA fulltime.
I mean from an existing cstomers perspective " one that is getting ready to do at least 2 commercial projects with TGEA" it seems a bit A.D.D. the way nothing seems to ever really get finished and there is always some new project that is taking resources away from existing ones.
If the plan is to eventually only use the torque engine will existing licensees be given upgrade pricing when TorqueX is complete?
Just curious. if someone at GG would care to elaborate about the percentage or numbers of their staff that is now working on torqueX vs TGEA fulltime.
I mean from an existing cstomers perspective " one that is getting ready to do at least 2 commercial projects with TGEA" it seems a bit A.D.D. the way nothing seems to ever really get finished and there is always some new project that is taking resources away from existing ones.
If the plan is to eventually only use the torque engine will existing licensees be given upgrade pricing when TorqueX is complete?
About the author
#142
So Stephen what you're essentially telling us is that Atlas isn't worth a damn unless you want to make a torque-based google earth? That's a very interesting statement and the first time I've heard it. I doubt you would find many people who knew that Atlas wasn't meant to replace legacy terrains for games. I wouldn't have bought the EA if I knew Atlas were going to be that worthless. This is also counter to Brian Rampage having said on July 28th 2005 about cutting holes in atlas: "This and many other features will be added back in the next update"
This also doesn't clear up the fact that with your large real-world Atlas satellite derived datasets, the game engine itself doesn't support them. Like this poor guy who was making a WW2 game with Atlas. garagegames.com/mg/forums/result.thread.php?qt=61726
I guess we can sum up with the statement "Atlas = Epic Failure"
08/23/2007 (3:14 pm)
Quote:It is also extremely important to note that Atlas was never truly meant to replace "legacy" terrain systems for "by hand" created worlds--it was designed to be much more in line with using real world data sets (earth geometry, with real world space based texture captures, although alternate usages exist), and real time editing is not a necessary workflow capability with this type of data set.
So Stephen what you're essentially telling us is that Atlas isn't worth a damn unless you want to make a torque-based google earth? That's a very interesting statement and the first time I've heard it. I doubt you would find many people who knew that Atlas wasn't meant to replace legacy terrains for games. I wouldn't have bought the EA if I knew Atlas were going to be that worthless. This is also counter to Brian Rampage having said on July 28th 2005 about cutting holes in atlas: "This and many other features will be added back in the next update"
This also doesn't clear up the fact that with your large real-world Atlas satellite derived datasets, the game engine itself doesn't support them. Like this poor guy who was making a WW2 game with Atlas. garagegames.com/mg/forums/result.thread.php?qt=61726
I guess we can sum up with the statement "Atlas = Epic Failure"
#143
First, I believe it was Ben Garney who posted that. Secondly, back on July 28th 2005 Ben probably thought his next update would solve the issues. Obviously he ran into some snags, since it was not long after that Atlas2 made its emergence.
You know, dredging up forum posts from 2 years ago and treating them as contracts written in stone is not going to help the communication issue at all. If that sort of thing keeps up, all that is going to happen is GG employees will stop posting anything on the forums. Have you said anything in the last 2 years that has not come true or promised to do something you haven't done? Anything? Did you promise to be somewhere then something made you late? Stuff happens. Life happens. Things change. Especially in software development projects.
If you really think GG should be held accountable for everything that anyone posts, from now to infinitely, then I think you should live up to the same standards. I challenge you, right now, to post a milestone list and timeline for your game. Then, you stick to it. I don't care if both your legs get broken in a car accident 2 years from now, 'cuz you posted your Milestone list. Everything you post will be considered legally binding.
I would be extremely surprised if 1 software project in 1,000 hits every Milestone or feature they plan for at the outset. It is a fact of life in Professional software development. Anyone who has worked as a Professional software developer on a project larger than trivial size learns these lessons. This whole argument has become ridiculously unreasonable.
08/23/2007 (3:59 pm)
Quote:
This is also counter to Brian Rampage having said on July 28th 2005 about cutting holes in atlas: "This and many other features will be added back in the next update"
First, I believe it was Ben Garney who posted that. Secondly, back on July 28th 2005 Ben probably thought his next update would solve the issues. Obviously he ran into some snags, since it was not long after that Atlas2 made its emergence.
You know, dredging up forum posts from 2 years ago and treating them as contracts written in stone is not going to help the communication issue at all. If that sort of thing keeps up, all that is going to happen is GG employees will stop posting anything on the forums. Have you said anything in the last 2 years that has not come true or promised to do something you haven't done? Anything? Did you promise to be somewhere then something made you late? Stuff happens. Life happens. Things change. Especially in software development projects.
If you really think GG should be held accountable for everything that anyone posts, from now to infinitely, then I think you should live up to the same standards. I challenge you, right now, to post a milestone list and timeline for your game. Then, you stick to it. I don't care if both your legs get broken in a car accident 2 years from now, 'cuz you posted your Milestone list. Everything you post will be considered legally binding.
I would be extremely surprised if 1 software project in 1,000 hits every Milestone or feature they plan for at the outset. It is a fact of life in Professional software development. Anyone who has worked as a Professional software developer on a project larger than trivial size learns these lessons. This whole argument has become ridiculously unreasonable.
#144
08/23/2007 (4:08 pm)
Why doesn't someone start a new thread and call it feature list or something. This thread is so convoluted, so spiraling it should probably be put out to pasture.
#145
Seriously, check out how Delta3d manages paged tiled terrain. Infinite landscape, divided into tiles, directly integrates with things like DTED terrain height maps and other geo-rectified data like GeoTIFFs. It also supports the whole idea of "decorators" for tiles such as trees and other models. Terrain meshes have dynamic LOD applied with varying based on terrain complexity and viewer eye distance. See this tutorial for a tutorial describing the system.
If Torque had something like the Delta3d terrain system it would be a real winner.
08/23/2007 (5:31 pm)
Quote:Actually this exact idea is why I initially went with TGEA thinking it would be "the solution" for my project, but I was never able to consistently integrate in my real world data without a huge amount of hand holding and massaging. Altas is quirky, crash prone, and the error messages leave a lot to be desired. It's also extremely limited in that you can only have a single terrain "thing" in a world - which is a problem when you're trying to make a world that's say 4-500 kilometers across.
It is also extremely important to note that Atlas was never truly meant to replace "legacy" terrain systems for "by hand" created worlds--it was designed to be much more in line with using real world data sets (earth geometry, with real world space based texture captures, although alternate usages exist), and real time editing is not a necessary workflow capability with this type of data set.
Seriously, check out how Delta3d manages paged tiled terrain. Infinite landscape, divided into tiles, directly integrates with things like DTED terrain height maps and other geo-rectified data like GeoTIFFs. It also supports the whole idea of "decorators" for tiles such as trees and other models. Terrain meshes have dynamic LOD applied with varying based on terrain complexity and viewer eye distance. See this tutorial for a tutorial describing the system.
If Torque had something like the Delta3d terrain system it would be a real winner.
#146
I stated an original design goal of the original Atlas system, and you take it out of context and make rather far reaching conclusions--and then drag up multiple year old posts to debate the statement and/or "prove" your point.
@Tim: I agree--due to much of the community's input (as reflected by many of the posts here), original Atlas design goals were modified as much as possible, and resulted in a system that doesn't leave either design assumption set (real world accurate data set, fictional terrain geometry/texture data sets) amazingly powerful.
08/23/2007 (6:13 pm)
@Jacobin: I think this is the second, or possibly the third time in this thread alone where someone has demonstrated that our "opaque" development practices are the only "safe" mechanism for communication with forum users for paid products.I stated an original design goal of the original Atlas system, and you take it out of context and make rather far reaching conclusions--and then drag up multiple year old posts to debate the statement and/or "prove" your point.
@Tim: I agree--due to much of the community's input (as reflected by many of the posts here), original Atlas design goals were modified as much as possible, and resulted in a system that doesn't leave either design assumption set (real world accurate data set, fictional terrain geometry/texture data sets) amazingly powerful.
#147
I would also like to point out that we are using real-world height data for our game and have been extremely happy with Atlas' results in this respect. Real-world terrain features are replicated perfectly (in proportion) and we have been able to use actual lat and long coordinates of cities for exactly placement on our terrain.
08/23/2007 (6:49 pm)
Quote:t's also extremely limited in that you can only have a single terrain "thing" in a worldReally? Several people have successfully tiled or "layered" several Atlas terrains in a single mission. This is one of its biggest advantages over the legacy terrain system.
I would also like to point out that we are using real-world height data for our game and have been extremely happy with Atlas' results in this respect. Real-world terrain features are replicated perfectly (in proportion) and we have been able to use actual lat and long coordinates of cities for exactly placement on our terrain.
#148
light/shadow issues fixed. Which I belive that is something that should be generated at runs time on a per-object basis so that they can be added or removed during play.
The ability to cut a hole in the Atlas terrain so as to allow for subterrainian play. I have an idea on this. perhaps a mask could be implemented and areas inside the masked areas simply didn't render or collide. fo corse you would need to take the areas and use the Editor in L3DT to flatten them or something to make sure that you had verts surrounding the area. I don't know about the mask part but if you used the editor in l3DT and punch a hole in L3DT and then flatten the area at the bottom out you should end up with a nice ring of verts arouns the edge. it is just a matter of getting it not to render or collide.
A plugin that just works. I don't know why it crashes at over 2048x2048. But it would seem to me that if people can type it in by commandline and it works then a plugin should be able to do this woth out crashing. I don't know what the problem is mind you. Is it that the larger the terrain the the larger the number of variables in the equation to find what will work?
I know for me this and some better docs and I would be happy as can be!
08/23/2007 (8:11 pm)
Yeah in my limited opinion I think Atlas 2 would be top notch if it had the following features:light/shadow issues fixed. Which I belive that is something that should be generated at runs time on a per-object basis so that they can be added or removed during play.
The ability to cut a hole in the Atlas terrain so as to allow for subterrainian play. I have an idea on this. perhaps a mask could be implemented and areas inside the masked areas simply didn't render or collide. fo corse you would need to take the areas and use the Editor in L3DT to flatten them or something to make sure that you had verts surrounding the area. I don't know about the mask part but if you used the editor in l3DT and punch a hole in L3DT and then flatten the area at the bottom out you should end up with a nice ring of verts arouns the edge. it is just a matter of getting it not to render or collide.
A plugin that just works. I don't know why it crashes at over 2048x2048. But it would seem to me that if people can type it in by commandline and it works then a plugin should be able to do this woth out crashing. I don't know what the problem is mind you. Is it that the larger the terrain the the larger the number of variables in the equation to find what will work?
I know for me this and some better docs and I would be happy as can be!
Torque 3D Owner Stephen Zepp
In the interests of being slightly less transparent, I'll give this one a go:
--the fundamental challenge with real time editing of Atlas terrains is mesh decimation.
To briefly explain: By definition, when you want to "level out a small area of an Atlas terrain", what you really want is the ability to real time modify the highest level of detail chunk of an overall terrain geometry set. For this to work at all levels of chunked LoD, you then need to take that modification, and propagate it all the way up the levels of detail to the top chunk, in real time--which is a process that takes seconds/minutes/hours, depending on the nature of your terrain geometry set, as well as what turns out to be extremely non-trivial technology.
To understand why this is such a challenge, you need to take into account a few things:
design assumptions of Atlas : Atlas is a terrain engine that is designed to take a very large set of geometry and texture data, and pre-process it (prior to run time) into a different configuration ("chunks") that allow for threaded data streaming, dynamic chunked level of detail, and extremely large visibility distances (a by product of the combination of chunked lod and clipmap based texture manipulation). More on large visibility distance challenges below.
It is also extremely important to note that Atlas was never truly meant to replace "legacy" terrain systems for "by hand" created worlds--it was designed to be much more in line with using real world data sets (earth geometry, with real world space based texture captures, although alternate usages exist), and real time editing is not a necessary workflow capability with this type of data set.
A secondary use of Atlas is what most people are trying to use, and having mixed success: preparing "fictional terrain" data sets (normally through external terrain generators such as L3DT), and then expecting to be able to manipulate them in real time in a similar style as legacy terrain. As has been stated (correctly), this concept (real time editing) works with the legacy terrain engine because the concept is entirely different: legacy terrain is stored internally as simply a height map, and is processed in real time as a textured poly set--but this is performed every single frame. Atlas is more powerful in that it does all of the processing prior to run time, but is less flexible because it is dependent on that real time processing.
An analogy to the above would be the differences between art assets created for real time processing (games), vs art assets created for "render farm" rendering--or, to be direct: "Toy Story" is not an art asset set appropriate for real time rendering, but if you are willing to accept pre-run time (or in that case, pre-view time) processing, you can be more visually appealing.
tradeoff between run time performance, and pre-run time asset pipeline. By definition, Atlas (and Atlas 2) is designed to optimize run time performance, at the cost of terrain asset preparation costs. This is a design decision, and an important one. In effect, what is being asked for is to reverse this design decision, and instead optimize for pre-run time asset pipeline--a non-trivial design change. I will go out on a limb and state officially that the risks and resource development cost of minimizing the impact of this design decision were not properly researched, and considered somewhat trivial, when in fact it is not.
Finally, a quick description of the issue of large visibility distance challenges: "z-buffer fighting" as it is commonly called is a direct result of trying to optimize visibility range, and ultimately is a precision issue. As your visibility distance goes up, the precision of your z-buffer goes down (fundamental hardware issue with how video cards work), and it is very non-trivial to develop a completely agnostic general technical solution to the issue. There really is no "magic tech fix" to the problem, and to gain the advantages of this type of implementation, you give up the ability to easily manage the z-buffer sorting issues that result in overlapping geometry/texture flickering.