> 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 had to add the uriToNative may need some > looking at to see if it's not needed. I'm pretty sure we need uriToNativePath in this case. We're talking about loading texture images referenced via the <image><init_from> element right? <image><init_from> is a URI, so you'll need to convert it to a file path if you want to load it as a file from disk. I was just saying writing a document with an OS file path containing spaces or whatever should work fine, since the DAE class methods pass all document names through nativePathToUri first. Steve Garrett Potts wrote: > Hello Steve: > > Thank you for the comments. I'll pound the ingest side of things as > much as I can. I will start windows build this week after I finish > some OSG 2.4 upgrades on MAC and test the dae some more. I don't have > any other OS's than that at my disposal. I do know some who use > SUSE. I'll see if they can also give it a whirl for you. > > I think the daeRMaterial that I had to add the uriToNative may need > some looking at to see if it's not needed. The way it's currently > done I had to add it in there for files that contained spaces had the > %20 in them and was being sent to the osg:readImage . For the port I > used y'alls documentation for porting and did a one-to-one translation > and it worked great. > > > Take care > > > Garrett > > On Apr 29, 2008, at 3:17 PM, [EMAIL PROTECTED] wrote: > > >>> 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 >> fine. They're converted to URIs internally using the nativePathToUri >> function. It's when you're working specifically with URIs (in the >> DOM this is usually done via the daeURI class) that you need to >> worry about file path <--> URI conversion. >> >> >>> The testing stage for the modification is in it's infancy and needs >>> more testing before we can probably say its valid. >>> >> My intent was to do testing to make sure the plugin at least runs on >> a few different platforms: Windows XP, Mac OS X, and Ubuntu, since >> that's what I have easy access to. I don't have a plan in place for >> testing the actual features of the plugin though. >> >> >>> I'll build for the MAC. Do you know if there is support to build >>> universal. Right now I build on a ppc and then the intel then I >>> lipo them together. >>> >> Yes, building a Mac universal binary is easy: just add "arch='x86 >> ppc'" to the make command line. More info in the DOM's make build >> readme: >> http://collada-dom.svn.sourceforge.net/viewvc/collada-dom/trunk/dom/make/readme?view=markup >> >> Steve >> >> >> Garrett Potts wrote: >> >>> Hello Steve: >>> >>> Glad I can help some :). >>> >>> I plan on doing the windows build as well but have only done the MAC. >>> I have also only tested with a few Google Collada models so I don't >>> think I hit everything. Would need others to pound it to see if we >>> missed anything. For instance, the texture material load requires >>> us >>> to now unencode a uri to a local native name and I am not sure if >>> that >>> is used in other parts of the dae plugin. 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 the reader I saw some conditionals for WIN32. I only made mods to >>> what I could test here. The testing stage for the modification is in >>> it's infancy and needs more testing before we can probably say its >>> valid. >>> >>> The tgz file I sent to the submissions is the modifications I have so >>> far and it for the ingest testing for some of the dae models in >>> google >>> seems to work and I have not seen any anomalies yet. >>> >>> >>> Let me know when the DOM 21 is tagged. I'll build for the MAC. Do >>> you know if there is support to build universal. Right now I build >>> on >>> a ppc and then the intel then I lipo them together. >>> >>> >>> Take care >>> >>> Garrett >>> >>> On Apr 29, 2008, at 2:20 PM, [EMAIL PROTECTED] >>> wrote: >>> >>> >>> >>>> 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 different build >>>> setups >>>> for different platforms, so there might be multiple places where >>>> changes >>>> need to be made to get all the platforms up to DOM 2.0. >>>> >>>> One other thing. Due to some problems that were discovered in DOM >>>> 2.0 >>>> I'm doing a 2.1 release sometime in the next few days. This release >>>> doesn't contain any breaking changes, so I think all we'll need to >>>> do is >>>> update the DOM lib name to '21' instead of '20'. >>>> >>>> Steve >>>> >>>> Garrett Potts wrote: >>>> >>>> >>>>> Hello Robert: >>>>> >>>>> I wanted to tar up the dae and call it maybe dae2 for the collada >>>>> 2.0 >>>>> tag release they have. Do you want me to send to you or send to >>>>> the >>>>> osg-submissions? >>>>> >>>>> >>>>> Take care >>>>> >>>>> Garrett >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > 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
