Bryan Valencia wrote:
> andrel wrote:
>> I think the main problem with this approach is that you assume you 
>> always know what is in the file. That is a dangerous assumption if you 
>> write a library. It is also not important from a POV point of view, 
>> whatever it is that you load, you can translate, scale and texture it, 
>> so it is an object.
>> Warp's question was if .obj files can be anything apart from meshes 
>> i.e. if it can harm if you put the result in a mesh. Technically for 
>> an .obj file there may not be a danger, but conceptually it is wrong 
>> because other files can contain other objects and you don't want .obj 
>> loading routines to behave different from, say, .off files.
> 
> 
> Typical behavior in the programming world is that when a mesh tries to 
> open another file, it acts the same as when you (for instance) try to 
> open a .wav file in paint.  You would get an exception.
> 
> If there were a wavefront object file were opened by a 
> nurb.loadfromobj(), it would raise an exception.  The filename is 
> irrelevant, except to make it a little easier to use the default 
> file-open dialogs on it.
> 
> Think of it this way:  if you load an image in POV of type "jpeg" and a 
> filename of "MyImage.png", the parser barfs.  Ditto if you did #include 
> "command.com".

I agree (apart from the parser barf, that is a runtime error. The 
association of an extension to a format is a windows thing and POV isn't)

> It would be the same here - the language can't load raw SDL into a Mesh 
> container.

and here we part ;) It may be this way if it were implemented your way, 
but my point was that it shouldn't.
Please explain why the user has to know what is in a file when writing a 
POV script or library.

Post a reply to this message