In article <4716501d$1@news.povray.org>, 209### [at] gmailcalm says...
> Warp wrote:
> > Alain <ele### [at] netscapenet> wrote:
> >   The important thing, IMO, is that it doesn't hard-code that what is
> > returned by the function is precisely a mesh. It should be more abstrac
t
> > than that.
> 
> Actually no.  I would want a mesh object to be able to load from mesh 
> data types only (or be created on the fly in SDL like always)  I would 
> never want a CSG union, light source, or bologna sandwich to be able to
 
> load into a mesh, for instance.
> 
> The POVMesh object should descend from a POVObject, just like a 
> POVSphere, POVCylinder, POVBlob, POVUnion, etc.  But there should be no
 
> way that a POVCylinder would implement the loadfrom3DS() method.
> 
> Keep in mind that the point of this thread is not about things to do to
 
> the SDL to improve it (which should also happen), it's about decoupling
 
> the SDL from the back-end so that we can integrate with more powerful 
> languages (along with the SDL).  The examples I gave were not how I 
> think the SDL should look at all.  I was envisioning what the code would
 
> look like in a fully object-oriented language.
> 
It might be noted that there are some mesh formats that contain some 
additional data, some/all of which "might" be usable as well, so the 
result would need to either include commands to "load" those elements 
using other commands (which may/may not be a good idea), or import them 
at the same time. I.e. the "mesh object" generated would need to also 
include those things, like textures, etc., when completed. Obviously 
those things need to be accessible later too, in case, for example, you 
don't want to use the texture that came with the model. But otherwise, 
yes. It wouldn't make much sense for something like "cylinder" to have a 
"cylinder.loadfrom3DS" function. In fact, it makes a lot of sense to 
only apply the imports for certain types "too" the types that support 
them. So, in the case of mesh, you make an empty mesh, then use "its" 
import function to get the result.

Mind you this won't work for something like a AutoCAD files, since it 
can contain a mess of different data types, not just meshes, so you also 
need a sort of "importobjects" function that can generate a table of 
objects from the file. You don't one, in that case, a single object, 
like some of those horrible converters I tried way back when did, where 
it took dozens of distinct objects, like from a CAD file of a human 
body, and generated "one" mesh, when the original file had them clearly 
subdivided into individual parts. What a mess that was...

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message