> Dave McClurg wrote:
>
> Currently, when you load something in SSG there is no
> way to control what gets loaded. Usually, that is
> ok, but if you want a small memory footprint and
> don't have an easy way to cleanup the models, I
> propose adding load hint flags:
>
> enum ssgLoadHintFlags
> {
> SSG_LOAD_TEXTURES = (1<<0), // texture images and coordinates
> SSG_LOAD_VNORMALS = (1<<1), // vertex normals
> SSG_LOAD_VCOLOURS = (1<<2), // vertex colours
> SSG_LOAD_ANIMATION = (1<<3), // transform and mesh animation
> SSG_LOAD_EVERYTHING = ((1<<15)-1),
> SSG_LOAD_NOTHING = 0,
> } ;
>
> void ssgLoadHint ( int hint_flags ) ;
>
> Of course, this won't happen until PLIB 1.3 but
> i just wanted to throw the idea out for comment.
Yes - I can see why some people might want this.
I wonder if it would be better to do this with a callback
function though. Under that scheme, if the application
installs a 'Leaf node creation callback', then the loader
will call the callback with the lists of vertices, colours,
normals, etc - and the application would then create the
node, populate the various fields (or not if it didn't
want them) and return the address of the ssgEntity it
finally decided to create back to the loader.
If the user does not define a leaf node creation callback
then the loader could simply create a default node type
containing all the data - needed in order not to break
existing applications.
That would have several advantages:
1) We allow the callback node to do this stuff
conditionally (eg if you wanted only leaf nodes
containing Purple polygons have their texture
coordinates removed).
2) It would also solve a related problem - should
the loader create an ssgVtxTable or the up-coming
ssgCVA leaf node type? Should the loader demand
that a display list be created? ...etc.
3) It would allow for new loader constraints to be
added in the future without having to go in and
change all of the half dozen loaders that are
being written.
--
Steve Baker http://web2.airmail.net/sjbaker1
sjb...@ai... (home) http://www.woodsoup.org/~sbaker
sj...@ht... (work)
|
