Dirk Reiners wrote: > Hi Everybody, > >as a basis for this discussion I would be very interested in getting >some feedback on which formats people are actually using vs. formats >that would be 'nice to have'. > >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 >> >> > >The ones that are in 1 should be easy enough to port. > >Looking around the web I see lwo/lws as interesting extensions, as there >are a lot of models in those formats. How important is .iv these days? > > > >>- exr, rgb, sgi >> >> > >Image formats are a different story. It might be a good idea to move >away from individual loaders and instead use another project for that. >I've long fought the fight for new dependencies, but it seems to be less >and less productive to do handle this ourselves. > >Contenders would be ImageMagick, DevIL and FreeImage. I haven't used any >of them, any comments or preferences? > > My preference would be to add support for plugins to OpenSG (see the wiki discussion) and allow people to add any or all of these. If they are available then we compile the plugin, if not then we don't. We could even extend it to add support for video formats through xine-lib and other libraries like that. Basically we would try never to write an image loader again but just writer interfaces to image loading libraries (ask what they support, load a file, save a file, etc). This should allow us to build on the shoulders of others quite a bit.
>>- rot, scale, trans, >> >> > >See my other mail. > > > >>tar, bzip2/gzip/zip >> >> > >Archive/compressed formats are a different story. This links back to the >discussion about HTTP and other data providers, hey're just a different >flavor. Important, but a different topic. > >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) > >Patrick Meier wrote: > > Hi, > > > > X3D and Collada are nice - but for the others I see some problems: > > > > 1) 3DXML can contain encrypted data - you don't find infos in the >specs (I also thought about integrating it into OpenSG) > >Yeah, that's a killer for me. > > > 2) for Rhino we would need NURBS support or we have to recalculate some > > parts (I don't remember whats missing into OpenSG: rational or >non-rational support) > >It's coming. Give us (or rather Akos and Michael) a little time... > > Once nurbs support is in, this would be a great loader to even have implemented partially so we can demonstrate the nurbs capabilities. Has anyone written a Rhino loader before? Is it very difficult? >Allen Bierbaum wrote: > > > > 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. > >Yes. > > > 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. > >Thinking about that was the main reason for changing namespace names in >2. I would be very interested in seeing that. > > > 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. > >Yup. That's what killed it before it got born, IMHO. > > > 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. > >IMHO loaders are split in three parts: structure, geometry and >materials/surface attributes. > >Structure is fairly easy, a Group is a Group, no matter where. There are >some complications in transforming Node types that are not there, but >other than that it's pretty straightforward. So no real need for helpers >or wrappers. > > There is one type of helper that *may* be useful here and this is where I think commonality between loaders could be introduced. At least in the loaders I have written I always seem to end up using some sort of stack structure where I push and pop nodes as a traverse through the source data. This may take the form of a real stack or it may just end up being a pointer to an OpenSG node, but the concept is the same. When I visit a new "node" in the source data I end up deciding if I must create a new node and attach it to the current head or if I need to modify that node by creating a core or something similar. What I also then end up with is a bunch of helper building methods that can each do their part to either build a node/core or extend the current node/core. I don't know if it is possible or not, but I wonder if OpenSG could formalize a pattern like this (or something else better) so all the loaders could use it and then the implementation code may look very similar between the loaders and hopefully simplify maintenance. It is very possible that I am being overly optimistic here though so please tell me if I am crazy. :) >Geometry is putting together the vertices/normals etc. That's a part >that's non-trivial as it involves a ton of objects, so it makes sense to >have some helper. The GeoBuilder is what I would hope covers that part. >It's not finished yet, but it's getting there. > >Materials/Surface Attributes are not too bad, as most file formats have >a rather direct mapping to OpenGL-style things. It gets more complicated >with multi-pass and shades, but so far very few formats support that, so >I'm not sure how to design helpers for that. > >So I think we're not too bad in terms of stuff. We need to make the >GeoBuilder more complete, but other than that writing a loader for a >simple format like off should be fairly simple. > > Yes, the geom builder could help out. We just need to keep extending it to support more capability and hopefully simplify the loaders in the process. :) -Allen > > 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. > >That is always an option. > >Yours > > Dirk > >------------------------------------------------------------------------- >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 > > > ------------------------------------------------------------------------- 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
