Yeah, OSG uses DOM 2.1 now. There are no pre-built binaries for the DOM
anymore. You'll need to build it yourself, which is fairly simple as
long as you have a recent version of Visual Studio (2005 or 2008).
Instructions are available on the DOM wiki:
Yeah, I had the same problem. I don't think the Collada plugin's CMake
setup is very good right now unfortunately. The big problem here is that
linking the release version of the DOM into the debug version of OSG
won't work. Not on Windows anyway. Same goes for trying to link the
debug DOM into
Yeah that's pretty weird. I doubt this is a result of upgrading to DOM
2.1. The Collada plugin has probably always had these problems, though I
could be mistaken.
Robert Osfield wrote:
2008/5/13 [EMAIL PROTECTED]:
I submitted a fix to osg-submissions. Diff (against trunk) is below for
I just tried this and I didn't have any problems. I'm on Ubuntu Gutsy.
Here's (roughly) what I did.
# DOM setup
sudo aptitude install libxml2-dev libpcre3-dev libboost-filesystem-dev
svn co dom
make
sudo make install
# OSG setup
sudo aptitude install cmake
svn co osg-trunk
svn co
Actually I can reproduce this now. I just wasn't calling it the same way
you guys were. I was giving the output file a full path, and in that
case the conversion works.
This is likely a simple error in the way the plugin converts URIs to
file paths (which, incidentally, doesn't need to be
I submitted a fix to osg-submissions. Diff (against trunk) is below for
anyone who wants it now.
Steve
===
--- src/osgPlugins/dae/ReaderWriterDAE.cpp(revision 8313)
+++ src/osgPlugins/dae/ReaderWriterDAE.cpp(working copy)
Now I've got the dom built, but now the install apears to be playing up.
Sorry, there's a bug in the make install rule that causes it to not work on Linux unless
you're running from an svn checkout. I fixed the bug in the trunk and it'll go in the
next release, but for now you can comment out
Was waiting to see if Steve had any anomalies show up on his end.
Sorry, I know I said I'd look at this over the weekend but I didn't get
a chance. I'll definitely test this sometime this week.
Robert, I would move forward with merging Garrett's patch into the OSG
trunk. If I have changes
get it
there.
I'm not registered to that list, but I'm guessing I can go through the archive
to find the patch. If I can't get it through the archive it'd be nice if you
could email it to me at [EMAIL PROTECTED] (x = steven_thomas, y =
playstation.sony.com). I'll be sure to build any changes I
Hey Garrett, thanks a ton for this work. I'd been planning to bring OSG
up to DOM 2.0 myself at some point, but it looks like that's taken care
of with your patch. Thanks!
Does your patch bring platforms other than Mac up to DOM 2.0 also? I
vaguely recall that the OSG Collada plugin had
I have not tested writing so we may have to add a nativeToUri utility call(
found in daeUtil.h) for encoding to a URI any files with spaces and special
symbols.
In DOM 2.0 the DAE methods that work with document names (like DAE::open/load,
DAE::write/save, etc) work with file paths just
I'll see if they can also give it a whirl for you.
That's probably not necessary. If you and I each do our best to test the
platforms we have access to that should be enough. If someone's having a
problem on a different platform they can contribute a patch.
I think the daeRMaterial that I
Hi Eduard, unfortunately I don't have any tips for the error you're
getting. A couple months ago I tried getting OSG to use the DOM trunk
code for its Collada support, and other than a few easily fixable
compiler errors it worked fine. I didn't get any .so load errors. I was
testing with
Ok, I'm still a bit confused about whether the Collada plugin is
supposed to use the development version of the DOM or the last stable
release (1.3 from 30 March 2007). It'd be more sensible to use the last
stable release of the DOM, but looking at the CMakeLists.txt file leads
me to believe
Which version of the OSG are you interested in?
I'm interested in whatever versions are going to be affected by changes
I make to the development version of the Collada DOM. What I'm concerned
about is that I'll make a breaking change in the DOM and then the
Collada plugin for OSG will no
Yes, it's the same issue. I'll take a look at the Collada plugin for OSG
and try to get it fixed.
Steve
Gerrick Bivins wrote:
I'm not sure if this is related but I get the following error when
attempting to compile the dae plugin:
/usr/bin/c++ -Dosgdb_dae_EXPORTS -fPIC
I fixed the Linux build of the Collada plugin and submitted the fixed
files to the osg-submissions list. If that wasn't the right procedure
for submitting a patch let me know.
The fix requires the latest development version of the Collada DOM,
including some code I just submitted today. I
I'm trying to reply to an issue raised by someone regarding Collada
support in OSG:
http://sourceforge.net/forum/forum.php?thread_id=1899938forum_id=531263
I made some changes to the Collada DOM that may require a few tweaks in
client applications such as OSG's Collada plugin. Dilian reported
Frankly it's stupid that the Collada DOM can't save or load files
properly using native file system paths. Just in the last week I fixed
this in the latest DOM code in the svn repo on SourceForge. Now there
are some general file path -- URI conversion functions in the DOM, and
the DAE
1. Changing the collada build files (VC8 project file in my case) to
differentiate the collada release and debug build by library name not by
directory.
I understand this is a problem for some people. The last official
release of the Collada DOM (1.3) uses '_d' to differentiate debug and
20 matches
Mail list logo
