jan p. springer wrote: > hi, > > that's a nice list. i'd like to point out that all fileformats loaded through > performer may vanish if abi compatibility breaks (i'm currently trying to > convince someone at sgi to just provide a gcc4 release); but with virtually > nobody doing maintainance on it it will just vanish sooner or later. so, > leaving out performer i'd like to see (natively for 2.0): > > - dxf, exr, iv, lwo, lws, off, ply support > - exr, rgb, sgi > - rot, scale, trans, tar, bzip2/gzip/zip > > (from http://opensg.vrsource.org/trac/wiki/OSGComparison flagged as not (yet) > available for 2.0)
I think we should start building up a list of these desired file formats as part of the yet to be written 2.0 roadmap. I agree that with Performer dying off we can't rely upon it for any formats in the future. I think it may be a good idea to write a loader similar to the performer one but for OSG. That way we could load any format that OSG can load. It may be a pain to maintain though as even the simplest programs I have for OSG seem to break every time I update to a latest version of OSG. > also, i'm wondering if this might not the point in time/space to think again > about reviving lodestone or sth. similar? (see below) Matthias Stiller wrote: > Hello Allen, > > in an ideal world without resource constraints we think these formats > could be/get important: > > - X3D > - Collada (ok there's already something happening) > - 3DXML (Dassault's pseudo open format ) > - 3DM (Rhino, a cheap but nice modelling environment) X3D and Collada are probably the most important to us as well. As far as 3DXML, is the full spec available publically? Back to loaders in general... Lodestone was always a great idea but I don't see any reason that other developers would really kick in on it now. OSG already has a bunch of loaders, the proprietary scene graphs only care about the ones their customers want, and game engines generally focus on their native formats. There doesn't appear to be any reason for these groups to want to create or use a lodestone type system. I think the best we could do is try to minimize the effort needed to create and maintain a loader. What I would like to see is a nice builder/helper system in OpenSG that would make writing file loaders much easier. If we could capture all the common code in some helper classes I think it would make the code for writing a loader smaller, easier to understand, and simpler to write. It may also have the side benefit of making all the loader code use a similar design pattern and thus make it more easy for any developer to look at any loader and understand the code. Another way we could minimize effort is to port the loaders that already exist in other systems. For example if we really want a loader for a format already support by OSG, why not just port that loader code to OpenSG and use it directly? We would probably want to keep the code a similar as possible so we could apply updates and patches based on future changes from the original version, but we could use subversion to handle most of this pain for us. It seems to me like a way to get some loaders up and running quickly. But I haven't done anything more then look at the code, so I may be way off on this. I was hoping to put an engineer on some of these things for the next month but I decided to have him work on some other OpenSG contributions instead while the 2.0 roadmap clears up. Even if I had the time to work on loaders I don't think it would make much of a dent unless there are other people interesting in working in this area. Are there other interested spending time on writing or porting loaders? If there was a roadmap that laid out the plans for the loader system and the loaders that should be created/ported would you be willing to help out with them? -Allen ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
