From: Heiko S. <aei...@ya...> - 2008-09-27 17:46:29
|
Hi, Today in MP I noticed an effect due to a bug, which isn't yet resolved on win32. FGFS always loads OSG-Objects with correspondent name. Example: I have a f16.osg on my disk under OopenSceneGraph/data and the the f16.ac under FlightGear/data from CVS. When I choose the f16 I always get the f16.osg though the paths are all correct to the fgfs-model. The same happens with other osg-models. The point is, Helijah made a siple shadow for his DR400 ( the same princip like Bo105)- but he called the shadow-model "OSGshadow", which leads to load the OSGShadow example. ( the one with the aircraft circling over a small piece of terrain) Exactly this was loaded in FGFS and had a very nice effect: www.hoerbird.net/fgfs-screen-bug.jpg http://www.hoerbird.net/fgfs-screen-207.jpg http://www.hoerbird.net/fgfs-screen-209.jpg http://www.hoerbird.net/fgfs-screen-210.jpg Unfortnatelly the shader on the windows were broken! ;-) Can some explain why it loads the wrong file? Regards HHS still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html __________________________________________________ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com |
From: Melchior F. <mf...@ao...> - 2008-09-27 18:08:49
|
* 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. |
From: Heiko S. <aei...@ya...> - 2008-09-28 05:59:59
|
--- Melchior FRANZ <mf...@ao...> schrieb am Sa, 27.9.2008: > Von: Melchior FRANZ <mf...@ao...> > Betreff: Re: [Flightgear-devel] Bug or Feature? Or an accidently way to landinglights; -)? > An: fli...@li... > 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 |
From: Tim M. <ti...@re...> - 2008-09-28 08:15:26
|
Heiko Schulz wrote: > > > --- Melchior FRANZ <mf...@ao...> schrieb am Sa, 27.9.2008: > >> Von: Melchior FRANZ <mf...@ao...> >> Betreff: Re: [Flightgear-devel] Bug or Feature? Or an accidently way to landinglights; -)? >> An: fli...@li... >> 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 |
From: Melchior F. <mf...@ao...> - 2008-09-28 08:56:32
|
* Tim Moore -- Sunday 28 September 2008: > You can call it whatever you like :) The consensus is not > universally negative. Fact is: there was no consensus at all. IIRC two people on IRC agreed with you and later Curt on the list. None of them knew that the patch was based on wrong assumptions. > I introduced this feature when I found gross performance > problems in some of our models; at the time it was radio masts. Yes. Or more precisely, the wrong assumption that the AC3D format could only store lines as separate block entries and that OSG's AC3D importer could for that reason not create efficient structures. But even later that day (IIRC) we found out that this was wrong. Jon committed fixed pylon*.ac models, and the whole reason for the patch disappeared. Now we have that abomination in CVS, and all it does is annoy people and make FlightGear unpredictable and surprising. > The model names are embedded in the scenery, so it's not > practical to change them without rebuilding the scenery, AFIAK. The change wasn't/isn't even necessary (see above). > The only problem I see is picking up files from unexpected > places, which really means the OSG sample data directory. ... and any other directory where we store models, right? > Would picking another file extension for the substitution, > such as ".fgm", satisfy you? The main goal must be: if a developer *asks* for foo.ac, give him foo.ac. Not foo.osg, not foo.fgm, not anything else. If whatever was asked for couldn't be found, warn him/her and, optionally, pick something else. m. |
From: Melchior F. <mf...@ao...> - 2008-09-28 09:01:07
|
* 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. |
From: gerard r. <gh...@gm...> - 2008-09-28 09:24:49
|
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. Regards Gerard |
From: Vivian M. <viv...@li...> - 2008-09-28 13:55:03
|
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 |
From: gerard r. <gh...@gm...> - 2008-09-28 14:42:24
|
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.41260.ghmalau%40gmail.com&forum_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 <===================================== Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ "J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire " |
From: Vivian M. <viv...@li...> - 2008-09-29 12:05:07
|
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.com&forum_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 |
From: Vivian M. <viv...@li...> - 2008-09-29 13:08:11
|
I wrote > 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.com&forum_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 > Wouldn't you just know it - post appears, and I now know what the situation is. It is in current osg sources - revision 8881. However, I don't think there has been a version bump since it has gone in. Tim is waiting for that before enabling enabled the corresponding code in SimGear, which is already in cvs head. So if you want to try it update osg and simgear then uncomment this: #define OSG_PARTICLE_FIX 1 in simgear\source\simgear\scene\model\particles.cxx at about line 110 No guarantees - I haven't tested revision 8881. Vivian |
From: gerard r. <gh...@gm...> - 2008-09-29 14:45:35
|
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. For instance, the effect does not need any texture which is processed randomly, according the OSG script. 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). 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. Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ "J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire " |
From: Vivian M. <viv...@li...> - 2008-09-29 20:01:36
|
gerard robin wrote: > -----Original Message----- > From: [mailto:gh...@gm...] > 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 |
From: gerard r. <gh...@gm...> - 2008-09-30 00:04:09
|
On lundi 29 septembre 2008, Vivian Meazza wrote: > gerard robin wrote: > > -----Original Message----- > > From: [mailto:gh...@gm...] > > 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? 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. > > > Vivian > Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ "J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire " |
From: Heiko S. <aei...@ya...> - 2008-09-30 13:25:00
|
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=1009389&postcount=1379 http://www.flugzeugforum.de/forum/showpost.php?p=1009390&postcount=1380 http://www.flugzeugforum.de/forum/showpost.php?p=1009391&postcount=1381 http://www.flugzeugforum.de/forum/showpost.php?p=1009392&postcount=1382 http://www.flugzeugforum.de/forum/showpost.php?p=1009394&postcount=1384 Regards HHS |
From: Vivian M. <viv...@li...> - 2008-09-30 20:42:34
|
Heiko Schulz > > 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... transparency _is_ controllable. See data/Aircraft/Buccaneer/Models/Effects/haze.xml > 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=1009389&postcount=1379 > http://www.flugzeugforum.de/forum/showpost.php?p=1009390&postcount=1380 > http://www.flugzeugforum.de/forum/showpost.php?p=1009391&postcount=1381 > http://www.flugzeugforum.de/forum/showpost.php?p=1009392&postcount=1382 > http://www.flugzeugforum.de/forum/showpost.php?p=1009394&postcount=1384 > We can get close I think - Melchior did a dust cloud for the Bo105. Anders has done an excellent fire and smoke for a crashed ac - which has some similarities. Vivian |
From: Martin S. <Mar...@mg...> - 2008-09-30 14:03:20
|
Heiko Schulz wrote: > http://www.flugzeugforum.de/forum/showpost.php?p=1009389&postcount=1379 These links are pointless, you're required to have an account to view the images, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
From: Heiko S. <aei...@ya...> - 2008-09-30 14:18:05
|
> > These links are pointless, you're required to have an > account to view > the images, > > Martin. Oh- shit, I forgot..... Sorry! O.k. for description: Helicopter landed on a basketball field of clay and made a really huge cloud of dust. Each cloudpart are shifting away randomly and affected by the wind, the downwash and the turbulences, covering the whole place. They are also affected by the objects around this area. This means it needs a lot of properties to control which our current system cannot use yet to my knowledge. Some of the effets named above can be done with .osg, but not yet with our particle system. Regards HHS __________________________________________________ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com |
From: gerard r. <gh...@gm...> - 2008-09-30 15:16:40
|
On mardi 30 septembre 2008, Heiko Schulz wrote: > > These links are pointless, you're required to have an > > account to view > > the images, > > > > Martin. > > Oh- shit, I forgot..... > Sorry! > > O.k. for description: > Helicopter landed on a basketball field of clay and made a really huge > cloud of dust. > > Each cloudpart are shifting away randomly and affected by the wind, the > downwash and the turbulences, covering the whole place. They are also > affected by the objects around this area. > > This means it needs a lot of properties to control which our current system > cannot use yet to my knowledge. Some of the effets named above can be done > with .osg, but not yet with our particle system. > > Regards > HHS > > Hello Heiko, That is exactly what i wanted to explain. However today we can do it with a mixted of OSG script models (severals models) and the usual animation property (scale, select, rotate) , i played with it in order to get the wakes effects (large concentric circles moving from inside to outside) of an helicopter which over the sea when rescueing (S-51) I never included it because the result was not nice, i hope (after many hours working on these wake effects ) to propose something. And, partly, we have that approach, with the example of effects on the Catalina CVS which use animation of OSG script animation models, animated by the usual animations <property> rotate, select ( i don't remember if do use scale). That existing example is tricky, and not very accurate :( Sure, the best, would be, to have everything included into our usual XML language. But, we must have first the features which manage a hierarchy of effects, with the relationship child(s) mother => multilevel =>multistage (that is what i called animations into animation). It is easy to write it, within OSG script (which do not want too many lines of script) It won't be so easy to write it with XML ( if we had the features) , many.. many ... lines of XML script would be necessary (look at any existing examples of usual animation with hierarchy, for instance landing gear and its components, struts, wheels..) and XML scripts will become very heavy to write and to manipulate. -- Gérard http://pagesperso-orange.fr/GRTux/ "J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire " |
From: Vivian M. <viv...@li...> - 2008-10-01 09:07:33
|
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 |
From: gerard r. <gh...@gm...> - 2008-10-01 09:34:51
|
On mardi 30 septembre 2008, Vivian Meazza wrote: > 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 > Thanks, I feel being like a program in CVS, when a lot of persons are working on me It is never finished :) Unfortunately the comparison stops here, because there is not any improvement, only repair. Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ "J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire " |
From: gerard d. <gh...@gm...> - 2008-10-01 11:12:35
|
---------- Forwarded message ---------- From: gerard robin <gh...@gm...> Date: 2008/10/1 Subject: Re: [Flightgear-devel] Bug or Feature? Or an accidently way to landinglights; -)? To: FlightGear developers discussions < fli...@li...> On mardi 30 septembre 2008, Vivian Meazza wrote: > 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 > Thanks, I feel being like a program in CVS, when a lot of persons are working on me It is never finished :) Unfortunately the comparison stops here, because there is not any improvement, only repair. Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ "J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire " |
From: Erik H. <er...@eh...> - 2008-09-30 08:08:49
|
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 |
From: Vivian M. <viv...@li...> - 2008-10-09 13:43:41
|
Erik Hofman wrote (a long time ago) > -----Original Message----- > From: [mailto:er...@eh...] > 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 |
From: Erik H. <er...@eh...> - 2008-10-09 14:07:00
|
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) |