Re: [Flightgear-devel] Bug or Feature? Or an accidently way to landinglights; -)?
Erik Hofman wrote (a long time ago) -Original Message- From: [mailto:[EMAIL PROTECTED] Sent: 30 September 2008 09:09 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Bug or Feature? Or an accidently way to landinglights; -)? gerard robin wrote: OSG script can be very complex with animations into animations regarding particles shapes, particles colors ... and so on. This is what I have been missing when playing with submodel particles; when ejecting a flare I can get the flashlight modeled correctly but all flares I have seen produce a smoke trail which is not yet possible to animate (as far as I know). It would be nice to have a recursive submodel object, or in other words it would be nice to be able to specify new submodels within the submodel animation configuration file. It's been possible to attach a sub-submodel to a submodel for some time now (a year or so). See data\Aircraft\seahawk\Models\seahawk-submodels.xml and data\Aircraft\seahawk\Models\seahawk-subsubmodels.xml to see how it's done. Submodels are hard on frame rates, so if you want a smoke trail, this is probably not the way to do it. But, good news, it is also possible to attach particles to submodels. I have attached a short smoke trail to tracer, and that's now in cvs, or will be shortly. I'm not sure how realistic it is for tracer, but it does serve to demonstrate how you might do it for a flare. Vivian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug or Feature? Or an accidently way to landinglights; -)?
Vivian Meazza wrote: It's been possible to attach a sub-submodel to a submodel for some time now (a year or so). See data\Aircraft\seahawk\Models\seahawk-submodels.xml and data\Aircraft\seahawk\Models\seahawk-subsubmodels.xml to see how it's done. Submodels are hard on frame rates, so if you want a smoke trail, this is probably not the way to do it. But, good news, it is also possible to attach particles to submodels. I have attached a short smoke trail to tracer, and that's now in cvs, or will be shortly. I'm not sure how realistic it is for tracer, but it does serve to demonstrate how you might do it for a flare. I didn't even know there was a difference between submodels and particles these days ... thanks for the info! Erik (I start to wonder if the documentation isn't severely out of date) - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug or Feature? Or an accidently way to landinglights; -)?
Hi, I didn't even know there was a difference between submodels and particles these days ... thanks for the info! Erik there is a big difference, not only regarding perfomance and abilities! Very nice to play with! (I start to wonder if the documentation isn't severely out of date) Regards HHS (wonders if Erik knows that we moved from plib to OSG... :-P) - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug or Feature? Or an accidently way to landinglights; -)?
On jeudi 09 octobre 2008, Vivian Meazza wrote: Erik Hofman wrote (a long time ago) -Original Message- From: [mailto:[EMAIL PROTECTED] Sent: 30 September 2008 09:09 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Bug or Feature? Or an accidently way to landinglights; -)? gerard robin wrote: OSG script can be very complex with animations into animations regarding particles shapes, particles colors ... and so on. This is what I have been missing when playing with submodel particles; when ejecting a flare I can get the flashlight modeled correctly but all flares I have seen produce a smoke trail which is not yet possible to animate (as far as I know). It would be nice to have a recursive submodel object, or in other words it would be nice to be able to specify new submodels within the submodel animation configuration file. It's been possible to attach a sub-submodel to a submodel for some time now (a year or so). See data\Aircraft\seahawk\Models\seahawk-submodels.xml and data\Aircraft\seahawk\Models\seahawk-subsubmodels.xml to see how it's done. Submodels are hard on frame rates, so if you want a smoke trail, this is probably not the way to do it. But, good news, it is also possible to attach particles to submodels. I have attached a short smoke trail to tracer, and that's now in cvs, or will be shortly. I'm not sure how realistic it is for tracer, but it does serve to demonstrate how you might do it for a flare. Vivian Since i never tried it, submodel into submodel with xml my answer is only a guess. It looks to me that the full OSG script ( without any external xml script) is more performant and less cpu consummer that any equivalent xml script. However, the comparison is not fair, the xml is understood by everybody, it is integrated into FG ( wind effect ) versus the OSG script which was difficult to understand, it is not integrated into FG. My whish is to have both :) :) Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug or Feature? Or an accidently way to landinglights; -)?
Hi, However, the comparison is not fair, the xml is understood by everybody, it is integrated into FG ( wind effect ) versus the OSG script which was difficult to understand, it is not integrated into FG. My whish is to have both :) :) Cheers -- Gérard That's not quite correct, as far as I understand. the xml-one is the translation of this into FGFS. Menas that you can controll the properties which you know from OSG script by xml. Unfortunately not all of the given features had been translated. That's why it is possible to have them reactong to the wind. Regards HHS - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug or Feature? Or an accidently way to landinglights; -)?
Heiko Schulz wrote: (wonders if Erik knows that we moved from plib to OSG... :-P) I think I remember something like that .. :) I've been busy for more than a year (maybe two) and didn't pay much attention to FlightGear during that period. Erik - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug or Feature? Or an accidently way to landinglights; -)?
gerard robin wrote: OSG script can be very complex with animations into animations regarding particles shapes, particles colors ... and so on. This is what I have been missing when playing with submodel particles; when ejecting a flare I can get the flashlight modeled correctly but all flares I have seen produce a smoke trail which is not yet possible to animate (as far as I know). It would be nice to have a recursive submodel object, or in other words it would be nice to be able to specify new submodels within the submodel animation configuration file. Erik - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug or Feature? Or an accidently way to landinglights; -)?
* gerard robin -- Sunday 28 September 2008: The OSG animation particles models could be very accurate within XML, but unfortunately there is missing a lot of features ( more than a lot :) ) which are there within OSG native model. OK, so you identified where the brainpower should have gone: Not in ugly hacks, but in improving particles. Right? :-P m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug or Feature? Or an accidently way to landinglights; -)?
gerard robin wrote On lundi 29 septembre 2008, Vivian Meazza wrote: gerard robin wrote So, if I understand you correctly, there are no missing features, just the 2 bugs: z buffer and jitter. Tim has submitted a fix for both those to OSG. I've been using it for some time now. Works perfectly, but AFAIKS have not been taken aboard by OSG. Before: ftp://ftp.abbeytheatre2.org.uk/fgfs/Screen-shots/bucc-particles.jpg After: ftp://ftp.abbeytheatre2.org.uk/fgfs/Screen-shots/bucc-particles- 2.jpg Vivian Not exactly what i mean. Yes, with xml, had bug with the z buffer No ,xml don't gives every feature which are available with OSG script, The result from FG xml script is very simple ( not far from we had with PLIB effects ). OSG script can be very complex with animations into animations regarding particles shapes, particles colors ... and so on. I'm not sure I understand the problems that you describe - the xml particles do particle colour, size, transparency, texture, and the gravity, fluid, and wind programs all work (which they don't in the .osg script) - I'm not aware of anything missing? Only 2 shapes are available: QUAD and LINE. I would guess that they cover pretty much all our needs; do you have an example of requirement for another shape? For instance, the effect does not need any texture which is processed randomly, according the OSG script. Sorry you lost me there - random texture? Language difficulty perhaps? sorry, my language is not good ( out from the hospital, i need some rest :) , same problem in French :( ) To me (and today) there is only one way to get the best nice effects (more realistic): = it is to use the OSG script, but if it will be fully translated to XML (which could give some heavy coding). If you could describe what is missing in your opinion, we could perhaps at least put it on the TODO list. Don't think the coding would be too heavy. I had tried to get the effect that i get with the Catalina wakes OSG, without any success. When testing the xml scripts, i never got the same result ( may be i am wrong), the result was very poor. The content of the OSG scripts (when reading it) shows that there is an animation into an other animation, and a processing of shape colors and transparencies which avoid any texture ( the texture looks to be created randomly). We can notice that, these OSG examples are a very low level examples ( even they are better than my XML translation) With it we can have an higher complexity ( i am working on it) and i hope to get better and better effects, without any limitations, but the know how the writer and the power of the CPU. So, i concluded that only OSG script is able to answer the requested complexity. So up to now, because OSG opened a wide door to many features, i guess that we must not reduce the size of that door :) Again, i agree with the common usage of it, like trailing smoke, or some dust on the wheel when touching the ground, however we can do more than we did with PLIB. I haven't found an effect I couldn't do yet, but perhaps you have? Let us know and we will look into it. You are right, if we only want the basic ones, which answer today to most of the generic requests, in addition to it, we still have Plib which answer too ( the Catalina water bomber use it, i don't need to translate it in OSG) However with OSG we can do more and better, the wake effects , the fire effect, exploding effect are other specific cases which wants more complexity. Sorry to read that you have been in hospital - hope you are well now, Regards Vivian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug or Feature? Or an accidently way to landinglights; -)?
Hi, The result from FG xml script is very simple ( not far from we had with PLIB effects ). OSG script can be very complex with animations into animations regarding particles shapes, particles colors ... and so on. I'm not sure I understand the problems that you describe - the xml particles do particle colour, size, transparency, texture, and the gravity, fluid, and wind programs all work (which they don't in the .osg script) - I'm not aware of anything missing? Only 2 shapes are available: QUAD and LINE. I would guess that they cover pretty much all our needs; do you have an example of requirement for another shape? For instance, the effect does not need any texture which is processed randomly, according the OSG script. Sorry you lost me there - random texture? Language difficulty perhaps? To me (and today) there is only one way to get the best nice effects (more realistic): = it is to use the OSG script, but if it will be fully translated to XML (which could give some heavy coding). If you could describe what is missing in your opinion, we could perhaps at least put it on the TODO list. Don't think the coding would be too heavy. We can notice that, these OSG examples are a very low level examples ( even they are better than my XML translation) With it we can have an higher complexity ( i am working on it) and i hope to get better and better effects, without any limitations, but the know how the writer and the power of the CPU. So, i concluded that only OSG script is able to answer the requested complexity. So up to now, because OSG opened a wide door to many features, i guess that we must not reduce the size of that door :) Again, i agree with the common usage of it, like trailing smoke, or some dust on the wheel when touching the ground, however we can do more than we did with PLIB. I haven't found an effect I couldn't do yet, but perhaps you have? Let us know and we will look into it. However with OSG we can do more and better, the wake effects , the fire effect, exploding effect are other specific cases which wants more complexity. My point of view: Other sims and some games shows what is possible with particles - and that's a lot! The particle system we have now, is a great step compared to plib, but there is still plenty to do! Beside the known bugs (jitter, transparency) it is not yet possible to controll it completely. As an exapmle the transparency of the particles are static - thye can't be controlled by any properties. Well at least I don't know how... I found some very extreme pics of a dust cloud made by a helicopter which landed on a clay so tell me if exactly this possible with our particle system already: http://www.flugzeugforum.de/forum/showpost.php?p=1009389postcount=1379 http://www.flugzeugforum.de/forum/showpost.php?p=1009390postcount=1380 http://www.flugzeugforum.de/forum/showpost.php?p=1009391postcount=1381 http://www.flugzeugforum.de/forum/showpost.php?p=1009392postcount=1382 http://www.flugzeugforum.de/forum/showpost.php?p=1009394postcount=1384 Regards HHS - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug or Feature? Or an accidently way to landinglights; -)?
gerard robin wrote On dimanche 28 septembre 2008, Vivian Meazza wrote: gerard robin wrote On dimanche 28 septembre 2008, Melchior FRANZ wrote: * Melchior FRANZ -- Sunday 28 September 2008: The change wasn't/isn't even necessary (see above). Another reason for the patch was that we could use OSG's model embedded particles in the same scenery. Now that we have XML configured OSG particles, this reason is obsolete, too. No reasons left, as far as I can see. m. Not fully right, the XML doesn't give ( all) the features which are into OSG, . So to me the paricles.osg object with animations is longer necessary. For instance, the Catalina and some others that i am working on. The OSG animation particles models could be very accurate within XML, but unfortunately there is missing a lot of features ( more than a lot :) ) which are there within OSG native model. I haven't noticed anything critical missing from the XML particles, and they do put the particles in the right frame of reference, and they do get the right wind, which the osg solution does not. What do you see as missing? Perhaps we can get on the case. There is an update to particles in osg in the pipeline, which I'm currently using, and that does improve the look of the .xml particles. I'm not aware of the current position of that patch. Vivian Since i don't know what is new in the pipeline, i can't precisely answer the question. I only can get some comparison with the actual CVS process ( we had a talk about it before ) The xml which is there, don't give the same result than we have with the .osg effects, and, my models (which are in CVS) are not perfect, i am working on a huge improvement regarding the wake.osg which will increase more the differences. Yes, a long line of trailing smoke is not possible, because there is not any interaction from .osg to .ac and/or externals ( like winds). So, i don't say that the xml is wrong, i only say that it don't give the same eye candy. To remember the first talk we had about it here the link : http://sourceforge.net/mailarchive/forum.php?thread_name=200808121328.4126 0.ghmalau%40gmail.comforum_name=flightgear-devel = Are we sure that, all the Particle features which are within OSG, are available with the new XML coding particlesystem ? When translating one of my .osg file to particlesystem .xml file, i don't get the same quality of result. It could be just me. I can be wrong. :( Or that new XML coding is may be a first step, and others improvements are coming :) No, all the features of particles are not available with the xml version, but I don't think that should affect performance. Tim recently fixed a bug which only showed up under MSVC9, and other bugs have been reported, in particular that the particles jitter. There are no further enhancements planned to the xml stuff that I am aware of, unless Tiago is doing something. SNIP Vivian = So, if I understand you correctly, there are no missing features, just the 2 bugs: z buffer and jitter. Tim has submitted a fix for both those to OSG. I've been using it for some time now. Works perfectly, but AFAIKS have not been taken aboard by OSG. Before: ftp://ftp.abbeytheatre2.org.uk/fgfs/Screen-shots/bucc-particles.jpg After: ftp://ftp.abbeytheatre2.org.uk/fgfs/Screen-shots/bucc-particles-2.jpg Vivian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug or Feature? Or an accidently way to landinglights; -)?
gerard robin wrote: -Original Message- From: [mailto:[EMAIL PROTECTED] Sent: 29 September 2008 15:45 To: FlightGear developers discussions Subject: Re: [Flightgear-devel]Bug or Feature? Or an accidently way to landinglights; -)? On lundi 29 septembre 2008, Vivian Meazza wrote: gerard robin wrote So, if I understand you correctly, there are no missing features, just the 2 bugs: z buffer and jitter. Tim has submitted a fix for both those to OSG. I've been using it for some time now. Works perfectly, but AFAIKS have not been taken aboard by OSG. Before: ftp://ftp.abbeytheatre2.org.uk/fgfs/Screen-shots/bucc-particles.jpg After: ftp://ftp.abbeytheatre2.org.uk/fgfs/Screen-shots/bucc-particles-2.jpg Vivian Not exactly what i mean. Yes, with xml, had bug with the z buffer No ,xml don't gives every feature which are available with OSG script, The result from FG xml script is very simple ( not far from we had with PLIB effects ). OSG script can be very complex with animations into animations regarding particles shapes, particles colors ... and so on. I'm not sure I understand the problems that you describe - the xml particles do particle colour, size, transparency, texture, and the gravity, fluid, and wind programs all work (which they don't in the .osg script) - I'm not aware of anything missing? Only 2 shapes are available: QUAD and LINE. I would guess that they cover pretty much all our needs; do you have an example of requirement for another shape? For instance, the effect does not need any texture which is processed randomly, according the OSG script. Sorry you lost me there - random texture? Language difficulty perhaps? To me (and today) there is only one way to get the best nice effects (more realistic): = it is to use the OSG script, but if it will be fully translated to XML (which could give some heavy coding). If you could describe what is missing in your opinion, we could perhaps at least put it on the TODO list. Don't think the coding would be too heavy. So up to now, because OSG opened a wide door to many features, i guess that we must not reduce the size of that door :) Again, i agree with the common usage of it, like trailing smoke, or some dust on the wheel when touching the ground, however we can do more than we did with PLIB. I haven't found an effect I couldn't do yet, but perhaps you have? Let us know and we will look into it. Vivian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug or Feature? Or an accidently way to landinglights; -)?
--- Melchior FRANZ [EMAIL PROTECTED] schrieb am Sa, 27.9.2008: Von: Melchior FRANZ [EMAIL PROTECTED] Betreff: Re: [Flightgear-devel] Bug or Feature? Or an accidently way to landinglights; -)? An: flightgear-devel@lists.sourceforge.net Datum: Samstag, 27. September 2008, 20:08 * Heiko Schulz -- Saturday 27 September 2008: Can some explain why it loads the wrong file? That's an intentional bug, a.k.a. (mis)feature. You can also call it poor design. It was introduced after a discussion in this thread (where my objection was overruled): http://www.mail-archive.com/flightgear-devel%40lists.sourceforge.net/msg12849.html And here's another thread where someone called Heiko complains about it ... ;-) http://www.mail-archive.com/flightgear-devel%40lists.sourceforge.net/msg15466.html That feature is also why I have to redefine the OSG_FILE_PATH environment variable, so that OSG doesn't use the shiny OSG demo cow.osg instead of our own cow.ac. m. Just wanted to bring this back- for me it is definitely a bug, and should be changed! I don't see any advantages of that! __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug or Feature? Or an accidently way to landinglights; -)?
Heiko Schulz wrote: --- Melchior FRANZ [EMAIL PROTECTED] schrieb am Sa, 27.9.2008: Von: Melchior FRANZ [EMAIL PROTECTED] Betreff: Re: [Flightgear-devel] Bug or Feature? Or an accidently way to landinglights; -)? An: flightgear-devel@lists.sourceforge.net Datum: Samstag, 27. September 2008, 20:08 * Heiko Schulz -- Saturday 27 September 2008: Can some explain why it loads the wrong file? That's an intentional bug, a.k.a. (mis)feature. You can also call it poor design. It was introduced after a discussion in this thread (where my objection was overruled): You can call it whatever you like :) The consensus is not universally negative. http://www.mail-archive.com/flightgear-devel%40lists.sourceforge.net/msg12849.html And here's another thread where someone called Heiko complains about it ... ;-) http://www.mail-archive.com/flightgear-devel%40lists.sourceforge.net/msg15466.html That feature is also why I have to redefine the OSG_FILE_PATH environment variable, so that OSG doesn't use the shiny OSG demo cow.osg instead of our own cow.ac. m. Just wanted to bring this back- for me it is definitely a bug, and should be changed! I don't see any advantages of that! I introduced this feature when I found gross performance problems in some of our models; at the time it was radio masts. Some of the problems come from the way they were modeled, others from inefficiencies in the .ac format itself. I wrote a program to run the OSG optimizer, as well as some of my own optimizations, and write out the model in the .osg format. I'm sure you agree that it is not efficient to do this at scenery load time while running FG. The model names are embedded in the scenery, so it's not practical to change them without rebuilding the scenery, AFIAK. Hence, this substitution mechanism. The only problem I see is picking up files from unexpected places, which really means the OSG sample data directory. I didn't really see picking up the wrong cow model as a deal breaker :) But I'm willing to change this scheme if it's really too onerous. Would picking another file extension for the substitution, such as .fgm, satisfy you? Tim - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug or Feature? Or an accidently way to landinglights; -)?
* Melchior FRANZ -- Sunday 28 September 2008: The change wasn't/isn't even necessary (see above). Another reason for the patch was that we could use OSG's model embedded particles in the same scenery. Now that we have XML configured OSG particles, this reason is obsolete, too. No reasons left, as far as I can see. m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug or Feature? Or an accidently way to landinglights; -)?
Hi, I haven't noticed anything critical missing from the XML particles, and they do put the particles in the right frame of reference, and they do get the right wind, which the osg solution does not. Here with win32 builds by Fred, I noticed that xml-particles linked to the aircrafts are broken sicne 2-3 weeks after their implementation! So I could only use it for 2-3 weeks correctly. Only the xml-particles used in scenery objects are behaves correct! What do you see as missing? Perhaps we can get on the case. There is an update to particles in osg in the pipeline, which I'm currently using, and that does improve the look of the .xml particles. I'm not aware of the current position of that patch. Vivian Hopefully it will bring back the particles in a correct way- I found it really annoying to see that a new and missing feature was broken just few weeks after coming in and not been fixed for a nearly half year! Reagrds HHS __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug or Feature? Or an accidently way to landinglights; -)?
* Heiko Schulz -- Saturday 27 September 2008: Can some explain why it loads the wrong file? That's an intentional bug, a.k.a. (mis)feature. You can also call it poor design. It was introduced after a discussion in this thread (where my objection was overruled): http://www.mail-archive.com/flightgear-devel%40lists.sourceforge.net/msg12849.html And here's another thread where someone called Heiko complains about it ... ;-) http://www.mail-archive.com/flightgear-devel%40lists.sourceforge.net/msg15466.html That feature is also why I have to redefine the OSG_FILE_PATH environment variable, so that OSG doesn't use the shiny OSG demo cow.osg instead of our own cow.ac. m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
