Hi Robert, Well I had never an issue using Collada-DOM (v2.2)! I spotted there is a build system for 1.4 and one for 1.5 (Using 1.4 for osgDAE)... I'm terribly sorry about not helping you... There may be system-specific notes in some file??? Anyway, I don't see a solution other than mailing osg-users and ask for those who use the same system as you. Cheers,
Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ----- "Robert Osfield" <[email protected]> a écrit : > Hi Sukender, > > Thanks for break the submission into parts, this helps a lot. I have > begun reviewing the changes, but on doing my first test build I > realised that I don't yet have COLLADA installed on my present dev > system... it's installed on one of my other systems on so I may fall > back to this later on. > > I decided to get this current system up to speed so I just pulled > down > the COLLADA DOM 2.2.zip from sourceforge and alas it doesn't compile > under Linux due to missing COLLADA header files. I've looked at the > sources but haven't yet worked out how to fix these build issues. > The > build issues looks like they have mixed 1.4 and 1.5 version headers > and messed it up. By default the build is trying to build against > the > 1.4 headers. > > Any ideas which version might be working? > > Every time I try to work with the COLLADA DOM I come away regretting > the experience, I can't help but feel that it was a big mistake > adopting it in the first place, rolling our own parser would have > been > more productive... > > Robert. > > On Mon, Jan 17, 2011 at 10:08 PM, Sukender <[email protected]> wrote: > > Hi Robert, > > > > Please find the submission in 4 parts, without the UTF8 changes > (I'll change it to a runtime option). > > Hope this suits your request. > > Cheers, > > > > Sukender > > PVLE - Lightweight cross-platform game engine - > http://pvle.sourceforge.net/ > > > > ----- "Sukender" <[email protected]> a écrit : > > > >> Hi Robert, > >> > >> > I now believe the right thing to do would be to break the > >> submission > >> > into separate parts so that each set of new features are checked > in > >> > separately. This will make it easier to trace changes and any > >> > regressions, as well as make it possible for me to merge the > less > >> > controversial changes faster. Could you break the submission up > >> into > >> > parts based on functionality for me? > >> > >> I was afraid you would say that! Well... certainly. I'm not sure > >> *when* but I'll try ASAP. > >> > >> > >> > > Well, about UTF8, I guess those have same encoding as > filenames: > >> > > - nodes names (some readers put the full path as node name for > >> the > >> > root) > >> > > - geometries (and RigGeometries and MorphGeometries) > >> > > - animations and channels names > >> > > > >> > > Of course, this is only my feeling, and you may disagree. > >> > > If so, may I suggest to turn the proprocessor test into a > >> standard > >> > "if()" testing a readerwriter option? We could have > >> > daeGeometriesNamesUseCodepage / daeAnimationsNamesUseCodepage, > or > >> > such. However, if the same is possible with node names, I > suggest > >> to > >> > interpret node names the same way we do for filenames. > >> > > > >> > > Thoughts? > >> > > >> > This isn't quite the specific question about the code that I > >> > asked.... > >> > but asking wider questions... > >> > > >> > Personally I don't have an experience with UTF8. Pushing > changes > >> > from > >> > filenames down on to general OSG names is a much wider issue > that > >> we > >> > can't deal with prior to 3.0 release. > >> > >> Of course. I personally have to deal with string translations & > >> encoding, but you're absolutely right about not trying anything > before > >> 3.0. > >> > >> > >> > As a general note, I really dislike having #ifdef code paths in > the > >> > OSG codebase as it'll make the code much less maintainable and > more > >> > error prone. If we can do stuff at runtime then this is a > better > >> way > >> > of doing it. > >> > >> Ok. As said before, I guess I'll use plugin options, or such. > >> > >> More generally speaking, do you think about removing the #ifdef > >> everywhere and have a runtime way of handling encoding? > >> Even if slightly off-topic, I can bring you a few little > hints/info > >> from my experience: > >> - Fixed length encodings: UCS-2 (16 bits), UTF16 (synonym: UCS-4) > and > >> 7-8 bits encodings (ASCII, latin-1, etc.) > >> - UTF (8-16-32) cover all possible characters, contrary to all > others > >> (noticeably UCS-2). > >> - Thus, you can't have an unique FIXED-LENGTH encoding for > multiple > >> languages, except with 32 bits (UTF32 / UCS-4). > >> - UTF16 is often misinterpreted as UCS-2 (UCS-2 is a subset). > >> - An ASCII string is a valid UTF8 string, but not an UTF16 string > (of > >> course). > >> - UTF-8 is generally takes 3 bytes for some languages (Chinese, > >> Japanese or Hindi), but "This happens for pure text, but rarely > for > >> HTML documents." (Source wikipedia). > >> - UTF-8 can be stored in an standatd "narrow" std::string. > >> > >> So you have the choice between: > >> 1. Having a 32 bits encoding. Drawback: too heavy. > >> 2. Having a fixed-length encoding (8 or 16 bits). Drawback: need > to > >> change encoding when switching language. > >> 3. Using UTF16. Drawback: confusion with UCS-2, not compatible > with > >> ASCII, and generally used with "wide" std::wstring. > >> 4. Using UTF8. Drawback: a bit heavy for some languages. > >> > >> So my personnal choice *FOR MULTI-LANGUAGES* apps (and the choice > of > >> those who wrote "boost.locale" ;) ) is to use UTF8 everywhere for > the > >> general case, or use 7/8-bit encoding for situations where memory > >> really-really-really-matters, or for single-language apps. > >> > >> I would then recommend to keep OSG use "narrow" std::string, and > have > >> a flag somewhere (Some singleton? Registry? > ReaderWriter::Options?) > >> which says if filenames use a (8-bit) code page or UTF8. Having > "wide" > >> UTF16 overloads may be possible too (even if conversion functions > are > >> enough). Thoughts? > >> > >> See http://cppcms.sourceforge.net/boost_locale/html/tutorial.html > , > >> section "Recommendations and Myths" > >> > >> Sukender > >> PVLE - Lightweight cross-platform game engine - > >> http://pvle.sourceforge.net/ > >> _______________________________________________ > >> osg-submissions mailing list > >> [email protected] > >> > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > > > _______________________________________________ > > osg-submissions mailing list > > [email protected] > > > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > > > > _______________________________________________ > osg-submissions mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
