loading members at runtime 2004-02-27 - By NoiseCrime
Back
Hi all,
Just wanted to run this pass people and see what they think, or would do in
this situation.
I'm working on a project that has a large number of 3D models which have all
their textures seperate. There are several reasons for this, but mainly
becuase many models use the same texture, each model has bones animation and
additional models will be downloadable later which will proberbly re-use
many textures.
During development, for simplicity I just loaded all the textures into a
single cast lib, and wrote a script that would manage texture creation. It
would check if the texture already exists, and if not preload the bitmap,
set it to a texture, and finally unload it again. The idea being that since
sw3d keeps its own copy of the texture in memory, there is no point having
the bitmap member kept in memory by Director. Of course Director should
eventually clean this up itself, but it can't hurt to help it out. Besides
its good to keep the memory requires to a minimum, and the whole texture
castlib is already coming in at about 11mb, so i really don't want to have
all that loaded in memory constantly.
However to support the downloading of additional models and their textures I
need to switch to a new method. As I see it there are several possibilites.
1.Open castlib
Import new textures into the texture cast at runtime, and use 'savecastlib'
Really don't like this idea for a number of reasons. If the save gets
corrupted the user has lost all the textures, and if the cast lib itself is
corrupted, then I doubt the projector would even work. The castlib is 'open'
and not compressed (single files can have jpg compression). Any user issues
will be harder to track down with regard to textures as we have no way of
knowing whats gone on in the castlib.
2. Importfileinto
This is the way i'd normally approach it, and have used it on a number of
occasions. However i'm concerned by the text in the help that says it can
use up memory quickly, but this appears to be on a per cast member imported
basis. That is if you constantly import into the same member its unlikely to
add any memory overhead, but import 100 cast members then obviously you're
memory is going to be eaten up.
3. member.filename
This is what i'm considering using, and have coded up already so I know it
works. Its actually very similar to importfileinto, but instead i use a
single linked member in the cast. To change bitmaps I just link it to the
file I want, I can then create a texture from it, before linking the next.
Personally then i've discounted option 1, and prefer option 3, but frankly I
don't see there is any real difference between options 2 and 3.
Does anyone know of any differences betwen using importfileinto vs
member.filename?
Any recomendations to use or avoid any option based on experience?
Anything i've missed?
As i've said i've implemented the member.filename approach and it appears to
work flawlessly. Memory use looks consistant between this and the old
castlib version. So unless there is any good reason not to I'll stick with
that. Oh the project is a windows based projector only, slight possibility
of a Mac version sometime in the future.
thanks
Noisecrime 2004
__ ____ ____ ____ ____ ____ ____ ____ ____ ____
Dir3d-l mailing list
Dir3d-l@(protected)
http://nuttybar.drama.uga.edu/mailman/listinfo/dir3d-l
|
|
