Re: [Flightgear-devel] are we switching from blender to ac3d?
David Megginson said: On Sat, 25 Dec 2004 16:23:29 -0600, Curtis L. Olson [EMAIL PROTECTED] wrote: .ssg format is basically a binary memory dump of the internal ssg structures. This has some advantages within plib-based applications, but it would be tough to build an exporter from a non-plib application. It would be a lot simpler to build a plib-based converter, but then you'd need to be able to read the source format into plib anyway. .ssg is extremely non portable, and would make it very difficult for people to edit the models with any non-plib based modelers, and I'm not aware of any plib-based modelers that are far enough along to be useful. I think we would do better to stay with high level 3d formats. I know that no one particularly loves VRML, but it is text based (like AC3D) and open. As long as we're just doing textured and tinted meshes, with the more complex stuff (like animations) in external XML files, is there any good reason *not* to go with VRML, especially since we can compress the files on disk with gzip? This sounds interesting, I'm just not familiar enough with it. What would be involved in making this change? Curt's idea of storing .ssg in a cache fashion also sounds interesting. Sort of along the same theme I'm wondering if we could gain some benifit by caching binary representations of other XML config files (like 3d cockpit animations, etc). The amount of xml processing during intialization is becoming quite large in some cases. In reference to the original question on this thread, should we as a project be maintaining blender (or MAX, etc) _sources_ regardless of which direction we take? If a given model was developed in blender, shouldn't we be providing blender sources in a _base package source_ distribution so that future changes are also handled by blender users? This particular problem as I see it is that once an exported to ac3d model is commited to cvs with changes from an ac3d user, then the blender users are nolonger able to contribute to that model. Of course the flip side to this argument is that if we commit to providing blender sources and requiring blender source modifications (which itself is fraught with blender version issues), then we effectively commit to the blender format for that model, regardless of which format FlightGear actually loads. Would VRML give us true modeler portability? Can ac3d (or whatever closed source modeler) import a VRML model and have all features intact, and then export it back to VRML in a way that a blender user could import the same model and see the same changes? Can blender even import it's own exported VRML and have all the features intact? Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are we switching from blender to ac3d?
I just wanted to experiment with VRML models a little. I've had no luck loading one as yet (VRML 1.0 or 2.0) Does FlightGear/SimGear/plib have to be compiled with any extra options to support VRML or is it just unsupported right now? ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are we switching from blender to ac3d?
Dave Martin wrote: I just wanted to experiment with VRML models a little. I've had no luck loading one as yet (VRML 1.0 or 2.0) Does FlightGear/SimGear/plib have to be compiled with any extra options to support VRML or is it just unsupported right now? I think that plib does have some sort of vrml loader, but I don't think it's very advanced or very capable (based on what I've heard.) If you are dealing with a plib based app, you probably want to consider converting the model to a better supported format. For what it's worth, this isn't necessarily a knock on plib. 3d formats are hard, and the line between geometry and functionality get's blury, and an application always needs to communicate more than plain geometry. So everyone is tempted to push more information into the 3d format, but this is hard to do in a non-application specific way. Things like vrml and openflight are an *attempt* to encapsulate a lot of functionality into the format but they aren't always as successful, or generic as we'd like them to be. It's a very difficult problem ... FlightGear has xml wrappers on top of our models, but that means you have to hand code things like LOD and animations and can't do it in the modeler ... tough problem... Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are we switching from blender to ac3d?
On December 27, 2004 03:52 pm, Ampere K. Hardraade wrote: On December 27, 2004 02:27 pm, Jim Wilson wrote: Would VRML give us true modeler portability? Can ac3d (or whatever closed source modeler) import a VRML model and have all features intact, and then export it back to VRML in a way that a blender user could import the same model and see the same changes? Can blender even import it's own exported VRML and have all the features intact? 3D Max Studio can't import VRML. I don't know about other modellers though. Correction: appearently, it can import VRML. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are we switching from blender to ac3d?
On Mon, 27 Dec 2004 19:27:03 -, Jim Wilson [EMAIL PROTECTED] wrote: I know that no one particularly loves VRML, but it is text based (like AC3D) and open. As long as we're just doing textured and tinted meshes, with the more complex stuff (like animations) in external XML files, is there any good reason *not* to go with VRML, especially since we can compress the files on disk with gzip? This sounds interesting, I'm just not familiar enough with it. What would be involved in making this change? The same thing that is involved in switching to any format -- writing a VRML 1.0 importer for plib (or directly for FlightGear). The advantages of VRML are a) *every* 3D modelling program can import and export it; and b) it's text-based, so it's easy to debug problems and to generate VRML models or components using scripts. VRML was meant to be as big as HTML, creating a new, 3-D web browsing experience. That was total BS, of course -- I mean, do you really want to use a 3-D interface to bid on eBay or check movie listings? -- and to try to recover from the 3-D-for-the-web failure, llater versions of VRML added actions and all kinds of extra stuff that few ever implemented properly; it was also eventually XML-ified. The original, text-based, non-XML VRML 1.0, which is fairly simple, should have all we need for textured meshes, however. There is currently a VRML 1.0 importer in plib, but it doesn't quite work (it messes up on textures, if I recall correctly). Having a VRML 1.0 importer that worked as well as the AC3D importer would make things very easy -- just tell people to save as VRML no matter what modeller they're using. Curt's idea of storing .ssg in a cache fashion also sounds interesting. Sort of along the same theme I'm wondering if we could gain some benifit by caching binary representations of other XML config files (like 3d cockpit animations, etc). The amount of xml processing during intialization is becoming quite large in some cases. The trick is coming up with something that loads faster than the XML, or the caching is pointless. Out in the wild, people have tried and mostly failed. Most of the overhead, I think, comes not from the XML parsing but from opening and closing so many tiny files, so 100 pre-compiled binary files will take just about as long to load as 100 text XML files -- perhaps if you could dump everything into a single file, load times would improve. When I turn on debugging output, most of the load time does not seem to be reading config files, though. If a given model was developed in blender, shouldn't we be providing blender sources in a _base package source_ distribution so that future changes are also handled by blender users? Yes -- give me a place to put my models, and I'll gladly make the Blender source available. Right now, it's in a temporary directory for anyone who wants it: http://www.megginson.com/Private/Models/ Of course the flip side to this argument is that if we commit to providing blender sources and requiring blender source modifications (which itself is fraught with blender version issues), then we effectively commit to the blender format for that model, regardless of which format FlightGear actually loads. You have to distinguish between the maintainer and contributors. As long as I'm maintaining, say, the J3 Cub model, any contributors should make their changes to the Blender source, since Blender is my chosen format. If a different maintainer takes over (or forks the model), then that maintainer may choose to keep the source in 3DS, AC3D, or some other format. I don't think that we should dictate to people what modelling program they have to use, though, obviously, they'll do better attracting contributors if they use an Open-Source one, or at least a cross-platform one. Would VRML give us true modeler portability? Can ac3d (or whatever closed source modeler) import a VRML model and have all features intact, and then export it back to VRML in a way that a blender user could import the same model and see the same changes? You will lose information that's useful to the modeller, like, say, object grouping. VRML is good enough for displaying a model in FlightGear, but just about every modeller keeps a lot of extra information around that's useful to the designer, and that will be lost. If a new maintainer is taking over and wants to switch to a different modelling program, VRML is a good way to get the basic mesh objects and textures in there, but then there will be some work regrouping, etc. Can blender even import it's own exported VRML and have all the features intact? No, because VRML just stores the basic mesh objects and textures, not all the other Blender information (which FlightGear doesn't use either, by the way). It's somewhat similar to saving as RTF and then reloading into Word or OpenOffice. All the best, David -- http://www.megginson.com/
Re: [Flightgear-devel] are we switching from blender to ac3d?
On Mon, 27 Dec 2004 15:52:01 -0500, Ampere K. Hardraade [EMAIL PROTECTED] wrote: 3D Max Studio can't import VRML. I don't know about other modellers though. Are you certain? Even the dinky little shareware modellers usually support VRML 1.0 import and export -- it's like a spreadsheet not importing CSV. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are we switching from blender to ac3d?
On Monday 27 Dec 2004 21:11, David Megginson wrote: You have to distinguish between the maintainer and contributors. As long as I'm maintaining, say, the J3 Cub model, any contributors should make their changes to the Blender source, since Blender is my chosen format. If a different maintainer takes over (or forks the model), then that maintainer may choose to keep the source in 3DS, AC3D, or some other format. I don't think that we should dictate to people what modelling program they have to use, though, obviously, they'll do better attracting contributors if they use an Open-Source one, or at least a cross-platform one. You will lose information that's useful to the modeller, like, say, object grouping. VRML is good enough for displaying a model in FlightGear, but just about every modeller keeps a lot of extra information around that's useful to the designer, and that will be lost. If a new maintainer is taking over and wants to switch to a different modelling program, VRML is a good way to get the basic mesh objects and textures in there, but then there will be some work regrouping, etc. As I've mentioned, the modifications to the c172p that I made were with ac3d (it's not a hugely powerful modeller but speed of development is good). What exactly will have been stripped out of the model on export to AC3D - Specifically is it groupings or are there other things gone? I'd like to 'port' the design back to .blend if possible to avoid the 'fork'. It appears that the latest version of AC3D maintained the specular / diffuse etc material info. - Not sure whether Blender keeps that on import from AC3D tho. Cheers Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are we switching from blender to ac3d?
On Mon, 27 Dec 2004 21:28:18 +, Dave Martin [EMAIL PROTECTED] wrote: As I've mentioned, the modifications to the c172p that I made were with ac3d (it's not a hugely powerful modeller but speed of development is good). I'm happy to hand over the 172p to Dave or someone else who is willing to take it over and give it a lot of TLC -- it's our default aircraft, so it should look better than it does (i.e. a proper interior with fabrics, door handles, placards, etc.). One thing that Blender loses on AC3D export is reused meshes; for example, I might have 10 objects that all use the same mesh (think knobs or antennas), and in Blender, any change I make to one will appear in all the others; on export, the link is lost, and they're 10 separate objects. As Dave mentioned, specular and emissive colours are also lost on AC3D export (at least the last time I checked), and I have to edit them into the *.ac file by hand after export. Sometimes I also have to rearrange the objects for alpha ordering. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are we switching from blender to ac3d?
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 ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are we switching from blender to ac3d?
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 Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] are we switching from blender to ac3d?
[offlist] On Sat, 25 Dec 2004 19:02:47 -0500, Norman Vine wrote: Excuse me Curt but This is bordering on FUD Exchange formats are designed to capture common information for many different uses; proprietary formats, like PLIB's SSG, are optimized for a single app or library. Even if you (Norm) disagree with Curt's suggestion to avoid formats designed for a single app or library, I'm surprised that you cannot admit that this is something intelligent people can disagree on, rather than accusing Curt (of all people) of spreading fear, uncertainty, and doubt. Excuse me but this is FUD ! SSG is certainly not propriatary in any reasonable man's vocabulary !! The sggestion that FGFS who's native format is SSG would be somehow limited by using the native SSG load function esp. given there is an 'editable' model in the format of the Editor application that created the model is 'bordering' on FUD. FWIW If and when FlightGear exchanges SSG for another internal SceneGraph I would suggest using that SceneGraph's native loaders also ! Perhaps we would all get along better if we only spoke Esparanto outside of our homes also :-) Merry Christmas all, Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are we switching from blender to ac3d?
On Sun, 26 Dec 2004 09:53:49 -0500, Norman Vine [EMAIL PROTECTED] wrote: SSG is certainly not propriatary in any reasonable man's vocabulary !! You need to distinguish open specs from open formats. For example, MSIE is closed source but uses open formats (HTML, CSS, etc.); Open Office is open source but uses proprietary formats (file formats that they developed themselves and no one else uses). I wouldn't bother with Esperanto, but at least I'd prefer a language like English that people other than me use. Anyway, my original point was that whether you agree or disagree, you were being a little loose with the accusation of FUD against Curt. He's making a legitimate point, not trying to mislead people into doubting plib. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] are we switching from blender to ac3d?
David Megginson writes: Anyway, my original point was that whether you agree or disagree, you were being a little loose with the accusation of FUD against Curt. He's making a legitimate point, not trying to mislead people into doubting plib. If you reread my original post you will note I didn't accuse anyone of spreading FUD. I think I chose my wording rather carefully i.e. 'bordering' You may not agree with me but FlightGear would be better recieved if it used more pre-compiled objects and their appropriate loaders. i.e. Just because FGFS is written in 'C++' doesn't mean you have to re run a compiler over the whole source tree everytime you want to use it. What-is-good-for-code-is-also-good-for-data'ly yr's Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are we switching from blender to ac3d?
David wrote: As long as we're just doing textured and tinted meshes, with the more complex stuff (like animations) in external XML files, is there any good reason *not* to go with VRML, especially since we can compress the files on disk with gzip? Do you completely hand edit the XML? Do you plan to keep it that way? All the best, David Bye bye, Wolfram. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are we switching from blender to ac3d?
Curt wrote: I believe the main issue is that whatever format we go with has to have a good plib/ssg loader for it. Yes, if you standardise on one or two standard formats, the PLIB loader will be important. In fact, it seems like all the plib loaders (except for the ad/ssg loaders) have show stopping problems in places. Have you looked at ASE, OBJ and .X (in addition to AC3D)? Also, there is a new *.asc loader. BTW, all 3D models for a forthcoming commercial flight sim have gone through the ASE loader. I am working on animations for it right now. It currently works almost always :-/. The sim is called Battle of Britain 2 Wings of Victory :-/. Curt. Bye bye, Wolfram. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are we switching from blender to ac3d?
Curt wrote: .ssg is extremely non portable, and would make it very difficult for people to edit the models with any non-plib based modelers, and I'm not aware of any plib-based modelers that are far enough along to be useful. ... as modelers, correct. However, PPE is nice as a converter and makes a great tool for anyone making 3D models for a flightsim. Regards, Curt. Bye bye, Wolfram. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are we switching from blender to ac3d?
Norman Vine wrote: Erik Hofman writes: Norman Vine wrote: If someone was to do this I would suggest exporting to the native .ssg binary format :-) If they could fix the .ssg endianness problem in the process I'm all for it. Sounds good :-) [...] Am I missing something here ? Your idea should work. Norman Bye bye, Wolfram. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are we switching from blender to ac3d?
Curt wrote: 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. I think you guys are speaking aside each other. Curt wants to allow different modellers. James OTOH correctly says that the thing professionals do instead is to decide on one modeller, say Blender OR 3DS Max etc, and then write an exporter into their own propriatery format. This is the path suggested both by Kinetix (and probably the other big players in 3D modelling) and by mostgame developers that have done it. So, no standard format is involved. Norman - IMHO correctly - wrote that if you do that, the propriatery should be SSG, since that loads very fast. This is a HUGE thing for a flight sim. I am currently loading ascii files into the sim I work on to make development easy. A plane needs over a second. If you realise that a frame that is 50 ms longer than other frames is EASILY visible, then an ascii format is a factor 20 too slow. I think the first decision that needs taking is whether you want to mainly support say two modellers really well and the others not so well or whether it is a very high priority to support all modellers out there equally well. In the first instance, I support James/Norman's idea of an SSG exporter. Curt. bye bye, Wolfram. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are we switching from blender to ac3d?
On Sun, 26 Dec 2004 17:41:20 +0100, Wolfram Kuss [EMAIL PROTECTED] wrote: Do you completely hand edit the XML? I hand-edit the animations, but eventually, we could look at something more standardized. Do you plan to keep it that way? Since Blender has scripting support, it would be possible to generate the XML animation files from it, if anyone cared enough. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are we switching from blender to ac3d?
On Saturday 25 December 2004 04:48, Jim Wilson wrote: Those using blender, what exactly (if anything) needs to be done to the ac file after exporting it to ac format now? All the models that I've created in blender work without any modifications. I've also tried to let blender export to various other formats that plib can read, with varying success. I don't remember the details but colors were more or less wrong and axes were not as expected. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are we switching from blender to ac3d?
Incidentally; would I be loosing anything if I re-imported the .ac back to Blender? ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are we switching from blender to ac3d?
On Sat, 25 Dec 2004 12:38:53 + Dave Martin wrote: I have noticed that Blender seems to strip specular material settings when exporting to .ac Not sure if this is something I'm doing wrong or an issue with Blender. Neither. Blender strips them out because the ac3d file format doesn't support them. http://projects.blender.org/tracker/?group_id=9atid=125func=detailaid=1461 -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgp6xGEH8sWYG.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are we switching from blender to ac3d?
On Sat, 25 Dec 2004 03:48:29 - Jim Wilson wrote: Wasn't this a blender model? Do we want to go the route of breaking away from the blender artists by working on the converted ac3d format files? If we don't, then we should probably have blender sources available along with the base distribution. I like ac3d a lot, but after getting gypped by the developer, I'm looking at the whole idea of developing open sourced models with a closed source tool in a much different light. No kidding. It's really surprising that plib supports several proprietary 3d modellers, but doesn't support the one really powerful and popular open source modeller. But I don't suppose it's because they're opposed, but rather because no one has sent in code. It's a shame, too, because .blend files can include a lot of detail that e.g. ac3d files cannot. Those using blender, what exactly (if anything) needs to be done to the ac file after exporting it to ac format now? Are there any unresolvable problems. I'm just wondering if using the exporter code it might be reasonable to write a loader for blender files. A plib loader for .blend would, IMHO, be an incredible boon for FG. As noted, ac3d file format can't include specular/diffuse shading info. Blender/.blend files also give you the ability to texture an object's faces in a fashion other than UV mapping -- by assigning (named) materials to faces, and then assigning different textures to the different materials. ac3d files can't do this. There's a lot of other .blend functionality that ac3d can't do (e.g. procedural textures), but these two are the ones that have bitten me so far. -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgp30vapz59hS.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] are we switching from blender to ac3d?
Chris Metzler writes: No kidding. It's really surprising that plib supports several proprietary 3d modellers, but doesn't support the one really powerful and popular open source modeller. PLib was written *before* blender *was* A plib loader for .blend would, IMHO, be an incredible boon for FG. PLib is Open Source and If it itches ... :-) Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are we switching from blender to ac3d?
I just noticed that Blender apparently does not support 'lines' ie: a line drawn between 2 vertices with no real width (although visible). Is there a way to make blender use 'lines' or is it polys only? Lines can be handy to represent aerials etc and have a very minimal overhead when rendered in FG. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are we switching from blender to ac3d?
On Sat, 25 Dec 2004 16:05:19 +, Dave wrote in message [EMAIL PROTECTED]: I just noticed that Blender apparently does not support 'lines' ie: a line drawn between 2 vertices with no real width (although visible). Is there a way to make blender use 'lines' or is it polys only? Lines can be handy to represent aerials etc and have a very minimal overhead when rendered in FG. ..a cheap shot in the dark: lines are _narrow_ polygons in Blender? -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are we switching from blender to ac3d?
On Sat, 25 Dec 2004 10:54:41 -0500 Norman Vine wrote: Chris Metzler writes: A plib loader for .blend would, IMHO, be an incredible boon for FG. PLib is Open Source and If it itches ... :-) Absolutely -- that's why I wrote that I don't think plib developers are opposed, but rather it's just that no one has contributed it. If I knew more than how to do Hello World in C/C++ at this point, I'd be game! Barring that, my doing it has to wait until I *do*. -c (now, if plib had been written in Fortran, hehehehe) -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgpoyozBO4M3V.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are we switching from blender to ac3d?
On Saturday 25 Dec 2004 17:09, Arnt Karlsen wrote: On Sat, 25 Dec 2004 16:05:19 +, Dave wrote in message [EMAIL PROTECTED]: I just noticed that Blender apparently does not support 'lines' ie: a line drawn between 2 vertices with no real width (although visible). Is there a way to make blender use 'lines' or is it polys only? Lines can be handy to represent aerials etc and have a very minimal overhead when rendered in FG. ..a cheap shot in the dark: lines are _narrow_ polygons in Blender? What I'm getting at is that the .ac file supports a line drawn between 2 vertices whereas Blender *seems* to require at least three (to make a thin triangle) Am I correct with this or is there some way to do vertex-vertex lines in Blender? ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are we switching from blender to ac3d?
On 25 Dec 2004, at 14:43, Chris Metzler wrote: A plib loader for .blend would, IMHO, be an incredible boon for FG. As noted, ac3d file format can't include specular/diffuse shading info. Blender/.blend files also give you the ability to texture an object's faces in a fashion other than UV mapping -- by assigning (named) materials to faces, and then assigning different textures to the different materials. ac3d files can't do this. There's a lot of other .blend functionality that ac3d can't do (e.g. procedural textures), but these two are the ones that have bitten me so far. This is absolutely the wrong approach; the .blend file (like the .3ds format) is a very, rich, complex format that evolves with Blender releases. Just like 3DS, it is a dreadful format to import / export, and no-one should try. The correct approach is to pick a format that makes sense for FlightGear (whatever that may be), and write / find / improve a Blender exporter script (which are written in Python) for that format. The exporter API evolves slowly across Blender releases and is stable for precisely this reason. BTW, this is why 3DS do not document their file format, but do provide a very good exporter API. All commerical games invariably use an efficent, renderer specific format for their meshes; early in the development cycle they write a 3DS exporter (or Maya, etc) and give it to the artists, and that it the tool-chain. For plib, that format would probably be some kind of serialised representation of the scene-graph, but I'm not a PLIB expert. BTW, I have been through this cycle with WorldForge clients; currently one client loads 3DS files, but we are hurriedly switching to 'export' formats (as opposed to editable ones) becuase the 3DS loaders are enormous and complex. Trying to load 3DS / .blend / .lwo (and, I would contend, .ac3d) is analagous to saying FG should load it's textures as XCFs / .psps / PaintShopPro files - it's possible, but why on earth would you go to so much effort? HH James ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] are we switching from blender to ac3d?
James Turner writes: On 25 Dec 2004, at 14:43, Chris Metzler wrote: A plib loader for .blend would, IMHO, be an incredible boon for FG. This is absolutely the wrong approach; the .blend file (like the .3ds format) is a very, rich, complex format that evolves with Blender releases. Just like 3DS, it is a dreadful format to import / export, and no-one should try. The correct approach is to pick a format that makes sense for FlightGear (whatever that may be), and write / find / improve a Blender exporter script (which are written in Python) for that format. If someone was to do this I would suggest exporting to the native .ssg binary format :-) direct'ly yr's Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are we switching from blender to ac3d?
Norman Vine wrote: If someone was to do this I would suggest exporting to the native .ssg binary format :-) If they could fix the .ssg endianness problem in the process I'm all for it. Eirk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are we switching from blender to ac3d?
Erik Hofman wrote: Norman Vine wrote: If someone was to do this I would suggest exporting to the native .ssg binary format :-) If they could fix the .ssg endianness problem in the process I'm all for it. .ssg format is basically a binary memory dump of the internal ssg structures. This has some advantages within plib-based applications, but it would be tough to build an exporter from a non-plib application. It would be a lot simpler to build a plib-based converter, but then you'd need to be able to read the source format into plib anyway. .ssg is extremely non portable, and would make it very difficult for people to edit the models with any non-plib based modelers, and I'm not aware of any plib-based modelers that are far enough along to be useful. I think we would do better to stay with high level 3d formats. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] are we switching from blender to ac3d?
Erik Hofman writes: Norman Vine wrote: If someone was to do this I would suggest exporting to the native .ssg binary format :-) If they could fix the .ssg endianness problem in the process I'm all for it. Hi Eric, [EMAIL PROTECTED] Intel really messed the world up didn't they :-) However I don't think this should be very hard todo as AFAIK all SSG low level file access goes thru the functions in ssgio.cxx. We just need to decide which endianness is the default and then wrap all the lowlevel code for the other method with the appropriate inlines from PLIB::Util::ul.h Which version gets compiled in would be controlled by the configure script. Am I missing something here ? Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are we switching from blender to ac3d?
Norman Vine wrote: Curtis L. Olson writes: Norman Vine wrote: If someone was to do this I would suggest exporting to the native .ssg binary format :-) .ssg format is basically a binary memory dump of the internal ssg structures. This has some advantages within plib-based applications, but it would be tough to build an exporter from a non-plib application. It would be a lot simpler to build a plib-based converter, but then you'd need to be able to read the source format into plib anyway. .ssg is extremely non portable, and would make it very difficult for people to edit the models with any non-plib based modelers, and I'm not aware of any plib-based modelers that are far enough along to be useful. I think we would do better to stay with high level 3d formats. Excuse me Curt but This is bordering on FUD You still have the original Blender Files How-long-do-we-wait-for-FlightGear-to-load'ly yr's 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. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
