On Sunday 26 December 2004 09:28, James Turner wrote: > On 26 Dec 2004, at 00:37, Curtis L. Olson wrote: > > What did I say that was incorrect? If I've missunderstood > > something about plib/ssg I'd appreciate being corrected. If > > modeling is still done in blender/ac/multigen/whatever, > > then you need a conversion path to plib. That means going > > through one of the existing loaders no matter how you > > approach it. Using .ssg doesn't gain you anything in terms > > of rendering quality or features since you have to pass > > through a higher level format anyway. The only thing .ssg > > gives you is potential model load performance increases, > > although I've never seen any comparison benchmarks ... If > > you do get a performance increase, then perhaps we could > > have some util that converts to other formats to .ssg on the > > fly ... so you pay a price when you first load a new model, > > but after that, for each subsequent run of the application, > > you can load the .ssg format. > > > > We just need to handle this in a way the doesn't send us > > down a one way .ssg street. > > What it means is that the MAX / Blender exporters for .ssg > need to be linked against PLIB, but so what? That's not > difficult (that I can see). And the core issue is that it's > easier to do the selective mapping of modeller features > (nurbs, meshes, materials, animations, whatever) to renderer > features inside that modeller's exporter API, which invariably > makes all the data available in sensible, documented ways. The > exporter becomes code that builds a PLIB scene graph by > traversing the modeller's data, and then saves that graph. > > One catch is that the Blender exporter would have to be a > compiled plugin, not a Python script (unless Norman is sitting > on a Python-wrapper for PLIB :-), but that will still be less > coding, and more maintainable, than trying to deal with the > entirety of a Blender file (or other high-level format) inside > a PLIB loader. Which, as you pointed out, is *exactly* why > many of the PLIB loaders have limitations. > > Again, this is exactly analogous to the 2d art pipeline - > people edit in a rich format like Gimp / Photoshop, but no one > would suggest trying to load those formats directly in a game > (layers, paths and all); you keep your original files around > some place, and export / Save As to whatever simple format > suits your needs, whether it be PNG or RGB or JPEG. > > Anyway, I'll go back to lurking now. > James
Simply having a loader for more capable model formats, such as the native Blender format, .3DS, .OBJ or whatever isn't going to add new features to the renderer and won't improve the appearance of the models. When the renderer supports more features, such as multiple texture mapping, per-face mapping, scope mapping, trim-curves etc. it would be necessary to use a new model format but until then it would just be a case of storing info that's unusable. Having said that, I don't know exactly what the capabilities of the renderer are - afaik they seem to match the capabilities of the .AC format atm i.e. single texture map per object, smooth or flat shading, transparency and a range of lighting characteristics. LeeE _______________________________________________ Flightgear-devel mailing list [email protected] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
