> > > <init_from>../../../environ%20project/environ/terraindata/vtp-apps-data- > > and- > > plantlib/buildingmodels/cement_block1_256.jpg</init_from> > > > > C:\Temp\colladatest\models>osgviewer brantholme.dae > > processTexture(./material_effect-sampler) > > Warning: could not find file > > "C:/environ%20project/environ/terraindata/vtp-apps- > > data-and-plantlib/buildingmodels/cement_block1_256.jpg" > > Time to load = 0.0273278 > > > > I guess it is back to reading RFCs again to see if % encoding should be > > being done/undone. > > > > It looks like that the % encoding of the space character is done when the > xml file is being written from the database. > > I would expect the decoding to take place symmetrically when the database > is > initialised from the xml file. But it looks like this does not happen. > > I have had a look through DOM code to see where this all happens but I > cannot find it. > > > Marcus, or anyone who knows about the layout of the code, can you give me > a > clue where I should be looking. >
I think I may have found the right place now. daeResolverType::memoryToString(daeChar* src, daeChar* dst, daeInt dstSize) changes spaces to %20 daeResolverType::stringToMemory(daeChar* src, daeChar* dstMemory) just copies the string unchanged. Roger _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
