Torque 3D Development - GDC Live Edition
by Brett Seyler · 04/04/2009 (2:31 pm) · 333 comments
Wow...another GDC behind us. This was a big one. I dare say it was GG's biggest ever. Josh Williams and I gave a talk on Thursday titles "The Future of Web Games" which ended up being packed full with standing room only. There was a tremendous amount of interest in both InstantAction Technology and Torque 3D. That went off fabulously. We did some private demos for the big gun studios. The GG booth was jam packed for 3 days straight, and despite bringing a full staff of GG'ers to San Francisco to help, I think everyone was overloaded with excited questions and lots of "when can I get that!!??" The really exciting part for Torque 3D stuff (which was absurdely well recieved) is that we've still only shown probably 50% of what we're working on. Some of you saw Tom Spilman's uStream walkthough of the "South Pacific" demo. That's all been captured and posted for you relentless viewing and scrutinizing below =) Obviously a lot of people put hard work into Torque 3D, but we really owe a lot to Sickhead Games for helping us SHOW rather than tell all of what Torque 3D is capable of.
Tom's gone way above and beyond creating a new terrain implementation (as you'll see in the videos), physics, procedural object placement brushing tools (called "Forest Kit" after the original tech it's based on), and of course, the new Advanced Lighting. It's not just Tom though. Russell Fincher, a great artist, is responsible for making most of this look as good as it does. James did the River and Road tools and Ross worked a lot on bending the World Editor to make all this stuff easily accessible and easier to use. That's just the high points, but they really are a great crew. We're lucky to have their help.
So, in this blog, I'm just posting the Torque 3D relevant footage from GDC. You'll see two demos below, both pretty ground-breaking stuff. There's a lot more on the way. This shakey cam stuff is great, but the video is low resolution and I want to get some straight-from-the-machine captures out to really show how good this all looks and how easy it all is to use.
There truly is a lot more to come. There's a more in depth look at the World Editor, a focus on the Road and River tools, Gerhard's AI and GPU Cloth, Physics, new demos, genre kits, and more. We're also going to try to get a live demo embedded on the website so you can see this stuff for real. All that, and our first build for pre-order customers is just around the corner. Since we opened up the pre-order promotion last week, you guys almost broke our ecommerce system with the flood of purchases. Sorry to those of you who were turned away while we tried to patch things up last week. Hopefully everyone who wanted in got in. Shirts are on their way, and the Torque 3D private forums are alive with anticipation. I can't wait to see what you'll all do with this new technology. I have high hopes :)
I also know that there a lot of unanswered questions from the nearly 500 comments on the last blog. I'm going to re-read those thoroughly this week and try to answer them all. Thanks for you patience and thanks again to everyone whose kept the faith and stuck with us. It's great to know there's still such a huge community behind Torque.
More development blogs to come. This is post #16.
Torque 3D development blogs:
- Post #1 - Kickoff
- Post #2 - Apparatus and Warrior Camp
- Post #3 - Luma's racing kit
- Post #4 - Josh Engebretson and Web Publishing
- Post #5 - Pricing and Licensing
- Post #6 - Pricing and Licensing CONTINUED
- Post #7 - Wetness & Precipitation
- Post #8 - Screeen Space Ambient Occlusion (SSAO)
- Post #9 - Matt Langley and the Torque Launcher
- Post #10 - Chris Robertson and Collada
- Post #11 - Depth of Field
- Post #12 - Advanced Lighting
- Post #13 - Soft Particles
- Post #14 - World Editor
- Post #15 - Pricing and Licensing ANNOUNCED!
- Post #16 - GDC Live Edition
- Post #17 - River & Road Editors
- Post #18 - Beta is UP!
- Post #19 - Light Rays, Undercity, Material Editor
- Post #20 - Mass Market Hardware
- Post #21 - Beta: Part Deux
- Post #22 - Marching Towards Beta 3
- Post #23 - pureLIGHT
- Post #24 - Lighting, Terrain, and Cloth
- Post #25 - Beta 3!
- Post #26 - Coming Soon!
About the author
Since 2007, I've done my best to steer Torque's development and brand toward the best opportunities in games middleware.
#242
What kind of character animations will T3d support? per-vertex animation perhaps? Or not yet? I know it is not supported in tgea, so I was wondering what would be supported or at least default for T3D.
Thank you again.. and .. Are we there yet?
Peace,
Sarrene'
04/09/2009 (9:49 am)
I have another question.. What kind of character animations will T3d support? per-vertex animation perhaps? Or not yet? I know it is not supported in tgea, so I was wondering what would be supported or at least default for T3D.
Thank you again.. and .. Are we there yet?
Peace,
Sarrene'
#243
GarageGames is even willing to work with you to add your extensions to the core engine wrapped in appropriate #ifdef's that your module can enable.
04/09/2009 (11:12 am)
One thing to keep in mind is that the Project Generator makes it a lot easier for a kit developer to add source code to someone's project. No more nasty merge docs or full versions of the engine to diff against. Just drop the source code in the write subfolder, the module definitions into the Project Generator, update their project.conf file, and when they regenerate their projects it all automatically works (5-10 mins of effort as opposed to days worth previously).GarageGames is even willing to work with you to add your extensions to the core engine wrapped in appropriate #ifdef's that your module can enable.
#244
For iTorque there was a major effort to increase the speed of TorqueScript, reduce its memory consumption, and dramatically improve its heap management (the main bottleneck for any scripting language on the iPhone...including Unity's Mono implementation).
It is still not clear exactly when this will make it into Torque 3D. We have a lot of other things that are higher priority on the list to get done for the Betas.
There has been a little more effort put into abstracting and decoupling TorqueScript (for example, adding a new script parser and operation executer wouldn't be too difficult if you knew what you were doing). However, the console system is still largely rooted in the same code that you encountered in your previous efforts. At this point it isn't quite plug 'n play scripting. We have put some research into this and have plans to continue that research but it had to be sidelined for Torque 3D.
As I just mentioned, we've been looking at this off and on for the last year and a half but we don't have a firm timeline/roadmap at this point.
04/09/2009 (11:19 am)
Quote:
1) There was a mention that TorqueScript execution has been enhanced. Can some details be shared on this, like what has changed, and what kind of speedup percentage has been observed? Has memory consumption and/or heap management been improved?
For iTorque there was a major effort to increase the speed of TorqueScript, reduce its memory consumption, and dramatically improve its heap management (the main bottleneck for any scripting language on the iPhone...including Unity's Mono implementation).
It is still not clear exactly when this will make it into Torque 3D. We have a lot of other things that are higher priority on the list to get done for the Betas.
Quote:
2) During this work, was TorqueScript integration refactored so that it is:
a) less tightly coupled to the core engine (ie more modular)
b) refactored to more easily allow a different, pluggable script engine impl?
A few years back I did substantial research into TGEA code base to replace TorqueScript, and it didn't take long to determine that the way it was implemented, I'd be looking at a MAJOR engine change that I'd never be able to maintain over time with TGEA updates.
There has been a little more effort put into abstracting and decoupling TorqueScript (for example, adding a new script parser and operation executer wouldn't be too difficult if you knew what you were doing). However, the console system is still largely rooted in the same code that you encountered in your previous efforts. At this point it isn't quite plug 'n play scripting. We have put some research into this and have plans to continue that research but it had to be sidelined for Torque 3D.
Quote:
Is anything like this happening in T3D, and if not, is it on the roadmap? At a minimum, by the time the component model refactor is done, I think TorqueScript should just be a stock implemetation of the script engine component, and people should be able to write their own and replace it at runtime.
As I just mentioned, we've been looking at this off and on for the last year and a half but we don't have a firm timeline/roadmap at this point.
#245
There are no plans to do this at this point.
Other than a few tweaks with shaders here and ther, the particle system is still largely the same as it has been since TGEA 1.7. Sadly, we did not have the time to spend on this.
04/09/2009 (11:21 am)
Quote:
I wonder, will it include a Emitter Mesh (in particle system) ?
"Emit particles at any vertex, along any edge, or the surface of any polygon."
There are no plans to do this at this point.
Quote:
While at it, did we even see any particle systems in use yet (beside soft particles and a few explosions in the bad video's :P), particles is a big thing these days :) ?
Other than a few tweaks with shaders here and ther, the particle system is still largely the same as it has been since TGEA 1.7. Sadly, we did not have the time to spend on this.
#246
There have been a wide variety of games made with Torque over the years so, yes, I would say it is a general purpose game engine. I get the impression that what you are really getting at is, "Is it a blank slate game engine or do I still 'mod' examples to get what I want?". Without getting into a philosophical debate on why "modding existing examples" is a very powerful and useful design paradigm (in fact it is the one used by the majority of successful game studios out there), I would say that with every release of Torque we have pushed ourselves closer and closer to allowing that "blank slate" experience (allowing you to plug 'n play code modules with the Project Generator, more powerful script access to the core functionality, more functionality exposed directly to the editors).
Which version of TGEA? =) There are some pretty dramatic differences between TGEA 1.0.3 (which sounds like the version you may have used) and TGEA 1.7.x as well as some dramatic differences between TGEA 1.7.x and TGEA 1.8.x.
In general, the biggest differences between Torque 3D and the latest version of TGEA boil down to:
- Vastly improved Terrain system
- Completely new and far more powerful fully dynamic lighting system
- Far more robust and productive editors
- Much easier and more flexible art pipeline (Collada, Live Asset Updating, Polysoup collision)
- Abstracted and pluggable physics system with PhysX support out of the box
- Web deployment option
- Higher quality example artwork
- I heard that collada is supported, that's fine, but what about animated characters imported into Torque 3D with collada?
I don't really care if the engine comes with or without Forest kit.[/quote]
I mentioned before that you can do animated characters with Collada but you may face a few challenges (like not being able to mask out certain nodes). It is totally doable, however (I've done it and I'm not an artist).
Characters are a tricky thing for any game engine since they tend to require a more rigid hierarchy, special nodes, and in general a more thorough understanding of how they interact with the engine whereas static geometry just kinda has to sit there and look pretty. Have you ever tried to build a character for Half-Life? It makes Torque's art pipeline look trivial =P
Torque 3D does still have the ShapeBase inheritance-driven schema of "game classes" behind it. There has been continual refinement and polish to this over the last several years and it is easier to work with.
04/09/2009 (11:44 am)
Quote:
- Is Torque 3D a general purpose game engine? Or is just a game with source code and tools? Sorry if am asking this, i tried TGEA in the past and i had very bad experiences from it.
There have been a wide variety of games made with Torque over the years so, yes, I would say it is a general purpose game engine. I get the impression that what you are really getting at is, "Is it a blank slate game engine or do I still 'mod' examples to get what I want?". Without getting into a philosophical debate on why "modding existing examples" is a very powerful and useful design paradigm (in fact it is the one used by the majority of successful game studios out there), I would say that with every release of Torque we have pushed ourselves closer and closer to allowing that "blank slate" experience (allowing you to plug 'n play code modules with the Project Generator, more powerful script access to the core functionality, more functionality exposed directly to the editors).
Quote:
- How different Torque 3D is from TGEA?
Which version of TGEA? =) There are some pretty dramatic differences between TGEA 1.0.3 (which sounds like the version you may have used) and TGEA 1.7.x as well as some dramatic differences between TGEA 1.7.x and TGEA 1.8.x.
In general, the biggest differences between Torque 3D and the latest version of TGEA boil down to:
- Vastly improved Terrain system
- Completely new and far more powerful fully dynamic lighting system
- Far more robust and productive editors
- Much easier and more flexible art pipeline (Collada, Live Asset Updating, Polysoup collision)
- Abstracted and pluggable physics system with PhysX support out of the box
- Web deployment option
- Higher quality example artwork
Quote:
- What about the asset integration. How easily can animated characters be integrated into the engine? Is there any limits on rig hierarchy? Bones limits? Mesh limits?
- I heard that collada is supported, that's fine, but what about animated characters imported into Torque 3D with collada?
I don't really care if the engine comes with or without Forest kit.[/quote]
I mentioned before that you can do animated characters with Collada but you may face a few challenges (like not being able to mask out certain nodes). It is totally doable, however (I've done it and I'm not an artist).
Characters are a tricky thing for any game engine since they tend to require a more rigid hierarchy, special nodes, and in general a more thorough understanding of how they interact with the engine whereas static geometry just kinda has to sit there and look pretty. Have you ever tried to build a character for Half-Life? It makes Torque's art pipeline look trivial =P
Quote:
We are looking for a cleaner and decent code to add our own "Game classes and functionality".
Torque 3D does still have the ShapeBase inheritance-driven schema of "game classes" behind it. There has been continual refinement and polish to this over the last several years and it is easier to work with.
#247
No. It isn't that hard to put together a basic dialog system purely in TorqueScript however. As an experienced developer, I could probably whip something up in an afternoon or two.
No, melee is something we have decided to wait on until we have the time to do it properly (probably in the context of an RPG Genre Kit).
This is high on the priority list for getting into Torque 3D since we feel that the camera system is one of those areas that force people to have to code C++ and it really shouldn't. I don't know that we will get everything you are asking for but we will make a good effort and this is something we will probably continue to expand after release.
You just described a lot of the core features of the "Forest Kit" which will be sold separately from Torque 3D.
The GroundCover system that will ship with stock Torque 3D is essentially an optimized foliage replicator (it can also do shapes). It will even be tied to the Terrain Materials you are painting (paint a grass texture and get grass foliage).
Not sure what you mean by "alphaLOD"?
Yes, this is the Live Asset Updating you've seen us refer to. Hit save in Photoshop and watch the texture instantly change in your game. The artists working with Torque 3D love it! Scripts are a little trickier since there can be a lot of odd dependencies between scripts that don't necessarily play nice getting "half" executed.
The Terrain now uses Materials with support for diffuse textures (duh), detail textures (per Material), normal maps, and side projection. We will likely be able to push this even further into some cool ways. We are not planning to add direct support for "accumulation shaders" in the near future.
We haven't touched the Projectile system beyond minor bug fixes.
Unfortunately, the Particle Editor is probably going to be the last editor we will attempt to get to for Torque 3D and, given the amount of other stuff that we are working on, I would be surprised to see it happen. We have added some pretty interesting back-end tech to greatly simplify saving objects to script files non-destructively (without harming/overwriting anything else in the script file) so it will become a lot easier to do this. We are also planning to add a basic Datablock Editor that will allow you to edit the Particle datablocks. It just won't have a customized "view" of those properties.
Mich is hard at work on writing better documents for Torque 3D. It is funny that you mention F1 since TGE had documentation built right into the app/editor that was accessible by hitting F1 but I could count on my hands the number of people who knew that without me directly telling them =P
04/09/2009 (12:04 pm)
Quote:
Will there be a dialog system?
No. It isn't that hard to put together a basic dialog system purely in TorqueScript however. As an experienced developer, I could probably whip something up in an afternoon or two.
Quote:
A melee system with the expandability like Josh Moore's resource?
No, melee is something we have decided to wait on until we have the time to do it properly (probably in the context of an RPG Genre Kit).
Quote:
A camera system for different effects...fp, 3rd, orbit, Godview, plus controlable lagging?
This is high on the priority list for getting into Torque 3D since we feel that the camera system is one of those areas that force people to have to code C++ and it really shouldn't. I don't know that we will get everything you are asking for but we will make a good effort and this is something we will probably continue to expand after release.
Quote:
Optimized shape replicator with alphaLOD, twSurfaceReference, Clustering, mulitple models, already built in?
You just described a lot of the core features of the "Forest Kit" which will be sold separately from Torque 3D.
Quote:
Optimized foliage replicator with twSurfaceReference, clustering and multiple objects?
The GroundCover system that will ship with stock Torque 3D is essentially an optimized foliage replicator (it can also do shapes). It will even be tied to the Terrain Materials you are painting (paint a grass texture and get grass foliage).
Quote:
Are DTS objects/and DIF for that matter, going to have anything like alphaLOD?
Not sure what you mean by "alphaLOD"?
Quote:
Dynamic Script, texture and object loading. (So you don't have to reload your game each time)
Yes, this is the Live Asset Updating you've seen us refer to. Hit save in Photoshop and watch the texture instantly change in your game. The artists working with Torque 3D love it! Scripts are a little trickier since there can be a lot of odd dependencies between scripts that don't necessarily play nice getting "half" executed.
Quote:
Terrain shaders? Accumulation shaders for all objects...dif, dts, terrain?
The Terrain now uses Materials with support for diffuse textures (duh), detail textures (per Material), normal maps, and side projection. We will likely be able to push this even further into some cool ways. We are not planning to add direct support for "accumulation shaders" in the near future.
Quote:
Upgraded Projectile system (bouncing off different typemasks, lasers, timed projectiles, sticky projectiles)
We haven't touched the Projectile system beyond minor bug fixes.
Quote:
A partile editor that can actually save the partiles you create to a .cs?
Unfortunately, the Particle Editor is probably going to be the last editor we will attempt to get to for Torque 3D and, given the amount of other stuff that we are working on, I would be surprised to see it happen. We have added some pretty interesting back-end tech to greatly simplify saving objects to script files non-destructively (without harming/overwriting anything else in the script file) so it will become a lot easier to do this. We are also planning to add a basic Datablock Editor that will allow you to edit the Particle datablocks. It just won't have a customized "view" of those properties.
Quote:
And the kicker....organized documentation
An organized dictionary..."Torqtionary"...would be great. Basically a Help file with the %randomObject/scriptObject/datablock/feature.dump(); setup in an easy-to-use, alphabitical or search index. With an example that you can easily slap in a cs file and exec it in a mission. It would explain all the fields, tagged fields and functions like your dump does, but also give some context to the item in question. You use this here, for this purpose. See Also... Like old school Qbasic help!!! F1!
Mich is hard at work on writing better documents for Torque 3D. It is funny that you mention F1 since TGE had documentation built right into the app/editor that was accessible by hitting F1 but I could count on my hands the number of people who knew that without me directly telling them =P
#248
Though particle system answers wasnt what i hoped for, im guessing i could problably write my own class at a time (well, let me rephrase that to i'll NEED to write..) :P
I wonder why (beside maybe comming as a kit later) you didnt choose to spend much time on particle systems, Mesh Emitter, Vortex emitter, particle editor, as its usually a part of most new (2008+'ish) engines.
Anyways, we will have the source, so no biggie :P
04/09/2009 (1:54 pm)
Thanks for answers Matt :)Though particle system answers wasnt what i hoped for, im guessing i could problably write my own class at a time (well, let me rephrase that to i'll NEED to write..) :P
I wonder why (beside maybe comming as a kit later) you didnt choose to spend much time on particle systems, Mesh Emitter, Vortex emitter, particle editor, as its usually a part of most new (2008+'ish) engines.
Anyways, we will have the source, so no biggie :P
#249
It pretty much came down to limited time/resources. We felt like the Lighitng, Terrain, Collada, and Editors were all higher priority for the Torque community in general. We know it is an area that needs some serious love but we have to pick our battles =)
04/09/2009 (2:01 pm)
Quote:
I wonder why (beside maybe comming as a kit later) you didnt choose to spend much time on particle systems, Mesh Emitter, Vortex emitter, particle editor, as its usually a part of most new (2008+'ish) engines.
It pretty much came down to limited time/resources. We felt like the Lighitng, Terrain, Collada, and Editors were all higher priority for the Torque community in general. We know it is an area that needs some serious love but we have to pick our battles =)
#250
04/10/2009 (2:36 am)
Quote:TGE had documentation built right into the app/editor that was accessible by hitting F1 but I could count on my hands the number of people who knew that without me directly telling them =PI knew ;) but you have to admit it was rather basic infomation. Any chance of reviving/updating/removing that? Especially since it, the "About" window, and the "Credits" still contains references to a RealmWars (rw) directory -- yeah I know, technically not important but every little bit helps the sheen of that polish doesn't it?
#251
04/10/2009 (7:54 am)
How large can terrains be in Torque 3D? I know you can't give precise figures at this stage, but could you at least say if the limit is likely to be tens of square kilometres or hundreds of thousands?
#252
It really depends on how detailed you want your terrain to be.
The only real limitation to the terrain system now is how big your heightfield and id map are (they currently must match in size). They are both single textures so you are limited by the maximum texture size of your target minimum spec video card. In general 1024x1024 is a reasonable upper limit for older video cards and 2048x2048 is a reasonable upper limit for newer video cards. You believe you can lay hands on video cards that top out at 8192x8192 but that is probably only going to perform well with the extremely high end computers (perhaps in the simulation space where you can set strict hardware requirements).
That hardware-driven texture size limitation only controls how many points define your heightfield and id map. You can then scale the distance between those samples to whatever value you desire.
For example, the old TerrainBlock system had a max heightfield size of 256x256 with a default distance of 8m between samples (the old "stepSize" variable). This effectively gave you a terrain that was 2km x 2km (256 x 8). You could increase or decrease the "stepSize" (by powers of 2) but with the old system that sometimes caused unexpected issues.
The 8m spacing of the original terrain looked good enough but it was a fairly low texel density when compared to modern games.
With TGEA 1.7 we introduced the "MegaTerrain" object which stitched 4 TerrainBlocks together and helped smooth out the transitions between them. With the default 8m spacing this increased the terrain size to 4km x 4km. This worked but it was a bit of a hack and it used a lot more video memory than was ideal.
With the new terrain system you could have a 2048x2048 heightfield/id map with an 8m sample spacing and end up with a 16km x 16km terrain (256 square km) which will render faster than the old 256x8 TerrainBlock's. Or you could have a 2048x2048 heightfield/id map with a 1m spacing and get the original terrain's 2km x 2km but have far higher texel density (super detailed texturing) and much finer control control over the shape of the terrain (no more struggling to get that one piece of that slope to match up).
If you have the hardware you could theoretically use a 8192x8192 heightfield/id map with 16m spacing and get a massive 131km x 131km (17,179 square km) which looks decent and renders fast. I say "theoretically" because we haven't attempted it yet so your actual mileage may vary =)
The cool thing about the new terrain rendering technology is that it will grow with the hardware as it gets faster and more capable!
04/10/2009 (12:36 pm)
Quote:
How large can terrains be in Torque 3D?
It really depends on how detailed you want your terrain to be.
The only real limitation to the terrain system now is how big your heightfield and id map are (they currently must match in size). They are both single textures so you are limited by the maximum texture size of your target minimum spec video card. In general 1024x1024 is a reasonable upper limit for older video cards and 2048x2048 is a reasonable upper limit for newer video cards. You believe you can lay hands on video cards that top out at 8192x8192 but that is probably only going to perform well with the extremely high end computers (perhaps in the simulation space where you can set strict hardware requirements).
That hardware-driven texture size limitation only controls how many points define your heightfield and id map. You can then scale the distance between those samples to whatever value you desire.
For example, the old TerrainBlock system had a max heightfield size of 256x256 with a default distance of 8m between samples (the old "stepSize" variable). This effectively gave you a terrain that was 2km x 2km (256 x 8). You could increase or decrease the "stepSize" (by powers of 2) but with the old system that sometimes caused unexpected issues.
The 8m spacing of the original terrain looked good enough but it was a fairly low texel density when compared to modern games.
With TGEA 1.7 we introduced the "MegaTerrain" object which stitched 4 TerrainBlocks together and helped smooth out the transitions between them. With the default 8m spacing this increased the terrain size to 4km x 4km. This worked but it was a bit of a hack and it used a lot more video memory than was ideal.
With the new terrain system you could have a 2048x2048 heightfield/id map with an 8m sample spacing and end up with a 16km x 16km terrain (256 square km) which will render faster than the old 256x8 TerrainBlock's. Or you could have a 2048x2048 heightfield/id map with a 1m spacing and get the original terrain's 2km x 2km but have far higher texel density (super detailed texturing) and much finer control control over the shape of the terrain (no more struggling to get that one piece of that slope to match up).
If you have the hardware you could theoretically use a 8192x8192 heightfield/id map with 16m spacing and get a massive 131km x 131km (17,179 square km) which looks decent and renders fast. I say "theoretically" because we haven't attempted it yet so your actual mileage may vary =)
The cool thing about the new terrain rendering technology is that it will grow with the hardware as it gets faster and more capable!
#253
I have a question about this terrain "limit", all though high as it is, can you (even if you have to program it your self), create "infinite" terrain like eg. in Unity3D, where you can add "Terrain" blocks over and over, each having its own heightmap, detail map ect ect.
That way you could add smaller, but higher quality map blocks, while still be able to create uber large terrains.
In our project, we wish to create huge, MAD huge, high quality terrains while keeping "loading" screens to a minimum.
Is it possible to do (program our self or not) like, does the asset loading system allow for it.
04/10/2009 (1:42 pm)
@MattI have a question about this terrain "limit", all though high as it is, can you (even if you have to program it your self), create "infinite" terrain like eg. in Unity3D, where you can add "Terrain" blocks over and over, each having its own heightmap, detail map ect ect.
That way you could add smaller, but higher quality map blocks, while still be able to create uber large terrains.
In our project, we wish to create huge, MAD huge, high quality terrains while keeping "loading" screens to a minimum.
Is it possible to do (program our self or not) like, does the asset loading system allow for it.
#254
04/10/2009 (2:16 pm)
@Bo: I've never seen a terrain done the way you're describing with Unity, or any engine (Crytek, Hero for example) that has realtime editing tools. Unless there are serious hits to the texel density, I'm pretty skeptical that this works. Have you seen any examples of this?
#255
04/10/2009 (2:28 pm)
@Bo: much like TGEa, Torque 3D looks like it still retains the ability to place an arbitrary number of terrain blocks in your mission, but lining them up & matching the seams is up to you -- a tedious job at best. You will also be limited by your hardware on how many you can place and/or use.
#256
TV3D has a kind of sample on this, they call it "Paging" Terrain, but that one loads blocks as you move in that direction and unload blocks you moved away from (opposite direction).
http://tv3dsamples.blogspot.com/2008/07/landscape-paging.html (a sample C#)
However, in Unity3D you can define wich blocks belong to wich, so that way it would seem like they where "one" in regards to LOD distance and such.
http://forum.unity3d.com/viewtopic.php?t=20800 (some discussions on unity3d seemless terrain)
@Micheal
If you use external application like Grome to generate your heightmaps, the seems has already been taken care off.
You "could" if a "neighbor()" was present, stich the 2 matching line points together and 1 point change other "nightbor" point follows, that way you could paint/edit over seems.
And there would be no limit, as it loads/unloads maps thats not "seen", that way no more then certain amount of map blocks is loaded in any given time and would give the illusion of unlimited terrain.
04/10/2009 (2:39 pm)
@BrettTV3D has a kind of sample on this, they call it "Paging" Terrain, but that one loads blocks as you move in that direction and unload blocks you moved away from (opposite direction).
http://tv3dsamples.blogspot.com/2008/07/landscape-paging.html (a sample C#)
However, in Unity3D you can define wich blocks belong to wich, so that way it would seem like they where "one" in regards to LOD distance and such.
http://forum.unity3d.com/viewtopic.php?t=20800 (some discussions on unity3d seemless terrain)
@Micheal
If you use external application like Grome to generate your heightmaps, the seems has already been taken care off.
You "could" if a "neighbor()" was present, stich the 2 matching line points together and 1 point change other "nightbor" point follows, that way you could paint/edit over seems.
And there would be no limit, as it loads/unloads maps thats not "seen", that way no more then certain amount of map blocks is loaded in any given time and would give the illusion of unlimited terrain.
#257
We don't plan to support paging the terrain in as you move about the level for Torque 3D. Atlas taught us that this is very tricky to get right and performant so we decided to take a step back and focus on making sure that the underlying terrain was both powerful and flexible enough to support future extensions.
04/10/2009 (2:48 pm)
Currently, the TerrainBlock's have no concept of neighbors. It is completely up to you to keep the edges matched up.We don't plan to support paging the terrain in as you move about the level for Torque 3D. Atlas taught us that this is very tricky to get right and performant so we decided to take a step back and focus on making sure that the underlying terrain was both powerful and flexible enough to support future extensions.
#258
Okay ;), it was just a question, because our game design plans will have camera ala diablo, isometric/ortho like, and that what we wantet to have uber high detail maps, since so little is on screen at a time.
But, if we have to lower terrain size to get uber details, it wont work because we will need INCREDIBLE big terrains without loading screens.
Guess we will have to see about implementing it our self, because having it is not really a option for us.
Asking gives us time for what we have to prepare/do ect when this thing finally gets released (beta) :)
04/10/2009 (3:01 pm)
@MattOkay ;), it was just a question, because our game design plans will have camera ala diablo, isometric/ortho like, and that what we wantet to have uber high detail maps, since so little is on screen at a time.
But, if we have to lower terrain size to get uber details, it wont work because we will need INCREDIBLE big terrains without loading screens.
Guess we will have to see about implementing it our self, because having it is not really a option for us.
Asking gives us time for what we have to prepare/do ect when this thing finally gets released (beta) :)
#259
* These are on an old TerrainBlock with 8m sample density.
04/10/2009 (3:24 pm)
Do keep in mind that you also get a separate high resolution detail map per terrain material. This can lead to some amazingly high texel densities around the camera (perfect for an isometric game).* These are on an old TerrainBlock with 8m sample density.
Torque 3D Owner Tim Dix (Raverix)