T3D 1.1 Final Wish Item - Texture Preload
by Dusty Monk · in Torque 3D Professional · 03/30/2011 (6:49 am) · 17 replies
I know it's probably way too late for this, but I thought I'd throw it out there anyway. We would *love* a way to force load, at mission start-up, all of the textures in the scene that can fit into texture memory.
I know some people have worked out some work-arounds for this: things like placing an object in the scene that has every material in the zone defined to it, letting the renderer render it while behind a blocking UI screen, or doing a slow 360 degree camera pan while behind a UI screen. In the end, we may have to do something like this as well. But right now, that huge hitch at the beginning of the scene as the renderer loads our view for the first time is really the *only* performance issue remaining for us, render-wise.
So we would love to have an API call into the engine - from script or code either one, that says "scan the material list for the zone and stuff textures into memory until you run out of space", or something along tose lines, that we could call while the loading screen was still up.
Again, probably too late, I know you guys are in final bug-test mode, but hey never hurts to ask.. :)
Dusty
I know some people have worked out some work-arounds for this: things like placing an object in the scene that has every material in the zone defined to it, letting the renderer render it while behind a blocking UI screen, or doing a slow 360 degree camera pan while behind a UI screen. In the end, we may have to do something like this as well. But right now, that huge hitch at the beginning of the scene as the renderer loads our view for the first time is really the *only* performance issue remaining for us, render-wise.
So we would love to have an API call into the engine - from script or code either one, that says "scan the material list for the zone and stuff textures into memory until you run out of space", or something along tose lines, that we could call while the loading screen was still up.
Again, probably too late, I know you guys are in final bug-test mode, but hey never hurts to ask.. :)
Dusty
About the author
Dusty Monk is founder and president of Windstorm Studios, an independant game studio. Formerly a sr. programmer at Ensemble Studios, Dusty has worked on AAA titles such as Age of Empires II & III, and Halo Wars.
#2
However, in my investigation I think the fault lies more with Direct3D than with T3D: T3D does load the materials and textures into D3D when the level is loaded: it doesn't "wait until they are first rendered" to do so. It's D3D9 that seems to only loads the textures into VRAM when they are bound for the first time.
I think that, short of there being texture creation flags I don't know of, the only way to force pre-loading would be making the hidden texture pre-display hack official: go through all textures in all loaded materials and draw them to quads outside the screen (this should work because my hack was to skip culling objects the first time they are found by the scenegraph).
03/30/2011 (7:52 am)
Yeah, I had to do hacks on this as well. It was quite distracting to have the game stutter at each new character that first rendered on screen.However, in my investigation I think the fault lies more with Direct3D than with T3D: T3D does load the materials and textures into D3D when the level is loaded: it doesn't "wait until they are first rendered" to do so. It's D3D9 that seems to only loads the textures into VRAM when they are bound for the first time.
I think that, short of there being texture creation flags I don't know of, the only way to force pre-loading would be making the hidden texture pre-display hack official: go through all textures in all loaded materials and draw them to quads outside the screen (this should work because my hack was to skip culling objects the first time they are found by the scenegraph).
#3
I wasn't aware it was D3D that was waiting on the texture binding before loading it into vram, but I can't say I'm surprised. And yeah, making the forced rendering hack an official function in the engine is exactly what I think would be good. I know I'd feel much more comfortable about using such a function if it was written by the guys that wrote the rendering code, rather than whatever I hack in with my limited understanding of the pipeline..
Dusty
03/30/2011 (8:07 am)
Yeah Manoel I recall seeing somewhere in a different thread that you had done something similar. I don't suppose you'd be able to post up the code change you made to do that, or if that's not possible (I certainly understand) maybe at least pointing out where in the rendering code that culling takes place? I could probably muddle it out from there.. I wasn't aware it was D3D that was waiting on the texture binding before loading it into vram, but I can't say I'm surprised. And yeah, making the forced rendering hack an official function in the engine is exactly what I think would be good. I know I'd feel much more comfortable about using such a function if it was written by the guys that wrote the rendering code, rather than whatever I hack in with my limited understanding of the pipeline..
Dusty
#4
eg:
I could live with that.
03/30/2011 (8:18 am)
Personally, I'd settle for being able to manual load materials with script via execing a file at level load.eg:
exec("./level1_mats.cs");
//level1._mats.cs
loadMat("brick1");
loadMat("wallx");
loadMat("etc");I could live with that.
#5
03/30/2011 (8:31 pm)
Manoel, does that hack work well? Because we are having massive hiccups when moving around our levels, that go away after moving the camera once around the whole place... Would be cool if you could share that code... Thanks! 
#6
A ton of the stutter in our outdoor scenes was caused by shadergen running for complex terrain materials. So i did some fixes to reduce the shader permutations and pre-generate shaders at startup. This helped a ton, but we still have some hiccups.
I'm thinking now the better approch to all of this is to "warm up" the scene before you start playing. My idea is to render a cubemap of the scene into an offscreen buffer from the center of the level. We would disable LOD, zoning, and occlusion and move the far plane set to see everything. In theory this would cause all sorts of caches, textures, shaders, buffers, etc to be loaded and ready to run.
While we're at it we could also "pre-tick" the scene a few frames to allow particle effects to get started, trees to start swaying, and physics to settle down.
Anyway... it may not catch *everything*, but it might be really close and better than what we get now.
03/30/2011 (9:18 pm)
I think we may be able to make some improvements here for 1.1 as we have bugs already logged against the stuttering issues.A ton of the stutter in our outdoor scenes was caused by shadergen running for complex terrain materials. So i did some fixes to reduce the shader permutations and pre-generate shaders at startup. This helped a ton, but we still have some hiccups.
I'm thinking now the better approch to all of this is to "warm up" the scene before you start playing. My idea is to render a cubemap of the scene into an offscreen buffer from the center of the level. We would disable LOD, zoning, and occlusion and move the far plane set to see everything. In theory this would cause all sorts of caches, textures, shaders, buffers, etc to be loaded and ready to run.
While we're at it we could also "pre-tick" the scene a few frames to allow particle effects to get started, trees to start swaying, and physics to settle down.
Anyway... it may not catch *everything*, but it might be really close and better than what we get now.
#7
03/30/2011 (9:23 pm)
That would be really awesome =) 
#8
03/30/2011 (9:32 pm)
I enjoy the many ways such a "warm up" metaphorically mimics The Big Bang, and a "pre-tick" accounts for other possibility's. Delightfully entertaining...
#9
I know the large hitches and stuttering as we pick up various views of our level are exactly the same kinds of things we're running up against and trying to combat as well. And again, these all go away after the level has been viewed.
So of course the follow up question is - do you think there's a realistic chance of getting this pre-game warmup feature into 1.1 final? It sounds like a pretty hefty feature, so I can see the potential for breakage, and we don't really know how close you guys are to lockdown.
Thanks for the update
Dusty
03/31/2011 (5:09 am)
Tom: That seems like an even much more robust approach than just one of stuffing textures into vram at mission load. I especially like the idea of running a few pre-ticks of the sim to get get particle, physics, and wind effects going.I know the large hitches and stuttering as we pick up various views of our level are exactly the same kinds of things we're running up against and trying to combat as well. And again, these all go away after the level has been viewed.
So of course the follow up question is - do you think there's a realistic chance of getting this pre-game warmup feature into 1.1 final? It sounds like a pretty hefty feature, so I can see the potential for breakage, and we don't really know how close you guys are to lockdown.
Thanks for the update
Dusty
#10
03/31/2011 (8:22 am)
I wonder how much the pre-game warmup and/or pre-tick'ing would affect the mission load time? Even if it effects it adversely I think the benefit would be a good tradeoff.
#11
03/31/2011 (9:37 am)
Well, if it would move the time I have to wait to move the camera after the loading screen to the loading screen itself, it's not really a trade-off, but a definite improvement. 
#12
03/31/2011 (1:34 pm)
There is also a (seemingly) texture related stutter when an image file such as a weapon is first called and mounted, which I'm sure others have noted, but no one had mentioned it specifically yet.
#13
I've seen what you've described... i'm curious what the stutter is as weapons are usually fairly simple, but i suspect its ShaderGen again.
I'll investigate.
03/31/2011 (6:37 pm)
Quote:do you think there's a realistic chance of getting this pre-game warmup feature into 1.1 final?Well i have a bug or two assigned to me now on reducing these hiccups, so when i get to them i will consider trying that technique.
Quote:stutter when an image file such as a weapon is first called and mountedThis is where a technique like i describes doesn't help... things that are hidden and are suddenly added to the scene.
I've seen what you've described... i'm curious what the stutter is as weapons are usually fairly simple, but i suspect its ShaderGen again.
I'll investigate.
#14
04/01/2011 (7:48 am)
For weapons and the sort you could just hide an instance of the item somewhere in the level for preload (this is what CoD does/did with MG turrets - the turrets themselves were script objects but they needed an instance of the mesh hiding somewhere in the level).
#15
04/01/2011 (11:49 am)
Hah... interesting. So you like stick one weapon under the terrain or something. A very simple solution.
#16
Since we have a simTime-based fade-in effect when the game loads, the initial freeze when loading everything is hidden.
BTW, I also had to resort to preloading tricks when building dynamic shapes using lots of addMesh() calls. It turned out that each call to addMesh() was loading and unloading the source DTS files. Preloading the source DTS files into temporary StaticShapeData objects (created with the new keyword) sped things up a lot.
04/01/2011 (2:36 pm)
My horrible hack was to set mGlobalBounds to true in the onAdd() callback of the objects I wanted to preload, and then set it back to false inside their prepRenderImage() functions. I also skip per-mesh culling in TSStatics if mGlobalBounds is set to true (before setting it back to false). It forces them to render without frustum culling for the first frame. Since we have a simTime-based fade-in effect when the game loads, the initial freeze when loading everything is hidden.
BTW, I also had to resort to preloading tricks when building dynamic shapes using lots of addMesh() calls. It turned out that each call to addMesh() was loading and unloading the source DTS files. Preloading the source DTS files into temporary StaticShapeData objects (created with the new keyword) sped things up a lot.
#17
05/12/2011 (8:46 pm)
THREED-1853 Added...but not sure if there is any simple solution that will get us to 1.1 final. 
Associate Steve Acaster
[YorkshireRifles.com]