Preloading resources into a W3D questions 2004-03-19 - By Neto
Back
> Using loadfile is quicker to perform the operation (although is this on
> a per-sample basis, or simply if doing lots? IE is a single loadfile
> quicker than a clone, because clone has the bug where it slows down
> massively with repeated use).
> But loadfile may affect subsequent framerates IF you don't unload the
> source afterwards?
The thing with loadFile is that you *don't* load the source! Based on what
it looks, the external W3D file is simply appended to the target W3D, and
the new models are streamed into RAM. When you loadFile(), the member state
will change to streaming, and after the new models have finished loading
it'll go back to 4. So you still keep a single W3D in RAM all the time - it
just get's new stuff streamed into it.
> Removing the bonesplayer from models which don't need them definitely
> helps - is this true of source models too?
> It seems to me that a W3D has no affect until it's referenced. Is it
> possible that the clone / loadfile kickstarts the animations within it,
> which continues indefinately eating up CPU / slowing framerates once the
> copying has finished?
I don't know if you can remove the bonesplayer from the model resources, but
when dealing with characters, I ususally load them, delete their model and
store their resource and shaderlist in a variable, so it can be spawned when
needed. But yes, the loaded models (also cloned ones) will have bonesplayer
attached to them automatically.
> I'm interested in the loadfile vs 'proper' copying speed, since it may
> in future be worth structuring my model data differently if there's a
> significant difference, cos I hate loading speed.
> But, I'm doubtful.
I have this level, that is the biggest one in my game. The main W3D (with
the pretty geometry and textures) has 4MBs. Then there are all the
characters, a W3D with collision proxies, and a W3D with sound mapping. This
level has many different "states", that vary as the game events goes on .
The way I found to manage states was having a text member that describes the
W3Ds used to build a certain state, and have a text member that describes
the scripts that'll be used for that state (almost a custom scriptting
system). The game uses clone to build the level state, and it is SLOW. To
get around it, I made a caching system using #fileSaveMode, that builds a
cache W3D, and stores it in a cast, so I don't need to clone models at run
time. Then I simply switch members. It's faster, but this particular level
still takes 6~8 seconds to just preload the cached W3D. Building one of
those caches takes 20~30 seconds.
In the mockup I did using loadfile, it build the same level in 3~4 seconds.
It's twice as fast as LOADING a cached W3D approach, and I can dish the
whole caching hurdle altogether, making the game a LOT smaller.
> For CEFPS, originally I was cloning models (locally, Ie within the same
> W3D member).
> Each successive clone operation took longer and longer, although there
> was no speed hit in the final framerate I was aware of.
> I then swapped to newmodel() and model.resource =, which roughly made
> loading times 1/4 or less of what they were before, which seems roughly
> in line with your loadfile improvements over clone.
>
> Overall, clone is evil, but for setting up initial things to then be
> copied by other means, it has it's uses I feel. Loadfile isn't a direct
> perfect replacement, because it's an all or nothing approach, but that
> can be worked around (if I feel it's worth it).
>
> Barry
> gerbil@(protected)
>
>
> __ ____ ____ ____ ____ ____ ____ ____ ____ ____
> Dir3d-l mailing list
> Dir3d-l@(protected)
> http://nuttybar.drama.uga.edu/mailman/listinfo/dir3d-l
>
__ ____ ____ ____ ____ ____ ____ ____ ____ ____
Dir3d-l mailing list
Dir3d-l@(protected)
http://nuttybar.drama.uga.edu/mailman/listinfo/dir3d-l
|
|
