Tackling the tge terrain

#1 One word: Atlas

#2 That's not a solution for tge. And tgea isn't a solution for multi-platform support. I'm looking for a terrain that works and integrates into tge. I'm not looking to spend another 300 for a terrain that i have to wrench into tge to make work. If i'm going to wrench it's going to be something more open source. I know tgea is gg's flagship product now, but given how buggy it is and that it doesn't have full afx support yet, not to mention being tied into directx, it really doesn't thrill me as an option.

Is there going to be opengl support for tgea? Why not update tge terrain and throw an editor in there as well?

#3 I too am using the original TGE terrain because of its current issues.

The way I see it, by the time my game is completed, Atlas will be mature enough to port my game to TSE. The biggest problem with the legacy terrain is the amount of assembly used. Really, the best approach for new terrain in TGE would be to write something from scratch.

You have to ask yourself: Is the amount of effort that would be required to implement a new terrain engine worth it when Atlas is currently being developed full time by GG?

#4 Well, given that we are in map production, i don't feel that converting all the maps over to the atlas flavor will be the best option, thats even if i can get it in tge without a great deal of headache. We aren't going to be using the legacy terrain or modifying it in anyway, but will be attempting to use demeter as a starting point.

Even if atlas is mature enough by release or sooner, i still have no desire to go tgea or purchase tgea after the wait just to merge atlas in. Granted we could hope that gg will do us all a favor and stick atlas in the tge, but i'm honestly not crossing my fingers there.

My biggest concern is with demeter being under the gnu lgpl and what that means to getting it into torque either as a dynamic lib or statically. It's mostly the release aspect, since i can't release torque source code to the public for free, nor can i stick demeter into torque without releasing those changes. I could however create a standalone editor (with torque hooks), release that, but still use that editor/engine inside torque separately. Or i could just run it as a dynamic lib and just release that. So it won't be a full rewrite in either case.

#5 I tried tackling the tge terrain myself and its really quite a mess spread out over many files. Then there is of course the terrain blender that actually blends all of the terrain textures together onto the terrain. Correct me if I'm wrong, but I believe that's the only ASM involved. The blender has a bunch of values in the .cc file that seem to manipulate the ASM though so I'm not sure if the ASM needs to be completely overhauled or if it will run fine just by inputting the right values. If you need any help let me know. In my opinion an terrain overhaul is what tge needs the most right now.

#6 I've looked at the terrain code in TGE before as well and I agree it could do with an update, unpicking it all to replace with a seperate lib though would be quite some undertaking.

#7 It seems to be a big job, which is mostly why i think there is still the legacy terrain in there to begin with. One of the best options i've found thus far is demeter, unfortuanately the demo app crashes an nvidia machine, but works fine on ati...

#8 What does the Demeter Terrain Engine have that stock TGE terrain doesn't? I downloaded the demo (worked fine on my Nvidia card) and couldn't see anything special - and you'd still have to write your own terrain editor and tools.

#9 I'd like to throw my support behind new terrain for TGE.

Also, I'd like to mention that I am sick to death of the standard response being: Atlas.

Even after Atlas is fixed, it is not cross platform. TGEA is not cross platform. For some of us, this is REQUIRED!

#10 @Tim - A couple major things... size (not only terrain size, but texture size), detailed brushes (splats), a far amount of dynamic loading code, base texture overlay, smoother transitions and cleaner code (thats more IMHO though). I'd also like to create caves or tunnels in my maps. I really don't know that demeter is the answer at this point, but there isn't much out there either that would seem to work for our needs, but since demeter is easy to use as a dynamic lib as well as a static one, it might be a pretty decent solution. It really is a good deal of work though and high levels of experience is lacking at the moment. It would be nice to get some gg support too!

#11 Unfortunately there doesn't appear to be a specific terrain engine in my opinion worth looking at incorporating into TGE:
1. Demeter doesn't appear to be under active development and there isn't an active community for it - I've tried on two different machines and it doesn't work on either
2. Ranger - no update since 2003
3. ADvantage - only at v0.86 and I believe is directx only.

There are others but all with seemingly similar problems. Which would leave something like trying to pull the terrain code out of Ogre/Crystalspace or creating your own. Or and I hate to say it again... what about Atlas?

