TorqueX equals an incomplete TGEA

#121 To add something to the "limitless paged atlas terrain"

You don't even need limitless.

Give yourself 5000 view range, add a water block, look some away area and rotate the cam a little.
You will get flickers that are worse than anything I've ever seen in the zfight area and my last project was with Blitz3D, a closed source DX7 engine with no higher end T&L features ... but even there 15000 view range was no problem, zfights like this one needed view a maxRange/minRange ratio of 20000 and higher.

EDIT: At least I assume this to be zfight issues from what they look like. but might be a simple precision problem.

right now it isn't a problem to me as the project I'm part of fully bases on legacy terrains.

#122 Marc, thanks for your notes on the docs, I'll be slowly correcting/adding what I can in there.

#123 Re: Accuracy/precision issues with huge world spaces...that's pretty much a fundamental limitation with floating point values(ignoring 64bit since that brings the issue of speed and less installed hardware base) as they exist in current computer architecture. Yes, GG could write a specific system to work around it, but it would likely be game specific and would require substantial editing of the engine to support such a thing. Thus it'd be much better to focus on the majority of games, which don't usually run into such problems(given most games have limited world size). And since, aside from the amount of small changes, it's a relatively simple problem (referring to the GPG4 article's system below), it's much better to have people solve it for *their case* in particular at the game level. This gives the majority of people a working solution that doesn't sacrifice performance, while the smaller amount that actually need huge precision for large worlds (myself included on my own personal project) can implement something that will work *really* well for their particular case(rather than GG putting in something that "sorta works" in all cases).

I suggest checking out Game Programming Gems 4 article, "Solving Accuracy Problems in Large World Coordinates".

There are other ways to go about it even. Break your game up into multiple missions each of a size that doesn't cause accuracy issues at the farthest extents. That's the simple way. If you must have something that's entirely continuous, do as in the GPG4 article(for those without, the idea is to store an integer offset from the origin, then do positions with normal 32bit floats from there).

#124

Quote:
They wanted an easy way to flatten areas of the map or cut holes in atlas in order to properly place DIFF structures.

That's probably the most difficult part of an Atlas editor. I'm saying I don't think we're going to get it. What do you do when you want to change a DTS or a DIF? You go back to the original editor. That's what you need to do with Atlas, go back to L3DT and make your changes.

#125

Quote:
Yes, GG could write a specific system to work around it, but it would likely be game specific and would require substantial editing of the engine to support such a thing. Thus it'd be much better to focus on the majority of games, which don't usually run into such problems

This was my point as well.

I think what we're dealing with, at the root, is a mentality difference. Instead of considering the Torque engine a "right" I think it should be more considered a "privilege." Allow me to elaborate. Up until a few years ago, if an Indie wanted to make their own game they had to write it from scratch, all on their own. Now that we have GG and Torque we don't have to start completely from scratch. However, one should always keep in mind that if this product hadn't existed, you would be doing it all yourself. So, when you run into a shortfall in Torque, instead of thinking "They should have done this for me!" remind yourself "If Torque wasn't around, I'd have to do this anyway!" So be thankful for what Torque does do for you because it saves you the time and energy of having to do it yourself.

About 5 years ago I tried writing my own engine. After a few months and 1000's of lines of code I had something with a feature set resembling the original NES. I know how much work it was just to get to that point. So I'm not taking anything that Torque gives me for granted.

Those are my thoughts.

#126 Every serious 3d programmer should, at some point, attempt to write an engine from scratch. When I was in college I skipped numerous classes and stayed up way too late working on an engine. I got as far as .OBJ data importing, had my rabbit, got lighting working...then I looked at what I'd have to do to get texturing in and said, "Ok that's enough of that."

I highly, highly recommend starting with NeHe's GL tutorials and start building in whatever way makes most sense at the time. The knowledge gained from such an attempt is invaluable.

#127 Couldn't agree more :)

Or do it vice versa: use a somewhere understandable engine, and ask yourself why it does what it does and that till down to the low level ... and think about why it is good / bad that it is done that way ...
helped me a lot understanding general problems that can arise and limitations of even current gen systems

#128 Pat Wilson,

I agree whole heartedly!!

I remember getting the Torque Game Engine years ago as a way to look into the code of a full game engine so I could learn game programming. It was like diving into the middle of the ocean before learning to swim. I was completely overwhelmed. I thought it would be like picking up coding with applications like Adobe Photoshop or Intuit Quickbooks that I'd jumped right into their SDK. Boy was I wrong.

I enjoyed working with the editor and scripts which was a lot easier to pick up. When it came to the game engine I found that I had so many pieces that I needed to learn before I'd even begin to understand how they work together that I finally decided it was a better idea to learn to code a basic game engine myself.

