Integrating a larger terrain in TGE project
by Stephan - viKKing - Bondier · in Torque Game Engine · 11/15/2006 (12:54 am) · 48 replies
Ok, how many would be ready to pay to have a larger terrain integrated in TGE?
I presume that would be around US$50 - if GarageGames is ok.
This is only a market study at this time.
Thanks.
STef
I presume that would be around US$50 - if GarageGames is ok.
This is only a market study at this time.
Thanks.
STef
About the author
Contributor to Dark-Wind: War on Wheels from Sam Redfern.
#2
11/16/2006 (4:53 pm)
Two here.
#3
11/16/2006 (5:00 pm)
I think they did this, but the called it TSE / TGEA and its not 50$ its 150$
#4
@Pauliver - don't want TSE, not what's being asked for really but thanks for playing all the same :)
11/16/2006 (6:49 pm)
You can count me in on this too. @Pauliver - don't want TSE, not what's being asked for really but thanks for playing all the same :)
#5
11/16/2006 (9:12 pm)
I'd be very interested in this but only if were officially supported by Garage Games.
#6
11/17/2006 (8:38 am)
Ya for sure. but i dont think they could make a larger terrain for TGE. probably from the way they coded it. otherwise i'm sure they would have done this already.
#8
12/16/2006 (6:57 am)
Interested too!
#9
12/16/2006 (7:32 am)
I'm very much interested, too, but what Pauliver said is true. Considering one of the main features of TGEA is large terrain, there is probably a very very very good chance that you won't see an official large terrain TGE addition from Garage Games. Not to say someone else won't offer a resource, but it won't be Atlas quality.
#10
12/16/2006 (8:12 am)
There was GORPE, but that is long ago. I would use that before the current Atlas anyday, but it is not easy to integrate into the newest Torque incarnations.
#11
It looks cool and something that might suit my needs at the moment...
12/16/2006 (1:12 pm)
Stefan - what's happen to that resource? Is it still available in some form?It looks cool and something that might suit my needs at the moment...
#12
12/16/2006 (1:17 pm)
Not sure if there are any working links still around, but I am sure quite a few people have it collecting dust. Someone named David (names escapes me atm, could it be Blake?) used to be working with it but I do not think he got anywhere.
#13
12/16/2006 (1:33 pm)
You can already have massive terrains in legacy. Still, I'd be interested in more advanced rendering features in the terrain code.
#14
STef
12/16/2006 (1:36 pm)
@Matt: would you mind detailing your statement here, as long as it is not related in modifying squaresize to 32.STef
#15
12/16/2006 (2:16 pm)
I really don't understand what you want to do exactly. Changing the squaresize to 14 is usually too large anyway. What exactly is the purpose on having large terrains and how would you expand upon it? Personally my problem is not having enough content in the world. Another problem is having large, yet unrealistic terrains. Also, even if you do get the content in texture memory issues are always a problem. Honestly I'd be more happy with new rendering techniques than larger terrains. Just my opinion though.
#16
12/16/2006 (2:55 pm)
You're avoiding his question though. There's no way to get massive terrains with legacy unless you dwelve into the code. Though your defination of "massive" might be different than mine. :)
#17
12/16/2006 (3:13 pm)
I think our definitions of large terrains are different. I regard higher square sizes as larger terrains, and feel a 16+ squaresize terrain is large enough. Perhaps you or Stephan could explain what you mean.
#18
It was worthless. Yes, it would page terrain blocks off disk. Yes, it would render them across boundaries--but that's it.
No cross boundary (from one terrain block to another) ray casting--which means no targetting, no collision, no AI, and a whole host of other things required to make it work as a seamless paged terrain system.
And the biggest part is, no one that thinks they want larger terrains has actually researched or even begun to design what the real issues are:
performance and indirectly networking.
Let's say you are able to get a perfectly working paged terrain block system in place using legacy terrain concepts (height maps). You've overcome the challenges of pushing so many terrain textures to the video card without destroying FPS, and you've handled all the corner cases of boundary transition.
How are you going to optimize the performance of your server and client when there are 50,000 objects required to populate this terrain, each getting a processTick() call at a 32 millisecond frequency?
How are you going to handle instancing standup and management of links across multiple servers in your back end?
How are you going to handle control object migration across these servers?
Larger/paged terrain is the least difficult challenge with "big worlds". If you can't implement it yourself, you won't even come close to solving the real challenges.
Sorry if I come across as rude/arrogant in this post, but it is a very common post that wants "larger/more terrain" in any game without thinking through what that really entails--enough for me to post about it.
12/16/2006 (3:19 pm)
For what it's worth, I had a copy of the latest Gorpe "massive terrain" work back before I became an employee.It was worthless. Yes, it would page terrain blocks off disk. Yes, it would render them across boundaries--but that's it.
No cross boundary (from one terrain block to another) ray casting--which means no targetting, no collision, no AI, and a whole host of other things required to make it work as a seamless paged terrain system.
And the biggest part is, no one that thinks they want larger terrains has actually researched or even begun to design what the real issues are:
performance and indirectly networking.
Let's say you are able to get a perfectly working paged terrain block system in place using legacy terrain concepts (height maps). You've overcome the challenges of pushing so many terrain textures to the video card without destroying FPS, and you've handled all the corner cases of boundary transition.
How are you going to optimize the performance of your server and client when there are 50,000 objects required to populate this terrain, each getting a processTick() call at a 32 millisecond frequency?
How are you going to handle instancing standup and management of links across multiple servers in your back end?
How are you going to handle control object migration across these servers?
Larger/paged terrain is the least difficult challenge with "big worlds". If you can't implement it yourself, you won't even come close to solving the real challenges.
Sorry if I come across as rude/arrogant in this post, but it is a very common post that wants "larger/more terrain" in any game without thinking through what that really entails--enough for me to post about it.
#19
12/16/2006 (3:31 pm)
Populating terrain and other design decisions like that are kind of offtopic, don't you think? We could apply that to anything, Atlas included.
#20
And this isn't? Pointing to a worthless, not to mention unavailable resource as a solution to all their woes?
There isn't a single thing that this resource would do for anyone wanting a large world (bigger than default TGE) terrain that's worth anything at all. It solves almost no issues with the problem as a whole.
EDIT: Of course, no one mentioned the fact that the Gorpe module is single threaded in the main thread, meaning that every time you page in a new terrain, it will pause for 5-15 seconds without letting the player do anything as the next transitory terrain blocks are loaded in.
Atlas is of course multi-threaded.
I guess what I'm wondering is Stefan is can you give one reason why you would use outdated single threaded paged terrain hacks over a system design to solve the problem in a more robust and performant manner?
The only one I can think of it wanting to target older machine platforms--and in that case, massive worlds are the worst possible way to go in the first place...
12/16/2006 (4:01 pm)
Quote:
I would use that before the current Atlas anyday
And this isn't? Pointing to a worthless, not to mention unavailable resource as a solution to all their woes?
There isn't a single thing that this resource would do for anyone wanting a large world (bigger than default TGE) terrain that's worth anything at all. It solves almost no issues with the problem as a whole.
EDIT: Of course, no one mentioned the fact that the Gorpe module is single threaded in the main thread, meaning that every time you page in a new terrain, it will pause for 5-15 seconds without letting the player do anything as the next transitory terrain blocks are loaded in.
Atlas is of course multi-threaded.
I guess what I'm wondering is Stefan is can you give one reason why you would use outdated single threaded paged terrain hacks over a system design to solve the problem in a more robust and performant manner?
The only one I can think of it wanting to target older machine platforms--and in that case, massive worlds are the worst possible way to go in the first place...
Torque Owner Stephan - viKKing - Bondier