I'm not a TGEA license owner at the moment... but from what I hear the main annoyances are with bugs and lack of cross platform support, if my understanding is correct TGEA was written with the graphics layer seperated (GFX) so that it would just be a case of writing an OpenGL function for each of the GFX hooks.... if that's the case surely it would just take one talented programmer with OpenGL/C++ knowledge to turn this into a cross platform engine also, whether that be on contract to GG (or perhaps GG could offer an incentive to the community for the first one to get this ported) or just a person/group from the community deciding to tackle. I can't afford the license at the moment but it's certainly something I'd be willing to help out with/have a go at tackling.

#12 So you're suggesting someone write opengl hooks for tgea? Or is it taking atlas from tgea and hooking it into tge? Of the 2 options i think the latter is more feasible and less time consuming.

I wouldn't want to make any of this more work then necessary, which is why i think a gg person should chime in with some advice. I can't affort the tgea license right now either and would rather attempt the work (as limited coding abilities i do have) then pay for tgea, try to work out those bugs and hook opengl into it.

#13 @Jason: Not actually true at all.

TGE-A graphics have been fully abstracted into something called the GFX abstraction layer. It is designed from top to bottom to allow for "plugging in" rendering devices that "un-abstract" your game level GFX calls to whatever rendering calls are appropriate for the target rendering system.

TGE-A comes stock with a DX9 render device that does exactly this for DX9. To render TGE-A on an OpenGL target requires implementation of an OpenGL render device, which actually doesn't touch any of the TGE-A code (other than the device implementation itself).

Regarding back porting Atlas--it's been said in the forums before by us, but TGE and TGE-A are two different products with two very different target hardware markets. Backporting Atlas would cause restrictions in what hardware can run the combined "TGE + Atlas" codebase, and is not something we are going to do.

#14 That's all fine and good then Stephen, right now our game budget doesn't support buying 3 or more tge-a licenses (not mention the lack of an upgrade path). If we were talking shaders specifically i could see an impact on the target market, but we are talking about out-dated terrain and tge-a still supports legacy terrain either way. Is it that you would like to focus your attention only on the tge-a now and just let tge get the smaller updates that trickle down from tge-a updates?

I can see some affects of this focus in that even the MK probably will die off, really killing any future of the tge. Not updating the terrain, or being willing to provide some help there, goes hand in hand with that too. Don't get me wrong, I'm not saying thats a bad thing, just that there's a good deal of folks with tge and many posts wanting an updated terrain which the only response being get tge-a and atlas. For many of us, we feel left behind and i only purchased the engine less then a year ago. I personally think that at least if the focus is failing off the tge, an upgrade path could at the very least ease the burden that indies like us continually succumb to.

One of the main reason i chose the tge and gg products is the community support as well as cost and level of features. I know that you guys wouldn't discourage the community to update parts of the tge, but i also feel like you're not even remotely interested in helping us do it either, which is just as discouraging. I understand the hardware issue, but i really don't see that as much in terrain rendering as i do in shaders, i could be way off base though.

Just a note I'm not disgruntled, or upset that there is less then stellar support for things like this or that the common response is "get a tge-a license", but as tge-a has a bit of work ahead of it to be as usable as the tge, i really don't see an incentive to incorporate openGL support for an engine that needs some maturity to work out the bugs. This not to mention that AFX is'nt even integrated as a standard in it yet, which is pretty cornerstone to our design. Meaning we have to make that merge work as well (including making zodiacs work on atlas).

#15 It sounds as if I haven't really made my point well, so let me try an analogy:

Hammers have been around for thousands of years in some form or another, and while minor modifications to them have been made, in general they fit a particular role for a particular job, and they work very well within those bounds. If I need to hang pictures on my wall, I'm going to use a hammer--it's the simplest, easiest, most cost effective way to get that single nail driven in to the wall.

Now, hammers have advanced--we have things like pneumatic hammers, and for certain situations it makes a whole lot more sense to use that tool instead. For example, if you are hanging drywall and using an ordinary hammer, you may not be as efficient as someone using a pneumatic hammer. Thing is, you may just be so damned good with a normal hammer that the pneumatic hammer slows you down, and it's not worth the investment for the more expensive pneumatic hammer.

It's a tools choice decision--what is my requirement, what tools are available to assist me in meeting those requirements, how skilled am I at using those tools, and do they meet my budget?

