Re: [osg-users] Thoughts on a non Collada DOM based Collada plugin
HI Jason, On Fri, May 8, 2009 at 9:36 PM, Jason Daly wrote: > Yeah, I suppose it is, it seems less now that it's done, but I guess I was > busy for a while with it. Time often colours reality in a favourable light :-) >> What was the motivation for writing this code? You mention the the >> COLLADA DOM didn't look easer to use than rolling your own. I presume >> that the OSG's plugin didn't expose enough data that you need in your >> application. > > Right. In general, we needed an art path between 3ds MAX and VESS, and > specifically, we needed it for animated characters. We had an existing > Cal3D-based solution, but it was getting harder and harder to maintain. > osgAnimation had been talked about then, but it hadn't really gone anywhere > yet, and we already had some of the needed data structures in place from the > Cal3D work. If only we could click our fingers and turn back time... without loosing all the effort done during that time. Where's Hiro when you need him! > A big part of VESS is the scene graph abstraction layer (which proved quite > useful to us when Performer died). VESS nodes and attributes are > implemented (in this version) using the appropriate OSG objects. So, I'm > not constructing an OSG scene graph explicitly, but there is one being > constructed. Yes this make sense. In terms of reuse it might limit us. Although perhaps one could take a builder plugin approach to constructing scene graphs. >> I ask these questions as I'd expect many others will be in a similar >> position. If there might be a way to solve several problems at one >> time then it'll be a much more compelling task to rewrite our plugin, >> rather than just trying to fix the compile issues. >> >> Perhaps it might be possible to take your VESS collada code as a base >> and create an OSG + VESS compatible library that both projects could >> use. >> > > Well, I don't think there will be a problem with contributing the code. I'm > a bit skeptical as to how useful it will be, as a lot of it is pretty > specific to the way VESS works. I suppose it may be better than starting > completely from scratch, though, and it's commented pretty thoroughly, so it > should be understandable. I can't promise I'll have time to work on it > myself, but I'll try, and I can certainly answer any questions that come up. > > Let me know if you want to move forward with this, and I'll see what we can > do. Even if one only learns from it it would still be a useful thing to review. Do you have a timeline for when it might be open sourced? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thoughts on a non Collada DOM based Collada plugin
Hi, Robert, Robert Osfield wrote: About 10,000 or so, just for the COLLADA elements. A lot of it relies on existing VESS classes too, so that number is probably a bit low, although a lot of the code is basic DOM-like functionality that just parses XML into various objects and structures. That's a pretty big chunk. Yeah, I suppose it is, it seems less now that it's done, but I guess I was busy for a while with it. What was the motivation for writing this code? You mention the the COLLADA DOM didn't look easer to use than rolling your own. I presume that the OSG's plugin didn't expose enough data that you need in your application. Right. In general, we needed an art path between 3ds MAX and VESS, and specifically, we needed it for animated characters. We had an existing Cal3D-based solution, but it was getting harder and harder to maintain. osgAnimation had been talked about then, but it hadn't really gone anywhere yet, and we already had some of the needed data structures in place from the Cal3D work. Are you building the OSG scene graph for your collada representation? In a way :-)COLLADA kind of has two phases, the creation of "library" objects, and then the instantiations of those objects into the visual scene. The VESS COLLADA loader first parses the XML library objects into the corresponding classes, and then these are instantiated into VESS nodes and attributes. A big part of VESS is the scene graph abstraction layer (which proved quite useful to us when Performer died). VESS nodes and attributes are implemented (in this version) using the appropriate OSG objects. So, I'm not constructing an OSG scene graph explicitly, but there is one being constructed. I ask these questions as I'd expect many others will be in a similar position. If there might be a way to solve several problems at one time then it'll be a much more compelling task to rewrite our plugin, rather than just trying to fix the compile issues. Perhaps it might be possible to take your VESS collada code as a base and create an OSG + VESS compatible library that both projects could use. Well, I don't think there will be a problem with contributing the code. I'm a bit skeptical as to how useful it will be, as a lot of it is pretty specific to the way VESS works. I suppose it may be better than starting completely from scratch, though, and it's commented pretty thoroughly, so it should be understandable. I can't promise I'll have time to work on it myself, but I'll try, and I can certainly answer any questions that come up. Let me know if you want to move forward with this, and I'll see what we can do. --"J" ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thoughts on a non Collada DOM based Collada plugin
Hi Jason, On Fri, May 8, 2009 at 1:06 AM, Jason Daly wrote: > Not yet, but we're hoping to release it soon. It'll be in the new version > of our VESS library (http://www.irl.ucf.edu/software/vess). Excellent, so it'll be open sourced :-) > About 10,000 or so, just for the COLLADA elements. A lot of it relies on > existing VESS classes too, so that number is probably a bit low, although a > lot of the code is basic DOM-like functionality that just parses XML into > various objects and structures. That's a pretty big chunk. >> What features did you extract from the files? Geometry? State? >> > > Geometry, materials, textures, skin controllers, node hierarchy (including > skeletons) and (certain) animations. It only supports the COMMON profile > for the COLLADA FX elements (no shaders at the moment). Support for > external references is also missing. What was the motivation for writing this code? You mention the the COLLADA DOM didn't look easer to use than rolling your own. I presume that the OSG's plugin didn't expose enough data that you need in your application. Are you building the OSG scene graph for your collada representation? I ask these questions as I'd expect many others will be in a similar position. If there might be a way to solve several problems at one time then it'll be a much more compelling task to rewrite our plugin, rather than just trying to fix the compile issues. Perhaps it might be possible to take your VESS collada code as a base and create an OSG + VESS compatible library that both projects could use. Robert. > Looking back over this code reminded me of how much there is to COLLADA and > what features I had to glaze over or ignore completely just to get the work > done in time. > > --"J" > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thoughts on a non Collada DOM based Collada plugin
Robert Osfield wrote: Hi Jason, ... Is this work published? Not yet, but we're hoping to release it soon. It'll be in the new version of our VESS library (http://www.irl.ucf.edu/software/vess). What Xml parser did you use? libxml2, along with a fairly thin wrapper layer that we wrote as well How much code is it in terms on number of lines? About 10,000 or so, just for the COLLADA elements. A lot of it relies on existing VESS classes too, so that number is probably a bit low, although a lot of the code is basic DOM-like functionality that just parses XML into various objects and structures. What features did you extract from the files? Geometry? State? Geometry, materials, textures, skin controllers, node hierarchy (including skeletons) and (certain) animations. It only supports the COMMON profile for the COLLADA FX elements (no shaders at the moment). Support for external references is also missing. Looking back over this code reminded me of how much there is to COLLADA and what features I had to glaze over or ignore completely just to get the work done in time. --"J" ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thoughts on a non Collada DOM based Collada plugin
Hi Roger, We seem to have jumped straight into a technical discussion on how this could be done with very little discussion on whether it should be done. I think we need to take a step back here. At the moment I am tending toward the view that we should spend effort on improving the current build system and documentation for the plugin. I have yet to see a good argument why we should do otherwise. My problem with the COLLADA DOM is that it uses dependencies which we also use in our software, like boost and libxml2. That means if we're going to compile the OSG COLLADA plugin, then we need to compile the COLLADA libs against the same versions of boost and libxml2, and link those dynamically, or link them statically into both COLLADA and our software (which is a big payload for boost, it would be there twice and it's already BIG). This means that using the COLLADA plugin is no longer just a case of building COLLADA and getting OSG's CMake to find it, we also need to make various changes in the COLLADA libs' build system to make it use the same boost and libxml2 libs, and those changes need to be made each time we update COLLADA. It's a drag. I'm open to suggestions on how to alleviate this. I expect I'm not the only one in this situation, lots of people use boost in their software. Having our own COLLADA reader would certainly make that part disappear. But I agree it might be opening a large can of worms. I'm not the best placed to decide if the tradeoff is worth it, but the reasons above are why we don't use the COLLADA plugin, and once again I expect there are others in the same boat. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thoughts on a non Collada DOM based Collada plugin
Hi Robert, Comments in line. Roger Robert Osfield wrote: Hi Roger, On Thu, May 7, 2009 at 9:26 AM, Roger James wrote: We seem to have jumped straight into a technical discussion on how this could be done with very little discussion on whether it should be done. I think we need to take a step back here. At the moment I am tending toward the view that we should spend effort on improving the current build system and documentation for the plugin. I have yet to see a good argument why we should do otherwise. As a first step improving the current build system and docs is the right thing to do. It's far less work and will provide much more immediate results. Agreed. I should have some time to look at this in about two weeks time. One thing I was thinking about was trying to force a static link of the DOM to try and alleviate some of the dll/so problems. Unfortunately I do not have a Linux build environment at the moment. However, we can't magically turn the Collada DOM into something it's not, it's not a lightweight easy to use dependency, it's a beast to download, and slippery fish to compile. Our own build tweaks won't ever solve this issue. I know that well! ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thoughts on a non Collada DOM based Collada plugin
Hi Robert, On Thu, May 7, 2009 at 11:14 AM, Robert Osfield wrote: > > Are you suggesting an C++ interface for xml parsing that has a default > implementation, and then plugins that add alternate implementations? > The interface would need to be able to expose all the advanced > features of the alternative features that would need from them so > might be end up being quite extensive. > > Hum... Yeah I am suggesting this, but I must admit that I don't know the piece of work that it represents as I only use XML for basic usages. -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thoughts on a non Collada DOM based Collada plugin
Hi Jason, On Wed, May 6, 2009 at 8:06 PM, Jason Daly wrote: > Robert Osfield wrote: >> >> Thoughts on how much work this might be to do? Thoughts on what >> features of the Collada DOM that are invaluable/hard to replace? >> > > I'm jumping into this thread a bit late, but I'll just add that I've written > a COLLADA loader for a different project, and I didn't use the DOM (I found > it hard to understand, and figured I could implement the features myself in > less time than it would take to learn it). It wasn't a trivial amount of > effort, but it's certainly doable. Is this work published? What Xml parser did you use? How much code is it in terms on number of lines? What features did you extract from the files? Geometry? State? Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thoughts on a non Collada DOM based Collada plugin
Hi Serge, On Thu, May 7, 2009 at 8:03 AM, Serge Lages wrote: > And what about a plugin system gor the XML reading/writing ? This way we > could have a self made parser without external dependencies and other > parsers depending on expat, tinyxml, libxml for advanced usages. Are you suggesting an C++ interface for xml parsing that has a default implementation, and then plugins that add alternate implementations? The interface would need to be able to expose all the advanced features of the alternative features that would need from them so might be end up being quite extensive. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thoughts on a non Collada DOM based Collada plugin
Hi Roger, On Thu, May 7, 2009 at 9:26 AM, Roger James wrote: > We seem to have jumped straight into a technical discussion on how this > could be done with very little discussion on whether it should be done. I > think we need to take a step back here. At the moment I am tending toward > the view that we should spend effort on improving the current build system > and documentation for the plugin. I have yet to see a good argument why we > should do otherwise. As a first step improving the current build system and docs is the right thing to do. It's far less work and will provide much more immediate results. However, we can't magically turn the Collada DOM into something it's not, it's not a lightweight easy to use dependency, it's a beast to download, and slippery fish to compile. Our own build tweaks won't ever solve this issue. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thoughts on a non Collada DOM based Collada plugin
People, We seem to have jumped straight into a technical discussion on how this could be done with very little discussion on whether it should be done. I think we need to take a step back here. At the moment I am tending toward the view that we should spend effort on improving the current build system and documentation for the plugin. I have yet to see a good argument why we should do otherwise. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thoughts on a non Collada DOM based Collada plugin
Hi all, And what about a plugin system gor the XML reading/writing ? This way we could have a self made parser without external dependencies and other parsers depending on expat, tinyxml, libxml for advanced usages. Cheers, 2009/5/7 Mathias Fröhlich > > Robert, > > There is also expat. Which is under a BSD like license (I believe). It is > also > small and well tested. > Almost all linux systems and most of the modern unix variants already > include > expat due to fontconfig depending on expat. > For the other systems, expat is small enough to be included into osg. Then > a > configure time test could be used to either use the system provided > libexpat > or build and use the osg provided. > > Greetings > > Mathias > > -- > Dr. Mathias Fröhlich, science + computing ag, Software Solutions > Hagellocher Weg 71-75, D-72070 Tuebingen, Germany > Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 > -- > Vorstand/Board of Management: > Dr. Bernd Finkbeiner, Dr. Roland Niemeier, > Dr. Arno Steitz, Dr. Ingrid Zech > Vorsitzender des Aufsichtsrats/ > Chairman of the Supervisory Board: > Michel Lepert > Sitz/Registered Office: Tuebingen > Registergericht/Registration Court: Stuttgart > Registernummer/Commercial Register No.: HRB 382196 > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thoughts on a non Collada DOM based Collada plugin
Robert, There is also expat. Which is under a BSD like license (I believe). It is also small and well tested. Almost all linux systems and most of the modern unix variants already include expat due to fontconfig depending on expat. For the other systems, expat is small enough to be included into osg. Then a configure time test could be used to either use the system provided libexpat or build and use the osg provided. Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thoughts on a non Collada DOM based Collada plugin
Robert Osfield wrote: Thoughts on how much work this might be to do? Thoughts on what features of the Collada DOM that are invaluable/hard to replace? I'm jumping into this thread a bit late, but I'll just add that I've written a COLLADA loader for a different project, and I didn't use the DOM (I found it hard to understand, and figured I could implement the features myself in less time than it would take to learn it). It wasn't a trivial amount of effort, but it's certainly doable. --"J" ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thoughts on a non Collada DOM based Collada plugin
We already pull in XML parser dependencies any way
If you use GDAL your going to need Xercess, Collada uses either Libxm2
or tinyxml , so for me we already have these in one form or another
I don't really care which one should be adopted but I really don't think
we should be writing our own when there are well tested implentations
out their
As to another 3rd part dependency,I have so many now and OSG is just one
its does not make much difference to me, they are typically compile once
add to my 3rdparty library VOB and only update when needed which is
quite infrequent and OSG is just one of those 3rd part dependencies )
Gordon
Product Manager 3d
__
Gordon Tomlinson
Email : gtomlinson @ overwatch.textron.com
__
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jan
Ciger
Sent: Wednesday, May 06, 2009 1:20 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Thoughts on a non Collada DOM based Collada
plugin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello Robert,
Robert Osfield wrote:
>
> I've never used TinyXML/TinyXML++. I'm certainly open to adopting a
> more capable XML parser than the one I've written so far. I'd rather
> not add yet another external dependency for core OSG features, which
> is why I opted to roll my own XML parser for Present3D (and the .p3d
> plugin) rather using libxml2.
The dependency is tiny, the code is pretty easy to use:
ticpp::Element *fog_e = root->FirstChildElement("fog"); std::string
fogname = fog_e->GetAttribute("name"); // get attributes // colour of
the fog float r = 0.2, g = 0.2, b = 0.2, a = 1.0; try {
ticpp::Element *color = fog_e->FirstChildElement("color");
color->GetAttribute("r", &r);
color->GetAttribute("g", &g);
color->GetAttribute("b", &b);
color->GetAttribute("a", &a);
}
catch (ticpp::Exception &e)
{ /* not present */}
fmgr->setColor(osg::Vec4(r, g, b, a));
etc.
>
> Merging TinyXML/TInyXML++ into the core OSG might be a reasonable
> thing to do, but only if it's easier to understand and maintain than
> rolling this code ourselves. My experience with a writing quick XML
> parser suggests that this tasks isn't a big one.
I definitely prefer using something like TinyXML or SAX to writing my
own parser - parsing trivial files is easy, once you get into obscure
things where encodings, schemas and what not that needs to be handled at
least to the degree that the parser doesn't choke on it, it is not fun
any more.
Regarding merging TinyXML into OSG - please, don't! It is very easy to
do and a lot of projects do so. This causes crazy problems once you try
to combine two libraries that use their own copies of TinyXML, neither
has put it into a namespace and the two copies are not identical. I have
hit this problem before with ReplicantBody, I believe, and it was a
non-trivial issue to deal with.
> In the context of port our Collada plugin across to use our own .dae
> parsing code I think that the low level parsing code itself is an
> order of magnitude less work that the actual work on the dae side.
> Tweaking the XML parser classes to support that type of files that
> we'll get with dae may well be advantageous i.e. we can make our
> parser Matrix/Vec/OSG object aware.
That you can do even with a 3rdparty parser - e.g. the code above is
parsing the data into OSG data structures.
I think that the right way to go is not to avoid a 3rdparty dependency
when one is needed at all costs by duplication of work. An XML parser is
something so common that I do not see a good reason for creating a yet
another incomplete implementation. I understand the pain with
dependencies well, but this will only add an extra piece to maintain.
Pick a well known, supported and working implementation and stick with
it.
Regards,
Jan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFKAca0n11XseNj94gRApB9AJ99pbCGUYy7+Bs5xDuxAlI+hdyBiwCggSI/
L0VQS7p9jsXxuck666aONI8=
=JcTa
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thoughts on a non Collada DOM based Collada plugin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello Robert,
Robert Osfield wrote:
>
> I've never used TinyXML/TinyXML++. I'm certainly open to adopting a
> more capable XML parser than the one I've written so far. I'd rather
> not add yet another external dependency for core OSG features, which
> is why I opted to roll my own XML parser for Present3D (and the .p3d
> plugin) rather using libxml2.
The dependency is tiny, the code is pretty easy to use:
ticpp::Element *fog_e = root->FirstChildElement("fog");
std::string fogname = fog_e->GetAttribute("name");
// get attributes
// colour of the fog
float r = 0.2, g = 0.2, b = 0.2, a = 1.0;
try
{
ticpp::Element *color = fog_e->FirstChildElement("color");
color->GetAttribute("r", &r);
color->GetAttribute("g", &g);
color->GetAttribute("b", &b);
color->GetAttribute("a", &a);
}
catch (ticpp::Exception &e)
{ /* not present */}
fmgr->setColor(osg::Vec4(r, g, b, a));
etc.
>
> Merging TinyXML/TInyXML++ into the core OSG might be a reasonable
> thing to do, but only if it's easier to understand and maintain than
> rolling this code ourselves. My experience with a writing quick XML
> parser suggests that this tasks isn't a big one.
I definitely prefer using something like TinyXML or SAX to writing my
own parser - parsing trivial files is easy, once you get into obscure
things where encodings, schemas and what not that needs to be handled at
least to the degree that the parser doesn't choke on it, it is not fun
any more.
Regarding merging TinyXML into OSG - please, don't! It is very easy to
do and a lot of projects do so. This causes crazy problems once you try
to combine two libraries that use their own copies of TinyXML, neither
has put it into a namespace and the two copies are not identical. I have
hit this problem before with ReplicantBody, I believe, and it was a
non-trivial issue to deal with.
> In the context of port our Collada plugin across to use our own .dae
> parsing code I think that the low level parsing code itself is an
> order of magnitude less work that the actual work on the dae side.
> Tweaking the XML parser classes to support that type of files that
> we'll get with dae may well be advantageous i.e. we can make our
> parser Matrix/Vec/OSG object aware.
That you can do even with a 3rdparty parser - e.g. the code above is
parsing the data into OSG data structures.
I think that the right way to go is not to avoid a 3rdparty dependency
when one is needed at all costs by duplication of work. An XML parser is
something so common that I do not see a good reason for creating a yet
another incomplete implementation. I understand the pain with
dependencies well, but this will only add an extra piece to maintain.
Pick a well known, supported and working implementation and stick with it.
Regards,
Jan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFKAca0n11XseNj94gRApB9AJ99pbCGUYy7+Bs5xDuxAlI+hdyBiwCggSI/
L0VQS7p9jsXxuck666aONI8=
=JcTa
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thoughts on a non Collada DOM based Collada plugin
Hi Rocardo & JS, On Wed, May 6, 2009 at 5:02 PM, Jean-Sébastien Guay wrote: > Hi Riccardo, > >> don't you think TinyXml (or its close relative TinyXml++, that also >> support iterators, templates, exceptions and other c++ friendly features) >> would be a nice alternative? > > Considering it took me all of about a day to write, and it was my own code > (i.e. I didn't need to learn to use it) I think it was fine at the time. Now > I might make a different decision. > > I'm not the one to make decisions related to what to include into OSG, so as > for why Robert didn't use TinyXML/TinyXML++ for his XML parsing for > Present3D, I imagine he'll see this and answer. Though we're getting > massively off topic for this thread... I've never used TinyXML/TinyXML++. I'm certainly open to adopting a more capable XML parser than the one I've written so far. I'd rather not add yet another external dependency for core OSG features, which is why I opted to roll my own XML parser for Present3D (and the .p3d plugin) rather using libxml2. Merging TinyXML/TInyXML++ into the core OSG might be a reasonable thing to do, but only if it's easier to understand and maintain than rolling this code ourselves. My experience with a writing quick XML parser suggests that this tasks isn't a big one. In the context of port our Collada plugin across to use our own .dae parsing code I think that the low level parsing code itself is an order of magnitude less work that the actual work on the dae side. Tweaking the XML parser classes to support that type of files that we'll get with dae may well be advantageous i.e. we can make our parser Matrix/Vec/OSG object aware. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thoughts on a non Collada DOM based Collada plugin
Hi Riccardo, don't you think TinyXml (or its close relative TinyXml++, that also support iterators, templates, exceptions and other c++ friendly features) would be a nice alternative? Considering it took me all of about a day to write, and it was my own code (i.e. I didn't need to learn to use it) I think it was fine at the time. Now I might make a different decision. I'm not the one to make decisions related to what to include into OSG, so as for why Robert didn't use TinyXML/TinyXML++ for his XML parsing for Present3D, I imagine he'll see this and answer. Though we're getting massively off topic for this thread... J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thoughts on a non Collada DOM based Collada plugin
Hi all, On 06/05/2009 16.41, Jean-Sébastien Guay wrote: Something that I found interesting about the quick XML parser code was that being done in C++ it was much more convenient to use than libxml2, when I ported Present3D across from being libxml2 based to osgDB/XmlParser based the code ended smaller and more readable. Yeah, I once wrote a small C++ wrapper around libxml2 because I found it cumbersome to use, also based on nodes in a tree like yours and it made the user code much easier to read. I totally get what you're saying. don't you think TinyXml (or its close relative TinyXml++, that also support iterators, templates, exceptions and other c++ friendly features) would be a nice alternative? It's just a couple of headers and cpp files to include, or a very small library if one wants to ship the precompiled lib. Licenses for the two are zlib/libpng and MIT respectively. Ricky ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thoughts on a non Collada DOM based Collada plugin
Roger James wrote: Problems in area 2 seem to revolve around two main issues. Firstly that the OSG Collada plugin only supports version 2.1 of the Collada DOM object model and needs to be specifically linked against a build of the Collada DOM that is made for that version and if dynamic linking is used it needs to be able to find the correct DOM library at runtime. I made a mistake in the above. What I meant to say was Firstly that the OSG Collada plugin only supports version 1.4 of the Collada Schema, and as arr as I know version 2.1 of the Collada DOM implementation (it may work with 2.2 but I seem to remember some outstanding problems) and needs to be specifically linked against a build of the Collada DOM that is made for those versions My apologies Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thoughts on a non Collada DOM based Collada plugin
Robert Osfield wrote: Hi All, To me it's looks like we are consistently getting a lot more support queries about the Collada plugin than any other our plugins. Build problems are rampant, and alas there isn't that much we can do about it directly. The Collada DOM does cause lots of problems for us, and they are problems that hasn't got fixed as time has moved on, at best one problem has been solved only to replaced by others. Collada DOM has always been troublesome, and it looks like it always will be. Robert, The problems with the collada plugin seem to me to fall into two broad categories. 1. Problems with the plugins (and other implementations) interpretation of the Collada specification. 2. Problems with the Collada DOM's build and deployment system and its interaction with the OSG build and deployment system. Problems in area 1 will still be there if we move to an in house parser. So we can probably ignore them for this discussion. However, here is my two pennies worth on them! (Flame On) Most of these problems stem from various different interpretations of the Collada Common Profile. This profile is said to be a profile for the exchange of digital assets between content authoring tools where the effects and techniques used are limited to those that can be eventually rendered on some abstract but so far undocumented fixed functionality rendering pipeline. The specification does not specifically cover the case where the asset exchange is between a content authoring system and a rendering system (such as OSG), although that is increasingly where Collada is being used. So to implement the OSG Collada plugin we have to define a mapping between an undocumented abstract model of a fixed function pipeline, and what ever OpenGL rendering pipeline model we choose to support. After many months of patient trying I have given up trying to get answers from the Collada people about issues that this raises as we seem to be talking different languages! http://collada.org/public_forum/viewtopic.php?f=12&t=1210(Flame off!) Problems in area 2 seem to revolve around two main issues. Firstly that the OSG Collada plugin only supports version 2.1 of the Collada DOM object model and needs to be specifically linked against a build of the Collada DOM that is made for that version and if dynamic linking is used it needs to be able to find the correct DOM library at runtime. Secondly, the out of the box Collada DOM build systems links against versions of standard libraries such as boost that are contained and built in its own source tree. In the case of boost it does this even if the library is never used (due to inline code in include files); again this leads to problems finding the correct dynamic libraries at runtime. Most of the problems in area 2 can be solved by better documentation and improvements to the CMake build for the plugin. However this still leaves us as a hostage to future changes in the Collada DOM build system. I suspect that in the short term that improving the build system and documentation is a better option. However rolling our own parser might prove to be a better long term investment provided that the incorporation of future changes to the Collada schema are not too costly to implement. The effort involved in implementing a parser should not be underestimated. The Collada DOM's XML schema is extensive and complex. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thoughts on a non Collada DOM based Collada plugin
Hi Robert, Boy you spot everything that come and goes :-) :-) Something that I found interesting about the quick XML parser code was that being done in C++ it was much more convenient to use than libxml2, when I ported Present3D across from being libxml2 based to osgDB/XmlParser based the code ended smaller and more readable. Yeah, I once wrote a small C++ wrapper around libxml2 because I found it cumbersome to use, also based on nodes in a tree like yours and it made the user code much easier to read. I totally get what you're saying. Conforming to "Specs" is an issue, but I don't think it need be a big issue for reading as you can either read the data problem or you can't. Writing out con-formant .dae will be hard to police though. I guess we could use Collada DOM to test out the files for conformance during development and maintenance. I agree. Getting COLLADA support out of the box would be great as right now everyone has to jump through hoops to get COLLADA support and this only reduces the number of end users that will be using COLLADA as an interchange format. So by being awkward to build and maintain builder code against the COLLADA DOM is harming it's cause as much as it is promoting it. I agree. So, anybody have the time to do it? :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thoughts on a non Collada DOM based Collada plugin
Hi Robert, Robert Osfield wrote: Hi JP, On Wed, May 6, 2009 at 2:44 PM, J.P. Delport wrote: Can a known working version of the DOM not be included in the OSG code tree or as an external reference to a copy on the OSG server? Then the matching between plugin code and DOM stops being a documentation issue. The Collada DOM has a Sony license that requires distribution of the documentation has to be done along with the source code. This means that it's a huge payload for any OSG users trying to download the source. Basically it's no go. Thanks Sony... Even if there wasn't the licensing barriers I'm not sure the code base is something that we'd want to take on as something that we maintain. Yes, I was not thinking of maintaining our own branch but merely making snapshots of the versions we know works with the plugin code at a certain OSG revision. I was hoping a user could get known matching plugin/DOM code with a single checkout, ah well... jp Robert. -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thoughts on a non Collada DOM based Collada plugin
Hi JP, On Wed, May 6, 2009 at 2:44 PM, J.P. Delport wrote: > Can a known working version of the DOM not be included in the OSG code tree > or as an external reference to a copy on the OSG server? Then the matching > between plugin code and DOM stops being a documentation issue. The Collada DOM has a Sony license that requires distribution of the documentation has to be done along with the source code. This means that it's a huge payload for any OSG users trying to download the source. Basically it's no go. Even if there wasn't the licensing barriers I'm not sure the code base is something that we'd want to take on as something that we maintain. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thoughts on a non Collada DOM based Collada plugin
Hi J-S, On Wed, May 6, 2009 at 2:39 PM, Jean-Sébastien Guay wrote: > Yeah, well now that you've committed an XML reader into osgDB for Present3d, > this should be less of a pain that it would have been before I guess... :-) Boy you spot everything that come and goes :-) I was waiting to announce moving Present3D from it own repository into the core OSG once I had completed some more background work... but subversion tells all the details. I wrote the XML parser to remove the Present3D dependency on libxml2, it is just a days work, so it's very simple, but up to the needs of Present3D. The XML parser I wrote as it stands won't scale well to big source files yet, and it doesn't provide error checking, handling of different encodings etc, but it's a concrete start, it does show that the tasks of xml parsing needn't being hugely complicated. It should be possible to extend the parser code to scale up to the needs of other libs, and I'd suggest extend it on a need be basis. Something that I found interesting about the quick XML parser code was that being done in C++ it was much more convenient to use than libxml2, when I ported Present3D across from being libxml2 based to osgDB/XmlParser based the code ended smaller and more readable. > I imagine the hardest part would be to make sure it conforms to the spec. > Getting basic reading shouldn't be that hard. Though I'll let others more > familiar with it comment on this. Conforming to "Specs" is an issue, but I don't think it need be a big issue for reading as you can either read the data problem or you can't. Writing out con-formant .dae will be hard to police though. I guess we could use Collada DOM to test out the files for conformance during development and maintenance. > It would be a great new feature though, as the constant build problems with > the dependencies have always been what's kept me away from building the > COLLADA plugin, for one. I'm sure I'm not the only one. It would be great to > have this format "for free" (without any external dependencies) because I > expect it would be a good interchange format between modeling tools and OSG. > If animation could work too with osgAnimation that would be excellent. Getting COLLADA support out of the box would be great as right now everyone has to jump through hoops to get COLLADA support and this only reduces the number of end users that will be using COLLADA as an interchange format. So by being awkward to build and maintain builder code against the COLLADA DOM is harming it's cause as much as it is promoting it. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thoughts on a non Collada DOM based Collada plugin
Hi, Jean-Sébastien Guay wrote: Hi Robert, I'm not familiar with the Collada format itself, rather I have always just been a maintainer of the OSG that relies on others for development and support of the Collada plugin, but I do wonder just how much value we get from using the DOM rather than rolling our own xml parsing. Yeah, well now that you've committed an XML reader into osgDB for Present3d, this should be less of a pain that it would have been before I guess... :-) I imagine the hardest part would be to make sure it conforms to the spec. Getting basic reading shouldn't be that hard. Though I'll let others more familiar with it comment on this. It would be a great new feature though, as the constant build problems with the dependencies have always been what's kept me away from building the COLLADA plugin, for one. I'm sure I'm not the only one. It would be great to have this format "for free" (without any external dependencies) because I expect it would be a good interchange format between modeling tools and OSG. If animation could work too with osgAnimation that would be excellent. Here's to hoping, Can a known working version of the DOM not be included in the OSG code tree or as an external reference to a copy on the OSG server? Then the matching between plugin code and DOM stops being a documentation issue. jp -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thoughts on a non Collada DOM based Collada plugin
Hi Robert, I'm not familiar with the Collada format itself, rather I have always just been a maintainer of the OSG that relies on others for development and support of the Collada plugin, but I do wonder just how much value we get from using the DOM rather than rolling our own xml parsing. Yeah, well now that you've committed an XML reader into osgDB for Present3d, this should be less of a pain that it would have been before I guess... :-) I imagine the hardest part would be to make sure it conforms to the spec. Getting basic reading shouldn't be that hard. Though I'll let others more familiar with it comment on this. It would be a great new feature though, as the constant build problems with the dependencies have always been what's kept me away from building the COLLADA plugin, for one. I'm sure I'm not the only one. It would be great to have this format "for free" (without any external dependencies) because I expect it would be a good interchange format between modeling tools and OSG. If animation could work too with osgAnimation that would be excellent. Here's to hoping, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Thoughts on a non Collada DOM based Collada plugin
Hi All, To me it's looks like we are consistently getting a lot more support queries about the Collada plugin than any other our plugins. Build problems are rampant, and alas there isn't that much we can do about it directly. The Collada DOM does cause lots of problems for us, and they are problems that hasn't got fixed as time has moved on, at best one problem has been solved only to replaced by others. Collada DOM has always been troublesome, and it looks like it always will be. I'm not familiar with the Collada format itself, rather I have always just been a maintainer of the OSG that relies on others for development and support of the Collada plugin, but I do wonder just how much value we get from using the DOM rather than rolling our own xml parsing. The vast majority of our other plugins implement their own ascii/binary file parsing and we're able to maintain them just fine. It is of course more work for us to implement the file reading/write in the short term so it'd be a case of short term pain for long term gain. Thoughts on how much work this might be to do? Thoughts on what features of the Collada DOM that are invaluable/hard to replace? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
