Hi Robert, I must admit I didn't test istreams. I'll do that testing. Do you think testing with a ifstream is enough, or must I test with HTTP (since I'm not sure I compiled with curl)? I'll also fix the warnings I found (most of them are "conversion from X to Y: possible loss of data").
Making lib3DS a subproject of the 3DS plugin sounds fine to me. And as a final note, I must say I don't have to export a true and full-featured scene graph, but a few simple objects. This is why the 3DS suits that goal with older software. I'll tell you about istream reading soon I hope. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ----- Mail Original ----- De: "Robert Osfield" <robert.osfi...@gmail.com> À: "OpenSceneGraph Users" <osg-users@lists.openscenegraph.org> Envoyé: Vendredi 21 Août 2009 10h22:42 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: [osg-users] 3DS loader revisited? Hi Sukender, On Fri, Aug 21, 2009 at 8:35 AM, Sukender<suky0...@free.fr> wrote: > Of course, my goal is to work on the 3DS reader/writer without loosing > functionality. Actually, I simply tried to replace the "old" lib3DS with the > new one... and it was very straightforward: some calls were renamed, some > others changed a bit... One areas of significant deviation was for the support of reading from istreams, in your work can you still read from istreams? The ability to read from istream enables reading from http via the curl plugin. > Anyway I could load my 3DS models exactly the same way I did before. I could > even remove a tiny limitation (meshes were taversed by name, which can be > dangerous if two identical names exist. That should not, but now it's okay). > Everything worked like a charm! I guess some testing would be a good idea, > but it seems there was no functionality loss. > Side note: I had a few compilation errors using VC9 in the lib3DS, because of > implicit conversions from void* to SomethingElse*. I made those conversions > explicit and gave the fix to the lib3DS patches tracker. I had to make a number of changes to fix the pedantic warnings emitted by g++ 4.x. This might need to be rolled in as well. > About linking, I guess putting lib3DS as a static library could be a good > idea, even if my testing was with direct inclusion of source files. I'll work > on it and submit VC (8? 9?) binaries I guess... or may I keep the files as > they are in a first time? We could possibly just include the source to lib3ds as a subdirectory of the 3ds plugin, as CMake allows us to manage the source directories better than the old days of trying to support both VS6 and Makefiles. > About the writer, well, we have some customers with old software... Moreover > they're absolutely not 3D/vis/sim-oriented, so there are few supported > formats. I agree 3DS is very poor, but it is a non-flexible format (as some > XML-based formats could be); and as a non-flexible format it can be loaded > exactly the same way on various (old) software. > What kind of output format would you use else? Collada? A major problem with 3ds is that because there is no official/public specification and lots of different attempts at implementations the files generated can be very patchy in the their consistency. 3ds is not likely to map a general purpose scene graph too well either, but this issue applies to most writers - a general purpose scene graph is far to flexible to be easily mapped by the constraints of most formats. Collada has to be one of the best for being able to map things, but even it is a long way from perfect. Robert. _______________________________________________ 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