Yes, NeHe to the rescue. And after NeHe is was many other websites and books until I actually settled on learning with C# and MDX. Now, you can criticize that decision, but the point was to learn to code a basic game engine so I would be able to have an entry point to work with complex game engines. Little did I know that there would some day be a C# XNA Torque Game Engine as well.

Now it's my day job to work with the Torque Game Engine and add and change the engine. It was a long tough journey to get here, but I do realise now that I was so far out of my scope of understanding when I used to give GG shit over their game engine progress or certain features that I thought should be in Torque.

I realise that to make a game for real... you need to be able to add or change whatever you want. I also realised that there was no way in hell that I'd ever want to write my own 3d game engine from scratch ever again. :P I'll take fixing, adding and changing Torque any day.

#129

Quote:That's probably the most difficult part of an Atlas editor. I'm saying I don't think we're going to get it. What do you do when you want to change a DTS or a DIF? You go back to the original editor. That's what you need to do with Atlas, go back to L3DT and make your changes.

I think situation is a little different with DTS and DIF.

When you tweak a model it does not take long (in my experience )to re-export and correct any mistakes you may have had as the chances are you we almost done anyway before you exported it in the first place.
Fixing a texture or adding a bone etc is not a huge job because the process is more streamlined and you only have the model, and what's happening to it, to worry about.


Correcting "fixed terrain" is harder because you cant preview it correctly until its in game to see how it fits with everything else. Any small mistakes would take forever. You cant just patch a texture in L3DT you need to start again. You cant add a model to see if it fits in the space you just made, as its all guess work at this point. Trial and error

If everything is generated procedurally in L3DT there are 7 maps to redo if you change anything.

Can we all afford this time?

My maps in L3DT take hours to render, i have had one take15 hrs and when it was still not finished, i gave up on it until the pause/resume is feature is implemented, and im only testing with non-production ready terrain. I actually want to use much larger and more detailed textures, normal maps, light maps etc. and im guessing it will take a days to render.

This is not a feasible way to work unless your maps are small and "not limitless paged atlas terrain"


Imagine if a map takes 4 or 5 hrs (which is about the size of the maps i do for my feature tests.), every time you wanted to move a hill raise a valley, you would have to re-render everything you have done so far. if you had to do this 20-30 times or more with a game that has hundred of objects we are talking serious dead time.

IMHO editing terrain in TGEA is a must have feature and one we need before Atlas can be taken as a serious alternative to legacy terrain. Until its possible, mistakes are too costly.

#130 Compiling large maps for many hours. Reminds me of compiling Quake maps back in the day. If you want an in-game editor for ATLAS, then seem to be saying that you want them to take the time to re-create L3DT, but inside of Torque specifically for ALTAS terrains. Because that is exactly what you are asking, just like many people asked for Constructor because they did not like Quark and could not legally use Hammer/Radiant. Creating such an editor is an extremely daunting task, which is why there are external editors for doing it. And creating terrain assets for other engines with L3DT will lead to the same issues.

#131

Quote:
metalliandy said:
IMHO editing terrain in TGEA is a must have feature and one we need before Atlas can be taken as a serious alternative to legacy terrain. Until its possible, mistakes are too costly.

I agree with you.

But, as Pat said - if you haven't written an engine from scratch, you don't know how hard it is. In other words: it's not their fault they published a milestone list which they couldn't follow trough. It's your fault for not having made a 3d engine before.

You get it? I don't.

#132 Man you guys must be making some rediculasly large terrains. I do this that there need to be a solution for cutting a hole in the terrain though. the ability to have subterrainian levels is something that MANY games could use.

I use L3DT and I must say I'm not having really having any problems rendering out terrains. And as long as the project file is saved I can go back and make changes and re-export. It has worked very smoothly for me. I would like to see the L3DT exporter improved so that it will handle exporting reguardless of size though.

But I don't think that is a GG issue. Didn't Ben write that? Is his absence a permanent thing?

#133 Forgive my ignorance, but wouldn't it make sense to correct any errors in the terrain generation systems before working on a terrain editor?

I mean, wouldn't coordinate rounding errors etc. also cause problems for the editing systems?

#134 I apologise David, that was not the intention of my post.

I was trying to point out that changing exported terrain, currently is allot harder to do than tweaking a model due to the many considerations that must be taken into account.

All i am asking for is the ability to move terrain around and patch textures here and there In game so i can tweak the exported maps without having to re-render them in full using L3DT.

I do not mean massive terrain edits or creation, just move a hill a bit here and adding a little more grass texture there, without having to guess if it will be enough or too much.

GG did it with the legacy terrain, why is it so hard with Atlas?

I mean this as a serious question, what is/was the limitation or block that they hit/are hitting that is that hard to overcome.

