Re: [Flightgear-devel] animation problem (bo105 shadow)
Lee Elliott wrote: I'm glad someone else mentioned this:) I've noticed the same thing, and depending on which way you're looking, there are distinct 'ridges' or creases in the cloud layers, seemingly as a consequence of the reduced cloud layer radii. Just for the record, the cloud radii hasn't been changed, just the fact that it fades out to the edges. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] animation problem (bo105 shadow)
Hi, It lookes like a problem I had before... I had the strange effect that every ac3d object which I want to animate in some way needs to have at least two surfaces. So a simple sqare flat polygon will not be animated. Triangulating it to have two surfaces works well. On Montag, 22. März 2004 13:34, Melchior FRANZ wrote: I've added two shadows for the bo105 (after Jim beat me to it :-), [...] http://mail.flightgear.org/mailman/listinfo/flightgear-devel Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] animation problem (bo105 shadow)
Melchior FRANZ wrote: 1. Problem: it *has* to be a box. SimGear refuses to translate a mere (2D) plane! Do you tried splitting your quad into 2 triangles ? 2. SimGear refuses to rotate the rotor shadow alone (A). The object remains fixed like the fuselage shadow. If I add the fuselage shadow, both are rotated! The rotor shadow is also rotated if I remove the fuselage shadow from steps B and C. 3. Where the rotor shadow overlays the fuselage shadow, the resulting color is darker than either shadow. The shadows add. I mentioned that problem a while ago, and as a solution it was suggested to swap the two objects in the *.ac file. This, however, doesn't work. The resulting color is a percentage of the terrain color and a percentage of the shadow color, because I guess you are using alpha 1. When you draw 2 objects, the second ( whatever it is ) use the already modified color as the terrain color, and you have something darker. The only solution is to draw something that doesn't overlap. I don't understand what animation type alpha-test really does. The documentation is quite vague and lacks an explanation that can be understood by idiots like me. (The effect is to avoid depth buffer writing of pixel that are not seen because they are transparent. ?? why would I want to do that in some cases, but not in others. How does the problem look like, and how does it look when it's fixed. What does the value do? The textures do already have an alpha factor!?) Imagine you are drawing a tree with a quad with a texture of the tree. The pixel outside the shape of the tree are transparent. But because you are also writing to the depth buffer, because you don't want the object behind clear your tree, the transparent area is also written and objects behind this transparent area are discarded althougt they should appear. When you enable alpha test, transparent pixels are not drawn in the depth buffer, so objects in the background are not obscured by transparency, and you don't have to worry about drawing order, although generally result are better if the order is back to front. The effect can be seen in the suspension chains or the structures of the bridges. Without alpha test, you won't be able to see ground light through structures, and on bridge would disappear behind another. It is also applied to cloud layers, with an artefact though : when there are few clouds in a valley and you are below, you can see the sky through mountains. I experienced that flying in the Mont Blanc area recently. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] animation problem (bo105 shadow)
Melchior FRANZ said: I've added two shadows for the bo105 (after Jim beat me to it :-), but I can't animate them correctly. The situation is so strange that it must be a bug in fgfs. I've got objects shadow_fuselage and shadow_rotor. Both are very flat, textured boxes. The strategy is: A. rotate the rotor shadow B. scale both shadows according to pitch/roll C. translate both shadows down to -AGL height 1. Problem: it *has* to be a box. SimGear refuses to translate a mere (2D) plane! It probably has to be more than one surface. Thanks to the @#$%^ optimizer in plib. All you need to do is cut it in half. 2. SimGear refuses to rotate the rotor shadow alone (A). The object remains fixed like the fuselage shadow. If I add the fuselage shadow, both are rotated! The rotor shadow is also rotated if I remove the fuselage shadow from steps B and C. Be careful about listing more than one object in a single animation entry. It'll merge previously listed animations. 3. Where the rotor shadow overlays the fuselage shadow, the resulting color is darker than either shadow. The shadows add. I mentioned that problem a while ago, and as a solution it was suggested to swap the two objects in the *.ac file. This, however, doesn't work. That's right it doesn't. I'm not sure that there is a solution for this issue in the ac3d format. I don't understand what animation type alpha-test really does. The documentation is quite vague and lacks an explanation that can be understood by idiots like me. (The effect is to avoid depth buffer writing of pixel that are not seen because they are transparent. ?? why would I want to do that in some cases, but not in others. How does the problem look like, and how does it look when it's fixed. What does the value do? The textures do already have an alpha factor!?) This I'm not sure of, but it might have something to do with not processing fully transparent objects. Transparency could vary depending on the alpha-blend settings and if the transparency is full this might be a way of just deselecting the object at the application level. Based on my recollection of discussion on the list last week, that's probably what you are looking at. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] animation problem (bo105 shadow)
Frederic BOUVIER said: Imagine you are drawing a tree with a quad with a texture of the tree. The pixel outside the shape of the tree are transparent. But because you are also writing to the depth buffer, because you don't want the object behind clear your tree, the transparent area is also written and objects behind this transparent area are discarded althougt they should appear. When you enable alpha test, transparent pixels are not drawn in the depth buffer, so objects in the background are not obscured by transparency, and you don't have to worry about drawing order, although generally result are better if the order is back to front. Ah ok. I guessed wrong on that one :-) The effect can be seen in the suspension chains or the structures of the bridges. Without alpha test, you won't be able to see ground light through structures, and on bridge would disappear behind another. It is also applied to cloud layers, with an artefact though : when there are few clouds in a valley and you are below, you can see the sky through mountains. I experienced that flying in the Mont Blanc area recently. Could we just dynamically reorder the rendering of the layers based on location of the viewer rather than using the alpha-test? This problem actually shows up at KSFO most days with metar turned on. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] animation problem (bo105 shadow)
Melchior FRANZ I've added two shadows for the bo105 (after Jim beat me to it :-), but I can't animate them correctly. The situation is so strange that it must be a bug in fgfs. I've got objects shadow_fuselage and shadow_rotor. Both are very flat, textured boxes. The strategy is: A. rotate the rotor shadow B. scale both shadows according to pitch/roll C. translate both shadows down to -AGL height 1. Problem: it *has* to be a box. SimGear refuses to translate a mere (2D) plane! 2. SimGear refuses to rotate the rotor shadow alone (A). The object remains fixed like the fuselage shadow. If I add the fuselage shadow, both are rotated! The rotor shadow is also rotated if I remove the fuselage shadow from steps B and C. 3. Where the rotor shadow overlays the fuselage shadow, the resulting color is darker than either shadow. The shadows add. I mentioned that problem a while ago, and as a solution it was suggested to swap the two objects in the *.ac file. This, however, doesn't work. I don't understand what animation type alpha-test really does. The documentation is quite vague and lacks an explanation that can be understood by idiots like me. (The effect is to avoid depth buffer writing of pixel that are not seen because they are transparent. ?? why would I want to do that in some cases, but not in others. How does the problem look like, and how does it look when it's fixed. What does the value do? The textures do already have an alpha factor!?) I'd like the bo105 shadow to go into 0.9.4 (and Erik does, too :-). m. Here is the code that IMHO should work, but doesn't: animation typerotate/type object-nameshadow_rotor/object-name propertyrotors/main[0]/blade1_pos/property axis x0/x y0/y z1/z /axis /animation animation typerotate/type object-nameshadow_fuselage/object-name object-nameshadow_rotor/object-name propertyorientation/pitch-deg/property axis x0/x y-1/y z0/z /axis /animation animation typerotate/type object-nameshadow_fuselage/object-name object-nameshadow_rotor/object-name propertyorientation/roll-deg/property axis x1/x y0/y z0/z /axis /animation animation typetranslate/type object-nameshadow_fuselage/object-name object-nameshadow_rotor/object-name propertyposition/altitude-agl-ft/property factor0.2/factor axis x0/x y0/y z-1/z /axis /animation Perhaps not so much a bug, more just the way it is :-). I suggest you try the following: A. Does propertyrotors/main[0]/blade1_pos/property contain a valid value that will cause a rotation? B. Once an animation has tied 2 objects together, it seems not to subsequently separate them - try your rotations separately. C. Is a box necessary? - in 0.9.3 (don't know about CVS) more than one surface seems to do the trick. Regards Vivian M. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] animation problem (bo105 shadow)
Jim Wilson wrote: It is also applied to cloud layers, with an artefact though : when there are few clouds in a valley and you are below, you can see the sky through mountains. I experienced that flying in the Mont Blanc area recently. Could we just dynamically reorder the rendering of the layers based on location of the viewer rather than using the alpha-test? This problem actually shows up at KSFO most days with metar turned on. I noticed that at KSFO too. The problem with clouds is rather tough. Without alpha-test, we wouldn't see anything above clouds from below. The bottom of clouds ( the side of the quad pointing downward ) is drawn before the scene and the upper side after so we can see clouds through bridges or trees. This was needed before alpha test was used in models ( although I think alpha-test is not used yet for trees ). We can try to come back to the previous situation where all sides of clouds are drawn after the scene and rely on alpha test. There will be an ugly, not blended border around transparent patterns but It could be acceptable if it only show up at close distance. We can also begin to think about a multi pass method that would : 1. draw the clouds above the viewer without depth update, 2. draw the scene, 3 .redraw the clouds above with depth test With an impact on framerate due to double writing and problem like the one Melchior is experiencing with overlapping semi transparent objects. Haven't thought about it much of that. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] animation problem (bo105 shadow)
Fred, There is a different problem with the clouds; we need to be careful not to get distracted with a side issue here. In the case of the clouds, the primary problem is that the shape of the cloud bowl is much more curved than the shape of the earth. This means the elevation above ground of the clouds at some distance away is much lower than the elevation of the clouds at the view point. This doesn't show up much in flat areas, but you can *really* see it in mountainous areas. The cloud bowl is centered around the view point, so as you fly, watch the clouds that appear in front of mountains, as you get closer they will raise up and the intersection point will change. This is a primarily a problem with the shape of the cloud bowl, and not a problem with transparency or draw order or alpha test or anything like that. Ideally, the curvature of the cloud bowl should closely match the curvature of the surface of the earth which is *nearly* flat within visible distances. I would propose that a flat plane would more accurately match reality that our super hyper exagerated cloud bowl does now. The person who added the clould bowl was trying to make the clouds fade at the horizon, but I'm not sure this is the best way to go about it. Regards, Curt. Frederic BOUVIER wrote: I noticed that at KSFO too. The problem with clouds is rather tough. Without alpha-test, we wouldn't see anything above clouds from below. The bottom of clouds ( the side of the quad pointing downward ) is drawn before the scene and the upper side after so we can see clouds through bridges or trees. This was needed before alpha test was used in models ( although I think alpha-test is not used yet for trees ). We can try to come back to the previous situation where all sides of clouds are drawn after the scene and rely on alpha test. There will be an ugly, not blended border around transparent patterns but It could be acceptable if it only show up at close distance. We can also begin to think about a multi pass method that would : 1. draw the clouds above the viewer without depth update, 2. draw the scene, 3 .redraw the clouds above with depth test With an impact on framerate due to double writing and problem like the one Melchior is experiencing with overlapping semi transparent objects. Haven't thought about it much of that. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] animation problem (bo105 shadow)
I'm glad someone else mentioned this:) I've noticed the same thing, and depending on which way you're looking, there are distinct 'ridges' or creases in the cloud layers, seemingly as a consequence of the reduced cloud layer radii. It wasn't always this way, so I deduced that it had been done deliberately, some good reason. LeeE On Monday 22 March 2004 15:12, Curtis L. Olson wrote: Fred, There is a different problem with the clouds; we need to be careful not to get distracted with a side issue here. In the case of the clouds, the primary problem is that the shape of the cloud bowl is much more curved than the shape of the earth. This means the elevation above ground of the clouds at some distance away is much lower than the elevation of the clouds at the view point. This doesn't show up much in flat areas, but you can *really* see it in mountainous areas. The cloud bowl is centered around the view point, so as you fly, watch the clouds that appear in front of mountains, as you get closer they will raise up and the intersection point will change. This is a primarily a problem with the shape of the cloud bowl, and not a problem with transparency or draw order or alpha test or anything like that. Ideally, the curvature of the cloud bowl should closely match the curvature of the surface of the earth which is *nearly* flat within visible distances. I would propose that a flat plane would more accurately match reality that our super hyper exagerated cloud bowl does now. The person who added the clould bowl was trying to make the clouds fade at the horizon, but I'm not sure this is the best way to go about it. Regards, Curt. Frederic BOUVIER wrote: I noticed that at KSFO too. The problem with clouds is rather tough. Without alpha-test, we wouldn't see anything above clouds from below. The bottom of clouds ( the side of the quad pointing downward ) is drawn before the scene and the upper side after so we can see clouds through bridges or trees. This was needed before alpha test was used in models ( although I think alpha-test is not used yet for trees ). We can try to come back to the previous situation where all sides of clouds are drawn after the scene and rely on alpha test. There will be an ugly, not blended border around transparent patterns but It could be acceptable if it only show up at close distance. We can also begin to think about a multi pass method that would : 1. draw the clouds above the viewer without depth update, 2. draw the scene, 3 .redraw the clouds above with depth test With an impact on framerate due to double writing and problem like the one Melchior is experiencing with overlapping semi transparent objects. Haven't thought about it much of that. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
