[GEM-dev] Re: [PD] gem renders a teapot with 2 heads!

[james tittle]

On Feb 24, 2005, at 12:40 PM, IOhannes m zmoelnig wrote:

> james tittle wrote:
>> loaders...all I'm doing is opening the file, checking the extension, 
>> then calling the appropriate loader...simple enuff!  This much is
> well i am not sure whether it is a good idea to depend on the 
> extension. (yes  i know that the whole redmond os is wrapped around 
> that, but this doesn't prove anything)

...it seems to be how many people do it:  there's also a check after 
opening the file to make sure that the first bytes are correct (ie.  
correct magic number)...

>> working, I'm just getting around how to remove the other glm* stuff 
>> in a more abstract way...also, do we want all the loader code in one 
>> file, or seperate out into format specific files?
> i thought of one (abstract) class that defines the data and the 
> render-method; and child-classes would then implement the readers  
> (aka: open()-method)
>
> i would then call each loader with the given filename and the first 
> one that reports that it supports it (even if this decision is only 
> based on looking at the extension) will get the job.
>
> simple enuff...

...hehe...sounds like you thought about this before coding:  I'm 
usually coding before thinking!  I really should finish up the altivec 
color conversions before getting deeper into this...

> the problem why i got stuck is, because i couldn't decide how to 
> layout the data (one big vertex-array for the whole model and 
> references to this pool for the submodels (like in OBJ), or arrays for 
> each submodels  (might be more general) or...); sounds ridiculous, but 
> i quickly got tired...

...I definitely see two different objects (or perhaps one that changes 
behavior based on a message setting):  one for the vertex-array stuff 
and the other for "normal" model loading...IIRC the 3ds code I'm 
looking at uses submodel arrays, but like yourself, I got to a point 
and said "hmm...now where...?"

l8r,
jamie