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?
> - 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...
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.
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.
> 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
