Atlas Blender Question - Let Your Voice Be Heard
by Kyle Carter · in Torque Game Engine Advanced · 08/12/2006 (1:48 am) · 15 replies
Hey guys,
So I'm working on the new blended terrain, and seeing a long optimization cycle ahead of me. For reference, the new texturing architecture involves doing piecewise updates of textures on GPU from the CPU, as the camera moves around. This lets you have precise control over how much memory is used, requires no dynamic allocations, etc, and is generally fantastic.
HOWEVER.
For those of you who need blended terrain in Atlas, does it matter if it's blended on-the-fly from a small source file at runtime, or if blended texture data is cached, like mission lighting, at mission load?
Both approaches will require the same amount of data to be downloaded and give comparable image quality. The second cached appraoch is very light on CPU cost at runtime (<10% frametime to render terrain), the first on-the-fly approach can get fairly heavy in terms of cost on lower end CPUs (although aggressive optimization can help).
So, what I want to do is find out if completely on-the-fly blending is even needed by the users of TSE before I spend more time and effort optimizing - if not then I won't bother and can move on to other goodies. :) It also means I can make the blending algorithm easier to understand and extend and more visually pleasing.
"Blending" in this instance refers to TGE-style combination of multiple source materials and a lightmap into a single texture which is applied to the terrain.
So I'm working on the new blended terrain, and seeing a long optimization cycle ahead of me. For reference, the new texturing architecture involves doing piecewise updates of textures on GPU from the CPU, as the camera moves around. This lets you have precise control over how much memory is used, requires no dynamic allocations, etc, and is generally fantastic.
HOWEVER.
For those of you who need blended terrain in Atlas, does it matter if it's blended on-the-fly from a small source file at runtime, or if blended texture data is cached, like mission lighting, at mission load?
Both approaches will require the same amount of data to be downloaded and give comparable image quality. The second cached appraoch is very light on CPU cost at runtime (<10% frametime to render terrain), the first on-the-fly approach can get fairly heavy in terms of cost on lower end CPUs (although aggressive optimization can help).
So, what I want to do is find out if completely on-the-fly blending is even needed by the users of TSE before I spend more time and effort optimizing - if not then I won't bother and can move on to other goodies. :) It also means I can make the blending algorithm easier to understand and extend and more visually pleasing.
"Blending" in this instance refers to TGE-style combination of multiple source materials and a lightmap into a single texture which is applied to the terrain.
#2
For instance, the mission lighting stage for MoM levels can take 1-3 minutes. So, we actually ship 11 megs of lighting files. Also, our level load times were taking 45+ seconds... I recently cut this in half by removing datablock tranmission and executing the datablock scripts on the server and client...
What kind of additional load time and data size are we talking about on a load time cached system?
08/12/2006 (4:19 am)
TGE has significant load time issues with large amounts of level data. This includes the loading of datablocks through a small network pipe, loading of game objects, and the mission lighting phase. I'd be careful about adding any more phases or increasing load times.For instance, the mission lighting stage for MoM levels can take 1-3 minutes. So, we actually ship 11 megs of lighting files. Also, our level load times were taking 45+ seconds... I recently cut this in half by removing datablock tranmission and executing the datablock scripts on the server and client...
What kind of additional load time and data size are we talking about on a load time cached system?
#3
With the cached approach, would this limit the editors usefullness?
Will we still be able to edit the terrain textures in realtime?
Caching sounds nice in that it reduces load during runtime at the cost of some mission-load time, but if it does impact the abilities to edit the terrain texturing in realtime negatively, then I'm all for real-time data stream.
08/12/2006 (4:34 am)
A question Ben! How will this affect the texturing blender editor tool?With the cached approach, would this limit the editors usefullness?
Will we still be able to edit the terrain textures in realtime?
Caching sounds nice in that it reduces load during runtime at the cost of some mission-load time, but if it does impact the abilities to edit the terrain texturing in realtime negatively, then I'm all for real-time data stream.
#4
08/12/2006 (7:56 am)
For me, caching the blended textures would be fine. Of course, we would need to be able to clear the cache, or remove individual textures, so they could be rebuilt as needed (for editing, etc) Question: Were you also looking at splatting textures for the terrain?
#5
08/12/2006 (8:11 am)
Hey Benner. I have the same question as Stefan. How would the editors fit into all of this? I really don't care how the tech behaves behind the closed doors of your magic code castle, I just want to know what it will be like to work with the tools as an artist.
#6
I'll try to answer questions from top to bottom; if I miss something, just bring it up again as I probably missed it when reading through!
@Martin: not really - it's still just updating a cached chunk of terrain in memory and as such isn't re-rendering all of the data every frame, which is what would be needed for proper dynamic terrain effects. Of course there's nothing stopping you from adding e.g. a specular pass on top of the terrain if you wanted it.
For reference my current blender code is taking 50% or more of CPU when I start moving around 300m/sec. Just walking is OK (15%) but if you start going faster than that it starts to hurt.
If I do some extra work and port it to MMX or SSE I might be able to get 2-4x improvement, maybe as good as 10x, but that would be a fair amount of extra work for me, obfuscate the code, and make it hard to extend or modify. Also I've not got any real SIMD experience so it would take extra time for me to get done!
@Josh: You could always ship the data with your levels in which case it'd be a bit of extra disk (probably around 100mb/terrain if you go for a 32k unique texture over your terrain and are willing to have some compression artifacts), and in this case load time would not be appreciably higher.
If you didn't ship with the data then the load time could be a minute or two first time around. You could generate the data as part of the install process, though, which I think would be preferable for games with higher media requirements like yours.
@Stefan: The editors would work the same and realtime editing wouldn't be a problem. You'd occasionally want to delete and regenereate the terrain texture cache as it would slowly grow from editing. This is the same as how a unique texture dataset would work in Atlas.
@Jaimi: Splatting is another option, but I've not seen any super-great looking implementations of it and it's hard on fill rate so I've not pursued it closely. Got any killer screenshots to sell me on it? ;)
@Adam: How did you know to give the exact answer I was sort of hoping I'd get? (Seriously!) Tools will be the same in either case.
@Everyone: Guys, thanks for the input on this. I'd welcome any further input. Or just comments on my reply! I really want to make sure that Atlas is usable for everyone, so please make your voice heard! :)
08/12/2006 (2:31 pm)
Hey guys,I'll try to answer questions from top to bottom; if I miss something, just bring it up again as I probably missed it when reading through!
@Martin: not really - it's still just updating a cached chunk of terrain in memory and as such isn't re-rendering all of the data every frame, which is what would be needed for proper dynamic terrain effects. Of course there's nothing stopping you from adding e.g. a specular pass on top of the terrain if you wanted it.
For reference my current blender code is taking 50% or more of CPU when I start moving around 300m/sec. Just walking is OK (15%) but if you start going faster than that it starts to hurt.
If I do some extra work and port it to MMX or SSE I might be able to get 2-4x improvement, maybe as good as 10x, but that would be a fair amount of extra work for me, obfuscate the code, and make it hard to extend or modify. Also I've not got any real SIMD experience so it would take extra time for me to get done!
@Josh: You could always ship the data with your levels in which case it'd be a bit of extra disk (probably around 100mb/terrain if you go for a 32k unique texture over your terrain and are willing to have some compression artifacts), and in this case load time would not be appreciably higher.
If you didn't ship with the data then the load time could be a minute or two first time around. You could generate the data as part of the install process, though, which I think would be preferable for games with higher media requirements like yours.
@Stefan: The editors would work the same and realtime editing wouldn't be a problem. You'd occasionally want to delete and regenereate the terrain texture cache as it would slowly grow from editing. This is the same as how a unique texture dataset would work in Atlas.
@Jaimi: Splatting is another option, but I've not seen any super-great looking implementations of it and it's hard on fill rate so I've not pursued it closely. Got any killer screenshots to sell me on it? ;)
@Adam: How did you know to give the exact answer I was sort of hoping I'd get? (Seriously!) Tools will be the same in either case.
@Everyone: Guys, thanks for the input on this. I'd welcome any further input. Or just comments on my reply! I really want to make sure that Atlas is usable for everyone, so please make your voice heard! :)
#7
You're right - instead of porting over to MMX/SSE and spending there tons of time, it might be more useful to spend your time on other (cool!) things in the engine. :-)
08/12/2006 (2:51 pm)
Thanks Ben for the explanation. In that case I'd prefer the cached version. Eating so much CPU time could hurt really soon if you're going to make a flying game just like me :-)You're right - instead of porting over to MMX/SSE and spending there tons of time, it might be more useful to spend your time on other (cool!) things in the engine. :-)
#8
So, my vote goes towards the cached approach.
-Jase
08/12/2006 (4:24 pm)
I'm in favor of saving on the CPU load. Less CPU time used for the terrain means more CPU for everything else. Plus, you did mention "more visually pleasing", and "easier to understand and extend". I'm all for that. So, my vote goes towards the cached approach.
-Jase
#9
But I'm not sure yet - this is just the "is it even feasible" test - so we'll see what happens.
Either way, I'll be resolving this part of the implementation soon, and keeping your guy's preferences in mind - and even if I do have an efficient on-the-fly blender, I'll see about writing a tool to bake everything out to a unique texture for later touch-up (and of course the unique should always be at least a little faster than the blended).
Thanks for working with me on this stuff, guys! :)
08/12/2006 (4:30 pm)
Gotcha - one more twist in this discussion is I just did some benchmarks on yet another approach for doing blending at runtime, using the GPU, and it seems like it might meet the performance needs and be easy to implement... so we might be just fine with on-the-fly blending, and it'd be pretty easy to extend.But I'm not sure yet - this is just the "is it even feasible" test - so we'll see what happens.
Either way, I'll be resolving this part of the implementation soon, and keeping your guy's preferences in mind - and even if I do have an efficient on-the-fly blender, I'll see about writing a tool to bake everything out to a unique texture for later touch-up (and of course the unique should always be at least a little faster than the blended).
Thanks for working with me on this stuff, guys! :)
#10
Seems like its all "swings and roundabouts" to me ! lol
Basically I'm with Jase on this, although if the GPU can do it on the fly
without impacting too heavily on GPU processing (ie not cause the GPU to
become over burdened in more complex scenes) then that does indeed
sound a good way forward.
Thanks for letting us have our say within this development :)
Hewster
08/12/2006 (11:18 pm)
Hi Ben,Seems like its all "swings and roundabouts" to me ! lol
Basically I'm with Jase on this, although if the GPU can do it on the fly
without impacting too heavily on GPU processing (ie not cause the GPU to
become over burdened in more complex scenes) then that does indeed
sound a good way forward.
Thanks for letting us have our say within this development :)
Hewster
#11
I'm perfectly happy to have a "generation" phase of the install. Which would tie in more procedural stuff than just the terrain blending.
At the end of the day, download size is important, runtime footprint is important, but perhaps most important is the ease-of-use and ease-of-editing. Without being able to iterate and refine the world quickly, then we dont have a product to worry about right?
08/13/2006 (3:04 am)
I think using a GPU blended approach would be wise, given the move forward into DX10 territory is likely to throw us a bone in those areas.I'm perfectly happy to have a "generation" phase of the install. Which would tie in more procedural stuff than just the terrain blending.
At the end of the day, download size is important, runtime footprint is important, but perhaps most important is the ease-of-use and ease-of-editing. Without being able to iterate and refine the world quickly, then we dont have a product to worry about right?
#12
How much time are we talking about to actually generate these files?
08/13/2006 (3:27 am)
Naturally, I'm with Jase - but if these suckers are going to occupy 100 megabytes each or even more.. Yikes! :) That's alot of space.How much time are we talking about to actually generate these files?
#13
Here's a question for everyone. Do you think it would be more efficient for large terrains (and I mean really large) do go to a Blender texture approach and implement unique features (like paths and such) as DTS?
08/21/2006 (10:20 am)
The lower disk space profile would be nice, for sure. This doesn't really affect my project right now as we had discounted Blender terrain since we need unique terrain features. We could go to Blender terrain, however, if we implemented the unique terrain features as DTS files.Here's a question for everyone. Do you think it would be more efficient for large terrains (and I mean really large) do go to a Blender texture approach and implement unique features (like paths and such) as DTS?
#14
08/21/2006 (11:10 am)
You'll have some nasty LOD issues seperating stuff like that. If you can spare the disk space, unique is generally preferable as it's faster to upload & simpler to modify (at least in theory - once tools are in place i really will be. :)
#15
08/21/2006 (12:28 pm)
That's what I thought, thanks Ben. Looks like this discussion doesn't really apply for me. 
Torque Owner Martin Schultz
Regarding the lower-end CPU's: As far as I understand TSE, it is not so much for lower-end machines, just middle- and high-end machines. TGE is something for me that I expect to run on lower-end machines, but I wouldn't give this attribute to TSE. Especially when a lot of lower-end machines don't have the graphic cards to run TSE sufficiently.
Just my 2 Euro cents :-)