Hi Sukender & Robert, Just to emphasise what has already been said really, but we have literally 10's of thousands of 3DS models for various manufacturer's products, so whilst I accept there are significant limitations with 3DS structure now compared to more modern formats, the sheer size of the back catalogue means it will be around for a long time to come. Hence I think support for 3DS is important within OSG.
Robert's comments about the 3DS reader supporting streams is vital for us now with our web based catalogue viewing system. In regards to the ability to write a 3DS file, this would be fantastic. If help/assistance/testing is wanted I'm sure I'd be able to find some time. If you need sample models these could probably be provided as well. In regards to Collada, my recent excursions into conversions from 3DS to collada via osg has had mixed results. Still investigating (when time permits) but there is certainly an issue in validity of the collada file produced if the node name of the scene graph has spaces, also issues encountered with materials. However, these are for another thread. But I tend to agree that even with the teething problems, Collada does look to be very powerful. Is anyone looking at the new Autocad format - FBX? Just wondering whether anyone considering a Reader/Writer for it? Looked at trying to take an OSG collada file and convert it to FBX via Autocad's converter, but it failed. End of memory dump :-) Kind regards Neil. ---- Robert Osfield <[email protected]> wrote: > Hi Sukender, > > On Fri, Aug 21, 2009 at 8:35 AM, Sukender<[email protected]> 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 > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