surely they must of thought about this situation during the conception process?

I do not want GG to recreate L3DT in TGEA as it is a brilliant program and one that i use and will continue whilst creating my maps.

Arron is a superb coder and works tremendously fast, often incorporating requested features and fixing bugs within a few days-weeks of the users asking....Imagine what he could do with Atlas if GG gave him the code..lol


@james The maps i make currently are not huge... the design maps are 2048x2 with x8 everything else.

L3dt works like a dream, thats not the problem...Its tweaking in game that's causing the headache.

And yes it is a shame that currently the GG Atlas exporter can only handle 2048x2 map i believe, though this is not down to L3DT.
You can create mega terrains (in the Gpx range) if you had enough time. :)

#135 Perhaps it is because it is a completely different type of terrain system that uses extremely large images that are chunked up. Perhaps it should chunk them smaller and allow editing of specific chunks, but then matching up the edges of those chunks may be problematic if you do any hieght-work. Or blending over edges if you do any texture alignment.

I haven't looked at the ATLAS code very much to see what it is doing. It might be a simple fix, but if that were the case, it would seem to have been done already. It may be a huge hairy complete rewrite of the terrain system in accordance with an editor in mind, too. Which would be a good reason that it hasn't been done.

Has anyone here played with the ATLAS code to see what is going on under the hood? I haven't, and so I don't know what it would take to implement such an editor, even on the simplest terms.

#136

Quote:
GG did it with the legacy terrain, why is it so hard with Atlas?

Because Atlas is something completely different. The Legacy terrain was rendered and textured basically every frame right from its "component parts." It started right from the heightfield, then brought in the Opacity info for the textures, then pulled in the source textures themselves and rendered the whole thing together. This resulted in something that was extremely easy to change and edit.

Atlas has much more in common with DTS and DIF objects than it does with the old terrain system. The Atlas file is a custom format that stores Geometry (mesh) and texture information. Editing that information is difficult due to the amount of it and the complexity. For one it's all broken up into "chunks" that get LOD'd independently (hence it being called a "chunked LOD" terrain system). From what I've seen "leak out" to the forums, the largest difficulty is recursively generating the higher LOD's after the lowest LOD has its mesh information edited.

See this thread for more discussion on this topic. The post by Mary Westmacott does a good job outlining the headaches involved.

#137

Quote:But, as Pat said - if you haven't written an engine from scratch, you don't know how hard it is. In other words: it's not their fault they published a milestone list which they couldn't follow trough. It's your fault for not having made a 3d engine before.

You get it? I don't.

That actually made me chuckle. :)

Quote:I think what we're dealing with, at the root, is a mentality difference. Instead of considering the Torque engine a "right" I think it should be more considered a "privilege." Allow me to elaborate. Up until a few years ago, if an Indie wanted to make their own game they had to write it from scratch, all on their own. Now that we have GG and Torque we don't have to start completely from scratch. However, one should always keep in mind that if this product hadn't existed, you would be doing it all yourself. So, when you run into a shortfall in Torque, instead of thinking "They should have done this for me!" remind yourself "If Torque wasn't around, I'd have to do this anyway!" So be thankful for what Torque does do for you because it saves you the time and energy of having to do it yourself.

I would 100 % agree with you Mark, if the engine was open source.. ie free. But, its not, and since it cost afew hundred dollars a seat, that privilege you mention more feels like a right lol. No.. I just tried to think of it as a privilege and it didn't work. everytime I do, I keep thinking of the thousand+ dollars we spent in all, and I'm not use to paying money in those amounts to feel thankful when I run into shortfalls.


On the other hand, I fully understand the work that has, and will be put into TGEA by the GG guys. I think they are doing good work, and I DO find it a privilege to gently give them a nudge so they are aware of specific issues to fix.

#138 A really quite brilliant and effective terrain system exists in Delta3d (http://www.delta3d.org). Terrain is tiled, infinite, and extremely easy to work with including importing of data. 1 day's work with Delta3d and I was where I needed to be after spending too long with Atlas.

I gave up on TGEA's terrain system after beating my head against the wall for too long. Over promised and under delivered, which is something that at least is being admitted to above in a way.

#139 You know, not being able to match a software project plan that was made months and months in advance is not something that is unique to GG. All that is happening here with people harping about GG "not living up to published milestones" is a reinforcement of GG's decision to not publish anything. I guess we, as a community, aren't ready for it.

#140

Quote:
But, as Pat said - if you haven't written an engine from scratch, you don't know how hard it is. In other words: it's not their fault they published a milestone list which they couldn't follow trough. It's your fault for not having made a 3d engine before.

That's not what I said.

The result of writing an engine from scratch is not saying, "Awww they have it so tough, I won't complain anymore." It's more simply, "Oh."