james tittle wrote:
On Feb 24, 2005, at 5:33 AM, IOhannes m zmoelnig wrote:
currently only this format is supported, but i have started to write loaders for other formats (like 3ds, and...) but haven't got too far right now...
...good news: I also have a "proposal"/working code for multiple
well really i stopped writing on it soon after i had posted my start at the gem-dev... :-( hopefully i'll find time again (and to fix the avi-player in windows, and and)
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)
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...
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...
mfg..ad IOhannes
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
james tittle wrote:
...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)...
yes, i jsut wanted to point out, that if we have a modular thing, the decision of which file a module can handle should be handled by itself (as it knows best what it is able to do). i don't think to do it the other way round: calling a special modules just because we _think_ it can handle the file...
simple enuff...
...hehe...sounds like you thought about this before coding: I'm usually coding before thinking!
but i often get stuck while thinking...
...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...
yes the interface to pd should stay separated (as is now); but both [vertex_model] and [model] should use the same model-loader code.
so my ModelLoader-class should have a render()-method (for displaying) and some methods to extract the vertex-arrays (or whatever other arrays are stored in the model)
mfg.ad.sr IOhannes
-
IOhannes m zmoelnig -
james tittle