I don't want to go point by point, but I will follow up specifically on one thing:

Quote:I can see some affects of this focus in that even the MK probably will die off, really killing any future of the tge.

From our perspective as a business that provides tools (engines in this particular case), TGE and TGE-A fit two very different markets: TGE is designed for broad spectrum hardware over a span of many years, while TGE-A is designed to meet current and future hardware capabilities. There exist break points in hardware where you cannot do both--if we made the modernization kit stock in TGE, we would immediately cut down the hardware spread by forcing shader capable cards (not to mention other issues), and since the entire market position of the TGE project is a maximal hardware spread, that would be defeating the entire market target of that engine in the first place.

Will the MK be put in as stock in TGE? No, it will not. Does that mean MK will die off? That's up to users of TGE and how they may want to modify their target hardware market for their particular product.

Does this "kill the future of TGE"? Absolutely not. Sure, eventually all of those 5-8 year old computers, video cards, and "previous generation" hardware will die off, and at that time sure, TGE probably isn't a good tool/engine choice anymore. And yes, I agree, certain aspects of TGE (in your case, terrain) may fall out of best effectiveness earlier or later than others, but in general the engine has a quite extensive future, if properly selected as a tool/engine for an appropriate task.

I absolutely applaud those developers that are interested and willing to modify any aspect of either engine to meet their needs-after all, that's why we provide the source code, so you can. However, that doesn't mean that GG will be an active participant, but it also doesn't mean we won't.

When it makes sense from the big picture regarding product market goals and capabilities vs resource investment, TGE (and the rest of our engines) will make incremental changes, but the existing terrain system in TGE (and "legacy" terrain in TGE-A) isn't an area we currently feel requires extensive modification for the core product line.

#16 Stephen, I understand your analogies and they are certainly amusing. Really the point of this thread was to see what our options looked like and maybe get some help in making a wise choice for the solution. I'm sorry we had to go off into marketing strategies and stuff about hammers.

The bottom line still stands, being a non-profit group and having limited funds to develop our goals, we need a solution to the limited terrain issue, as do several other folks. Given what i have already described as possible options, we should all intelligently decide what will make the best use of our time to reach that goal. So again, support on this is welcome, but the answer "atlas" isn't of much help at this point.

An option is for all of us to just migrate to tge-a and deal with our respective issue (including AFX and cross-platform support), bugs and so forth. But, given thats not an option that will work best for us right now, let alone lack of an upgrade path being available, what else can we do?

Thats the key question...

#17 While trying to ignore the marketing drone's hammers, a terrain replacement for TGE and further work on the MK is almost required to make TGE of better use to modern games. I'll also point out that if GG had written the OpenGL layer as they said they would we all would not be having this conversation. If GG would allow a developer to sell an OpenGL layer for TGEA for profit, we also would likely not be having this conversation.

/rant

@Jason:

I think real discussion and planning for a terrain replacement for TGE is a very good idea. I've also looked over existing terrain solutions and really haven't found one that fits the bill. Porting Atlas to TGE is probably not the best solution as it would require anyone who uses it to have both TGE and TGEA. So that pretty well leaves either improving on the current TGE terrain, or writing one from scratch. I've not gotten further than just thinking about the problem, and I'm really not sure which option would be best.

@Stephen:

If you are not part of the solution then you are part of the problem ... and we have enough problems, thank you.

#18

Quote:
@Stephen:

If you are not part of the solution then you are part of the problem ... and we have enough problems, thank you.

Nice one--way to guarantee you won't be receiving any help from me personally.

Quote:
While trying to ignore the marketing drone's hammers, a terrain replacement for TGE and further work on the MK is almost required to make TGE of better use to modern games

Might want to check your references--I don't work in marketing, I teach Torque Technology. I'm one of the ones that would have actually helped you figure out best practices for building something like this once we got past the "it's GG's fault I don't like the terrain" level and down in to the design.

#19 You have got to be kidding.

The "marketing drone" comment was based on your behavior, not your job title and it was not provoked simply by your comments here, but in other threads as well.

#20

Quote:
The "marketing drone" comment was based on your behavior, not your job title and it was not provoked simply by your comments here, but in other threads as well.

It doesn't matter what it was based on--if you are going to be insulting to anyone, even employees, you aren't going to receive much assistance.