Re: [Flightgear-devel] Shadows
Could you give some examples ? The noshadow thing is usualy used to hide some artifacts caused by transparent geometry like windows, rotating propeler disk, paintings, etc, or to reduce the complexity of the shadow (virtual cockpit or other complex parts of the plane). Harald. Hello Harald, You could be interested on what i am doing about shadow animation in the coming condition shadow. == An aircraft don't cast shadow when agl-ft 450. animation condition greater-than property/position/altitude-agl-ft/property value450/value /greater-than /condition typenoshadow/type object-nameLysander/object-name /animation == Blend on an helicopter main rotor and rotor disc working correctly :we deactivate cast of shadow from rotor when rotor rpm100 (it must be tuned) animation condition greater-than propertyrotors/main/rpm/property value100/value /greater-than /condition typenoshadow/type object-nameRotor-Princ/object-name /animation == some moving Aircraft components could cast shadow according to their positions on the Aircraft. That is an exemple on a Naval aircraft the hook will cast shadow only when it is not fully retracted. animation condition equal propertygear/tailhook/position-norm/property value0/value /equal /condition typenoshadow/type object-nameHook/object-name /animation BTW: I discovered that many aircrafts have gear components or float components (seaplane) which are not hidden when retracted (no door). They only have to cast shadow when extended. Regards -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Ampere K. Hardraade wrote: I just noticed that when one is inside an object, or the shadow volume of an object, then the shadow casted by that object is not visible. Here is an example: http://www.students.yorku.ca/~ampere/fgfs-screen-010.jpg Ampere It is because the viewer is inside a shadow volume, this breaks the so called zpass rendering. The solution to that is to use the zfail rendering for the concerned shadow volume. It's easy. What is not is to detect this situation in some efficient way and since the zfail rendering is a lot slower than the zpass we don't want to render too many volumes with zfail. It's on my todo list. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Le lundi 18 juillet 2005 à 19:17 +0200, Harald JOHNSEN a écrit : Gerard Robin wrote: == some moving Aircraft components could cast shadow according to their positions on the Aircraft. That is an exemple on a Naval aircraft the hook will cast shadow only when it is not fully retracted. I am not sure I understand this example, or perhaps I presume that what is visible should cast shadows ;p Anyway the condition is available now. The old form without condition still exists. I have also made a few changes for tranparent objects. In the rendering dialog there is a new option near the aircraft checkbox. When enabled the rendering of the aricraft transparent parts is done *after* the shadowing code. In other words the transparent parts won't hide shadows as it should be. This is how things should be and this option should be enabled by default. But. We can agree that a window or a propeler disk is transparent but for the code a transparent part is a part that uses a transparent material, ie an alpha channel in his material or in his texture. In practice you will see that the new option will break shadows on a lot of aircrafts. Just don't use rgba textures where rgb would do the same ;) Harald. About the last exemple the hook retracted stay along, outside, close to fuse. Casting shadow in that position is not useful (I found the same with B-17F gears components) when we extend the hook it clearly appears and its own shadow could be nice to activate. Everything in order to spare CPU. I will try now your updates Many thanks. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Gerard Robin wrote: == some moving Aircraft components could cast shadow according to their positions on the Aircraft. That is an exemple on a Naval aircraft the hook will cast shadow only when it is not fully retracted. I am not sure I understand this example, or perhaps I presume that what is visible should cast shadows ;p Anyway the condition is available now. The old form without condition still exists. I have also made a few changes for tranparent objects. In the rendering dialog there is a new option near the aircraft checkbox. When enabled the rendering of the aricraft transparent parts is done *after* the shadowing code. In other words the transparent parts won't hide shadows as it should be. This is how things should be and this option should be enabled by default. But. We can agree that a window or a propeler disk is transparent but for the code a transparent part is a part that uses a transparent material, ie an alpha channel in his material or in his texture. In practice you will see that the new option will break shadows on a lot of aircrafts. Just don't use rgba textures where rgb would do the same ;) Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
We can agree that a window or a propeler disk is transparent but for the code a transparent part is a part that uses a transparent material, ie an alpha channel in his material or in his texture. In practice you will see that the new option will break shadows on a lot of aircrafts. Just don't use rgba textures where rgb would do the same ;) Harald. About the last exemple the hook retracted stay along, outside, close to fuse. Casting shadow in that position is not useful (I found the same with B-17F gears components) when we extend the hook it clearly appears and its own shadow could be nice to activate. Everything in order to spare CPU. I will try now your updates Many thanks. Hello Harald, Everything is working. The results are very nice. Your idea to introduce transparency is perfect that solve the ugly effects on propdisk and the hidden effect on shadows. Thanks -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
I just noticed that when one is inside an object, or the shadow volume of an object, then the shadow casted by that object is not visible. Here is an example: http://www.students.yorku.ca/~ampere/fgfs-screen-010.jpg Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
noshadow.myobjectname or animationtypenoshadow are really the same. But I think Mathias is talking about the fact that some object parts were silently not casting shadows based on their name. Before the noshadow animation exist I was checking for names like 'disk' for example so a 'propeller.disk' was not casting shadows. But in the current cvs only the 'noshadow' name and the noshadow animation are used. Sorry for the confusion, I realize that I did not talk about this hidden 'feature'. Harald. I don't understand why that animation.xml does not work, i get no shadow on agl less than 150, it should not. Any idea? animation condition greater-than property/position/altitude-agl-ft/property value150/value /greater-than /condition typenoshadow/type object-nameLysander/object-name /animation Lysander is the whole Aircraft (group defined) -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Gerard Robin a écrit : noshadow.myobjectname or animationtypenoshadow are really the same. But I think Mathias is talking about the fact that some object parts were silently not casting shadows based on their name. Before the noshadow animation exist I was checking for names like 'disk' for example so a 'propeller.disk' was not casting shadows. But in the current cvs only the 'noshadow' name and the noshadow animation are used. Sorry for the confusion, I realize that I did not talk about this hidden 'feature'. Harald. I don't understand why that animation.xml does not work, i get no shadow on agl less than 150, it should not. Any idea? animation condition greater-than property/position/altitude-agl-ft/property value150/value /greater-than /condition typenoshadow/type object-nameLysander/object-name /animation Lysander is the whole Aircraft (group defined) Because the condition clause is not used by the *noshadow* kind of animation. The code in animation.cxx clearly show this. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
property/position/altitude-agl-ft/property value150/value /greater-than /condition typenoshadow/type object-nameLysander/object-name /animation Lysander is the whole Aircraft (group defined) Because the condition clause is not used by the *noshadow* kind of animation. The code in animation.cxx clearly show this. -Fred Yes i have seen it. (my question was rather to get some answer about the next noshadow updates depending on Harald to do list). That property should be like select and any others property. Is it any technical reasons which keep off to do it? If yes, that will reduce the advantage of that noshadow property. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Gerard Robin wrote: Yes i have seen it. (my question was rather to get some answer about the next noshadow updates depending on Harald to do list). That property should be like select and any others property. I never thought of it as a dynamic selector, maybe I am wrong. Is it any technical reasons which keep off to do it? I think it can be done, we could have a condition for dynamic selection in addition to the current static form. If yes, that will reduce the advantage of that noshadow property. Could you give some examples ? The noshadow thing is usualy used to hide some artifacts caused by transparent geometry like windows, rotating propeler disk, paintings, etc, or to reduce the complexity of the shadow (virtual cockpit or other complex parts of the plane). Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Le samedi 16 juillet 2005 à 18:22 +0200, Harald JOHNSEN a écrit : Gerard Robin wrote: Yes i have seen it. (my question was rather to get some answer about the next noshadow updates depending on Harald to do list). That property should be like select and any others property. I never thought of it as a dynamic selector, maybe I am wrong. Is it any technical reasons which keep off to do it? I think it can be done, we could have a condition for dynamic selection in addition to the current static form. If yes, that will reduce the advantage of that noshadow property. Could you give some examples ? The noshadow thing is usualy used to hide some artifacts caused by transparent geometry like windows, rotating propeler disk, paintings, etc, or to reduce the complexity of the shadow (virtual cockpit or other complex parts of the plane). Harald. Oh, yes i can. It is the result of a first approach it can be opened to discussions. == We permanently need the maximum of fps. The shadow is mainly useful when the aircraft can cast shadow on the ground. We don't need it when the aircraft is in altitude and we could deactivate shadow. May be only useful if we like to get shadow on the aircraft from itself (very significant if the texture or color clear). == In order to solve the ugly effect on the propeller disk, we could try to deactivate some aircraft objets under conditions. == cockpit view (view 1) gets shadows on the windscreen, cockpit hud it is ugly, we could deactivate it. May be others , i continu to test it. thanks -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Could you give some examples ? The noshadow thing is usualy used to hide some artifacts caused by transparent geometry like windows, rotating propeler disk, paintings, etc, or to reduce the complexity of the shadow (virtual cockpit or other complex parts of the plane). Harald. Oh, yes i can. It is the result of a first approach it can be opened to discussions. == We permanently need the maximum of fps. The shadow is mainly useful when the aircraft can cast shadow on the ground. We don't need it when the aircraft is in altitude and we could deactivate shadow. May be only useful if we like to get shadow on the aircraft from itself (very significant if the texture or color clear). == In order to solve the ugly effect on the propeller disk, we could try to deactivate some aircraft objets under conditions. == cockpit view (view 1) gets shadows on the windscreen, cockpit hud it is ugly, we could deactivate it. May be others , i continu to test it. thanks In addition to, an other exemple. the shadow goes against the blend animation. The most significant is the helicopter rotor (i did not test with bo105, which should give the same difficulties, i tested it with one of mine). Let us go. RotorDisk being defined with noshadow animation =First: we start with a 0 rpm rotor gives a good shadow on the ground. =Second: the rotor rotate to reach the operational rpm, during that period blend property decrease the rotor look and increase the RotorDisk look. One should be replaced by the second. At that stage rotor do not get the blend effect because of the shadow. =Third: operational rpm has been reached, we can see both RotorDisk and rotor, we should only see RotorDisk. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Shadows
Harald JOHNSEN wrote ... snip ... Perhaps can we use a real ogl light for the aircraft landing light and fake light for the airport lights, and since the view is centered on the aircraft the hack could be good enought. Are you going to progress OGL lights for aircraft landing lights? I'm holding off doing fake landing lights on my models pending a better solution (that's my excuse anyway :-) ) Regards V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Le mardi 12 juillet 2005 à 07:45 +0200, Mathias Fröhlich a écrit : /animation Yes. As I last looked into the shadow code, there was some heuristic based on object names which made some surfaces 'noshadow' ones. That heuristic gives me false positives with the F-18. I would vote for dropping that heuristic completely and apply the noshadow where apprioriate. Greetings Mathias Do you mean that using noshadow.myobjectname or animationtypenoshadow are the same and the consequence is noshadow.myobjectname is not useful ? -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Gerard Robin wrote: Le mardi 12 juillet 2005 à 07:45 +0200, Mathias Fröhlich a écrit : /animation Yes. As I last looked into the shadow code, there was some heuristic based on object names which made some surfaces 'noshadow' ones. That heuristic gives me false positives with the F-18. I would vote for dropping that heuristic completely and apply the noshadow where apprioriate. Greetings Mathias Do you mean that using noshadow.myobjectname or animationtypenoshadow are the same and the consequence is noshadow.myobjectname is not useful ? noshadow.myobjectname or animationtypenoshadow are really the same. But I think Mathias is talking about the fact that some object parts were silently not casting shadows based on their name. Before the noshadow animation exist I was checking for names like 'disk' for example so a 'propeller.disk' was not casting shadows. But in the current cvs only the 'noshadow' name and the noshadow animation are used. Sorry for the confusion, I realize that I did not talk about this hidden 'feature'. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
The object noshadow definition (name or animation) does not keep off that object getting the shadow from an other object. will it be any way to make it: noshadow means == not receiving shadow, in addition to the existing not transmitting shadow No that is not possible. Harald. Well, that mean, will have to choose between both following alternatives: 1/ a beautiful aircraft shadow and an ugly Propeller Disk 2/ a beautiful Propeller Disk and no shadow May be one could find an other way to simulate high speed propeller rotation, on my side, i have not any solution. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
On Sonntag 10 Juli 2005 19:32, Harald JOHNSEN wrote: BTW: i have renamed every alpha objects noshadow.. You can now use the noshadow animation in your models and reference all the parts that should not cast shadow. Examle for radio-medium.xml : animation typenoshadow/type object-nameWires.1/object-name object-nameWires.2/object-name /animation Yes. As I last looked into the shadow code, there was some heuristic based on object names which made some surfaces 'noshadow' ones. That heuristic gives me false positives with the F-18. I would vote for dropping that heuristic completely and apply the noshadow where apprioriate. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Shadows
Le dimanche 26 juin 2005 à 20:28 +0100, Vivian Meazza a écrit : There's a bit of a funny with the interaction between the Hurricane propeller disk and the ac shadow: it makes the shadow disappear, and there's something throwing a shadow on to the disk, which I've not seen in real life, although I might not have noticed it. Is there anything I can do within the ac model to tidy this up? It would be nice to assign 2 of the 8 OpenGL lights to ac landing lights. Well done indeed Vivian After a holiday break without computers, i come back. The update about shadow is great. Working perfectly with my configuration Linux 2.6.12-2 Nvidia 6600GT driver 7667 (the last one) and --bpp=24 I would like to congratulate Harald, many thanks for that. I just wonder about the fact that every alpha objects make the shadow, which is behind, disappeared (Vivian did notice it). Every AC3D users can notice that problem = the object hierarchy must be built in order to make the alpha objects (canopy, propeller disk ...) at the end of the hierarchy. If it is not, AC3D 3D-view don't show the objects which are behind these alpha objects. May be that could be an explanation and help to solve that ugly effect. Is it any hierarchy in FG view processing ? if yes, may be the shadow must be put on the top of the hierarchy BTW: i have renamed every alpha objects noshadow.. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Gerard Robin wrote: I just wonder about the fact that every alpha objects make the shadow, which is behind, disappeared (Vivian did notice it). Every AC3D users can notice that problem = the object hierarchy must be built in order to make the alpha objects (canopy, propeller disk ...) at the end of the hierarchy. If it is not, AC3D 3D-view don't show the objects which are behind these alpha objects. May be that could be an explanation and help to solve that ugly effect. Is it any hierarchy in FG view processing ? if yes, may be the shadow must be put on the top of the hierarchy Transparent objects are a pain to deal with. In a perfect world all semi-transparent objects should be draw *after* all opaque objects, they should be *sorted* by depth and drawn back to front - or if not sorted they must be draw with depth writes *disabled* (this is for true transparent surfaces, not surfaces that use an alpha mask to build their shape). The shadow post-process should be done between the drawing of opaque objects and the drawing of transparent objects because we don't want that a totaly transparent triangle stops the light (and atm it *is* stoping the light because it has changed the zbuffer). As you said modelers usually sort their model graph to handle that problem but the shadow code need the whole scene because it uses the screen zbuffer. I don't see a clear solution to this problem. BTW: i have renamed every alpha objects noshadow.. You can now use the noshadow animation in your models and reference all the parts that should not cast shadow. Examle for radio-medium.xml : animation typenoshadow/type object-nameWires.1/object-name object-nameWires.2/object-name /animation Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
I noticed another artefact : http://frbouvi.free.fr/flightsim/moving-shadow.gif ( animated gif ) When moving toward the blue building, the shadow on the nearest building face is moving and it seems dependant on the viewer's position. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Le dimanche 10 juillet 2005 à 19:32 +0200, Harald JOHNSEN a écrit : Gerard Robin wrote: transparent objects because we don't want that a totaly transparent triangle stops the light (and atm it *is* stoping the light because it has changed the zbuffer). As you said modelers usually sort their model graph to handle that problem but the shadow code need the whole scene because it uses the screen zbuffer. I don't see a clear solution to this problem. BTW: i have renamed every alpha objects noshadow.. You can now use the noshadow animation in your models and reference all the parts that should not cast shadow. Examle for radio-medium.xml : animation typenoshadow/type object-nameWires.1/object-name object-nameWires.2/object-name /animation Harald. The object noshadow definition (name or animation) does not keep off that object getting the shadow from an other object. will it be any way to make it: noshadow means == not receiving shadow, in addition to the existing not transmitting shadow -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Le dimanche 10 juillet 2005 à 19:42 +0200, Frederic Bouvier a écrit : I noticed another artefact : http://frbouvi.free.fr/flightsim/moving-shadow.gif ( animated gif ) When moving toward the blue building, the shadow on the nearest building face is moving and it seems dependant on the viewer's position. -Fred Yes i did noticed it. And i do not get shadow from the usual objects which are randomly situated on the scenery = farmhouse, house, apartment. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Gerard Robin wrote: Le dimanche 10 juillet 2005 à 19:42 +0200, Frederic Bouvier a écrit : I noticed another artefact : http://frbouvi.free.fr/flightsim/moving-shadow.gif ( animated gif ) When moving toward the blue building, the shadow on the nearest building face is moving and it seems dependant on the viewer's position. -Fred I introduced a polygon offset in my last patch (to reduce some flickering), perhaps the value is too high. If you are above 50m the effect is less visible (since we switch the near/far clip planes when above/under 50m). I can reduce the offset a bit. Yes i did noticed it. And i do not get shadow from the usual objects which are randomly situated on the scenery = farmhouse, house, apartment. Yes it's on my todo list. The object noshadow definition (name or animation) does not keep off that object getting the shadow from an other object. will it be any way to make it: noshadow means == not receiving shadow, in addition to the existing not transmitting shadow No that is not possible. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Frederic Bouvier wrote:
Harald JOHNSEN wrote :
Don't change your model for that. If it's not a problem to rename your
objects you can add
a 'noshadow' prefix to your markings, they won't caste shadow
('mydecal' = 'noshadow.mydecal').
That can makes object names a bit long. It seems to me that there are a
length limit on names in Blender.
My personal preference is to turn the shadows into an animation. It
would be a way to turn the shadows off by applying the animation.
Erik
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Ampere K. Hardraade wrote: On June 27, 2005 05:40 pm, Curtis L. Olson wrote: Yes, that's a tough one ... think about what happens when the sun is low in the sky ... an object that casts a shadow on the current view could be *way* outside the view frustum. I don't really understand how shadows work, but you'd almost have to do a complete rerendering (ssgCullandDraw) of the world from the sun's perspective to get this right ... I'm guessing that may be a bit expensive??? Curt. May be a history of the shadows can be kept, so the object that casts the shadow is not drawn, the shadow will still stay for a while? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d That wouldn't work if you were moving N or S, but at least you wouldn't see the shadow just up and disappear. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Lee Elliott wrote:
On Sunday 26 Jun 2005 23:03, Vivian Meazza wrote:
Frederic Bouvier
2 stranges things that I know are inherent to the shadow
volume technique
1. even when surfaces are smoothed, the shadows are hard and
apply to a whole quad when a fuselage shadows itself ( try
the A320, look at the airframe and press t to see what I
mean ).
Cool I didn't know about time warp ;) I'll see what I can do for that
problem.
What we see is the projected shadow that is received by the caster itself.
2. transparent surfaces ( the suspension chains of the
bridges, or the metallic structures ) produce filled
shadows.
There is no real solution for that because it's the surface that cast
shadow and not the texture.
Yes, I can see that. The markings on the Hunter are on
separate transparent object: these throw a shadow. It seems as
if I'm going to abandon that method if shadows are to be
usable with that model. Pity; it saves a huge amount of
artwork and texture.
Don't change your model for that. If it's not a problem to rename your
objects you can add
a 'noshadow' prefix to your markings, they won't caste shadow ('mydecal'
= 'noshadow.mydecal').
The edges of the shadows are a bit too
hard; a little penumbra would be good
ahem ;) so you have too much fps ? this can be done with a fragment shader.
Let wait the hardware to catch up a hit, and we could have
clouds and mountains casting shadows ;-)
We could use a simple ovale for clouds, it's just that the shadow would
be as dark as the other type
of shadows - perhaps too dark then but not sure.
Nice if aircraft could throw shadow on cloud.
I didn't enable writes in the depth buffer while rendering clouds,
that's why they don't catch shadows.
I can't remember if that gave a visual glitch or if it was just for
performance.
Altogether it's a nice enhancement.
V.
thanks ;)
Yep - I've used the same texturing technique on a few a/c as
well:( Then again, I've already stopped using it:) It did save
a lot of texture space though.
Re the 1st problem Fred referred to, it seems to happen when an
object puts itself in shadow. Shadows cast by other objects
seem to be ok. Generally, the old shading code did a good
enough job of shading each individual object in a model,
according to the sun pos, so I wonder if the new shadows might
work better if they were only applied to other objects, and let
the old code shade each individual object...
LeeE
I'll check that.
Harald.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Harald JOHNSEN wrote :
Yes, I can see that. The markings on the Hunter are on
separate transparent object: these throw a shadow. It seems as
if I'm going to abandon that method if shadows are to be
usable with that model. Pity; it saves a huge amount of
artwork and texture.
Don't change your model for that. If it's not a problem to rename your
objects you can add
a 'noshadow' prefix to your markings, they won't caste shadow
('mydecal' = 'noshadow.mydecal').
That can makes object names a bit long. It seems to me that there are a
length limit on names in Blender.
-Fred
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Another nit picking : When an object ( say a building ) is culled because it is not in the view, its shadow is also culled even if it is in the view. 2 screen shots : In the first, an oracle building cast its shadow on another one http://frbouvi.free.fr/flightsim/fgfs-shadow-1.jpg If I go forward a bit, the shadow disappear : http://frbouvi.free.fr/flightsim/fgfs-shadow-2.jpg The FOV is exagerated because it is not easy to pause exactly when it happens, but you can clearly see the shadows poping in and out when you travel between buildings. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frederic Bouvier schrieb: Another nit picking : When an object ( say a building ) is culled because it is not in the view, its shadow is also culled even if it is in the view. 2 screen shots : In the first, an oracle building cast its shadow on another one http://frbouvi.free.fr/flightsim/fgfs-shadow-1.jpg If I go forward a bit, the shadow disappear : http://frbouvi.free.fr/flightsim/fgfs-shadow-2.jpg The FOV is exagerated because it is not easy to pause exactly when it happens, but you can clearly see the shadows poping in and out when you travel between buildings. Most likely the SSG has removed the building out of the scenegraph... CU, Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFCwHLLlhWtxOxWNFcRAhzrAJ9fjl0DaxjNbwFQpfSnk1aO2zd9vACaAhnD GiO2/o8l3PU+2tZ0sX9phiY= =UN7y -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Christian Mayer wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frederic Bouvier schrieb: Another nit picking : When an object ( say a building ) is culled because it is not in the view, its shadow is also culled even if it is in the view. 2 screen shots : In the first, an oracle building cast its shadow on another one http://frbouvi.free.fr/flightsim/fgfs-shadow-1.jpg If I go forward a bit, the shadow disappear : http://frbouvi.free.fr/flightsim/fgfs-shadow-2.jpg The FOV is exagerated because it is not easy to pause exactly when it happens, but you can clearly see the shadows poping in and out when you travel between buildings. Most likely the SSG has removed the building out of the scenegraph... Yes, that's a tough one ... think about what happens when the sun is low in the sky ... an object that casts a shadow on the current view could be *way* outside the view frustum. I don't really understand how shadows work, but you'd almost have to do a complete rerendering (ssgCullandDraw) of the world from the sun's perspective to get this right ... I'm guessing that may be a bit expensive??? Ignoring some of the artifacts and that they don't work on 16bit cards, the shadows are really cool, especially the self shading of the aircraft. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
On June 25, 2005 01:49 pm, Harald JOHNSEN wrote: Paul Kahler wrote: Oh does that sound like a bad hack. What happens to objects that have specular highlights? Would the illumination be as if the sun were shining rather than the spotlight? Lighting is important, but this doesn't seem like it's physically correct at all. OTOH, fake lighting is better than no lighting ;-) Paul You are right, this is totaly incorrect lighting. For correct lighting and correct specular we should use an Opengl light for each light source. The problem is that opengl is sill slow for spot lights, and there can be more than 100 light around an airport. Of course opengl can not handle more than 8 lights in hardware (and I am not sure that it is still realtime on lot of machines) so we would have to switch ogl lights depending on the position of objects or ground geometry... a bit overkill I think. Perhaps can we use a real ogl light for the aircraft landing light and fake light for the airport lights, and since the view is centered on the aircraft the hack could be good enought. Harald. I am probably getting this wrong, but from my prespective, the purpose of specular reflection seems to give the object a waxy (and reflective) surface. Perhaps specular reflections for these fake spot lights can be done using enviromental or reflective maps? Then again, I don't see having no specular reflection for these fake lights will be much of a problem. In the air, there won't be any object that can give you specular reflections. On the ground, with the user's plane being the only aircrafts, and the lack of terminals for airports, the situation would be the same as in the air. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
On June 27, 2005 05:40 pm, Curtis L. Olson wrote: Yes, that's a tough one ... think about what happens when the sun is low in the sky ... an object that casts a shadow on the current view could be *way* outside the view frustum. I don't really understand how shadows work, but you'd almost have to do a complete rerendering (ssgCullandDraw) of the world from the sun's perspective to get this right ... I'm guessing that may be a bit expensive??? Curt. May be a history of the shadows can be kept, so the object that casts the shadow is not drawn, the shadow will still stay for a while? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Shadows
Harald JOHNSEN Paul Kahler wrote: Oh does that sound like a bad hack. What happens to objects that have specular highlights? Would the illumination be as if the sun were shining rather than the spotlight? Lighting is important, but this doesn't seem like it's physically correct at all. OTOH, fake lighting is better than no lighting ;-) Paul You are right, this is totaly incorrect lighting. For correct lighting and correct specular we should use an Opengl light for each light source. The problem is that opengl is sill slow for spot lights, and there can be more than 100 light around an airport. Of course opengl can not handle more than 8 lights in hardware (and I am not sure that it is still realtime on lot of machines) so we would have to switch ogl lights depending on the position of objects or ground geometry... a bit overkill I think. Perhaps can we use a real ogl light for the aircraft landing light and fake light for the airport lights, and since the view is centered on the aircraft the hack could be good enought. I've just seen the new volumetric shadows. Brilliant!!! On a Nvidia gForce 5200, the frame rate hit is about 10 in external view (I can live with it) and no noticeable effect in internal - perhaps 1 or 2. There's a bit of a funny with the interaction between the Hurricane propeller disk and the ac shadow: it makes the shadow disappear, and there's something throwing a shadow on to the disk, which I've not seen in real life, although I might not have noticed it. Is there anything I can do within the ac model to tidy this up? It would be nice to assign 2 of the 8 OpenGL lights to ac landing lights. Well done indeed Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Vivian Meazza a écrit : I've just seen the new volumetric shadows. Brilliant!!! On a Nvidia gForce 5200, the frame rate hit is about 10 in external view (I can live with it) and no noticeable effect in internal - perhaps 1 or 2. Yes, it is very nice. I have a drop of 10 fps ( 50 - 40 ) when I enable all ( ac + ai + to ) There's a bit of a funny with the interaction between the Hurricane propeller disk and the ac shadow: it makes the shadow disappear, and there's something throwing a shadow on to the disk, which I've not seen in real life, although I might not have noticed it. Is there anything I can do within the ac model to tidy this up? 2 stranges things that I know are inherent to the shadow volume technique : 1. even when surfaces are smoothed, the shadows are hard and apply to a whole quad when a fuselage shadows itself ( try the A320, look at the airframe and press t to see what I mean ). 2. transparent surfaces ( the suspension chains of the bridges, or the metallic structures ) produce filled shadows. Let wait the hardware to catch up a hit, and we could have clouds and mountains casting shadows ;-) Good job again. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
On Sunday 26 Jun 2005 21:53, Frederic Bouvier wrote: Vivian Meazza a écrit : I've just seen the new volumetric shadows. Brilliant!!! On a Nvidia gForce 5200, the frame rate hit is about 10 in external view (I can live with it) and no noticeable effect in internal - perhaps 1 or 2. Yes, it is very nice. I have a drop of 10 fps ( 50 - 40 ) when I enable all ( ac + ai + to ) There's a bit of a funny with the interaction between the Hurricane propeller disk and the ac shadow: it makes the shadow disappear, and there's something throwing a shadow on to the disk, which I've not seen in real life, although I might not have noticed it. Is there anything I can do within the ac model to tidy this up? 2 stranges things that I know are inherent to the shadow volume technique : 1. even when surfaces are smoothed, the shadows are hard and apply to a whole quad when a fuselage shadows itself ( try the A320, look at the airframe and press t to see what I mean ). 2. transparent surfaces ( the suspension chains of the bridges, or the metallic structures ) produce filled shadows. Let wait the hardware to catch up a hit, and we could have clouds and mountains casting shadows ;-) Good job again. -Fred Yes, very nice work. I notice a little frame-rate drop but not as much as I expected (nVidia 6600 based card). I noticed problems with prop disks too. I'm fading both the props and prop disks in and out, depending on their rpm and even when the prop disk is completely faded out a shadow from the spinners is cast on them. As the disks are faded in the shadow density upon the prop disk seems to remain constant. I imagine that varying the shadow density based on the alpha channel of the texture of the object that the shadow is cast upon would not be trivial. I also noticed that the props, before being faded out, also cast a shadow upon the still faded out prop disks but don't once they're de-selected. I noticed a few 'artifacts' in the shadows cast upon the aircraft itself but I think most of these were due to tiny irregularities in the model geometry that are normally not noticed due to smoothing i.e. tiny concavities in the model which may not be obvious but which cast shadows. The shadow of the tailfin moving across the tailplanes is fine though, as was the shadow of the wing trailing edge upon the partially deployed flaps. I don't think I've seen the problem Fred reported of entire quads being shadowed incorrectly (hmm - Fred, are you referring to four-sided polys here? Any polys with 3 sides appear to be triangulated before rendering. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Shadows
Frederic Bouvier Vivian Meazza a écrit : I've just seen the new volumetric shadows. Brilliant!!! On a Nvidia gForce 5200, the frame rate hit is about 10 in external view (I can live with it) and no noticeable effect in internal - perhaps 1 or 2. Yes, it is very nice. I have a drop of 10 fps ( 50 - 40 ) when I enable all ( ac + ai + to ) There's a bit of a funny with the interaction between the Hurricane propeller disk and the ac shadow: it makes the shadow disappear, and there's something throwing a shadow on to the disk, which I've not seen in real life, although I might not have noticed it. Is there anything I can do within the ac model to tidy this up? 2 stranges things that I know are inherent to the shadow volume technique : 1. even when surfaces are smoothed, the shadows are hard and apply to a whole quad when a fuselage shadows itself ( try the A320, look at the airframe and press t to see what I mean ). 2. transparent surfaces ( the suspension chains of the bridges, or the metallic structures ) produce filled shadows. Yes, I can see that. The markings on the Hunter are on separate transparent object: these throw a shadow. It seems as if I'm going to abandon that method if shadows are to be usable with that model. Pity; it saves a huge amount of artwork and texture. The edges of the shadows are a bit too hard; a little penumbra would be good Let wait the hardware to catch up a hit, and we could have clouds and mountains casting shadows ;-) Nice if aircraft could throw shadow on cloud. Altogether it's a nice enhancement. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
On Sunday 26 Jun 2005 23:03, Vivian Meazza wrote: Frederic Bouvier Vivian Meazza a écrit : I've just seen the new volumetric shadows. Brilliant!!! On a Nvidia gForce 5200, the frame rate hit is about 10 in external view (I can live with it) and no noticeable effect in internal - perhaps 1 or 2. Yes, it is very nice. I have a drop of 10 fps ( 50 - 40 ) when I enable all ( ac + ai + to ) There's a bit of a funny with the interaction between the Hurricane propeller disk and the ac shadow: it makes the shadow disappear, and there's something throwing a shadow on to the disk, which I've not seen in real life, although I might not have noticed it. Is there anything I can do within the ac model to tidy this up? 2 stranges things that I know are inherent to the shadow volume technique 1. even when surfaces are smoothed, the shadows are hard and apply to a whole quad when a fuselage shadows itself ( try the A320, look at the airframe and press t to see what I mean ). 2. transparent surfaces ( the suspension chains of the bridges, or the metallic structures ) produce filled shadows. Yes, I can see that. The markings on the Hunter are on separate transparent object: these throw a shadow. It seems as if I'm going to abandon that method if shadows are to be usable with that model. Pity; it saves a huge amount of artwork and texture. The edges of the shadows are a bit too hard; a little penumbra would be good Let wait the hardware to catch up a hit, and we could have clouds and mountains casting shadows ;-) Nice if aircraft could throw shadow on cloud. Altogether it's a nice enhancement. V. Yep - I've used the same texturing technique on a few a/c as well:( Then again, I've already stopped using it:) It did save a lot of texture space though. Re the 1st problem Fred referred to, it seems to happen when an object puts itself in shadow. Shadows cast by other objects seem to be ok. Generally, the old shading code did a good enough job of shading each individual object in a model, according to the sun pos, so I wonder if the new shadows might work better if they were only applied to other objects, and let the old code shade each individual object... LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
On Mon, 2005-06-20 at 18:53 +0200, Harald JOHNSEN wrote: Ampere K. Hardraade wrote: Finally, is there a potential for this technique of generating shadow to be used on generating the effects of spot lights (eg. landing light, taxi light, logo light, etc.)? You are a genius, forget my previous reply. We can't lighten pixels from the framebuffer because of the low precision (8 bits) but we can of course darken them. Algo (works better at full night) : 1) render the scene and all non emissive geometry with a 'day' ambient term 2) render all lights (or emissive geometry) and update the stencil buffer ( stencil := 1) 3) render a quad on screen to darken everything where stencil == 0 with 1 3 the scenery goes dark/black as usual with 2 the scenery in light stay illuminated Its quasi free, simple, support a million (fake) spot light ;) Oh does that sound like a bad hack. What happens to objects that have specular highlights? Would the illumination be as if the sun were shining rather than the spotlight? Lighting is important, but this doesn't seem like it's physically correct at all. OTOH, fake lighting is better than no lighting ;-) Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Paul Kahler wrote: Oh does that sound like a bad hack. What happens to objects that have specular highlights? Would the illumination be as if the sun were shining rather than the spotlight? Lighting is important, but this doesn't seem like it's physically correct at all. OTOH, fake lighting is better than no lighting ;-) Paul You are right, this is totaly incorrect lighting. For correct lighting and correct specular we should use an Opengl light for each light source. The problem is that opengl is sill slow for spot lights, and there can be more than 100 light around an airport. Of course opengl can not handle more than 8 lights in hardware (and I am not sure that it is still realtime on lot of machines) so we would have to switch ogl lights depending on the position of objects or ground geometry... a bit overkill I think. Perhaps can we use a real ogl light for the aircraft landing light and fake light for the airport lights, and since the view is centered on the aircraft the hack could be good enought. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
On Freitag 17 Juni 2005 21:02, Harald JOHNSEN wrote: I have started to add some volumetric shadows in Flightgear. It uses the standard stencil method to count shadow volume (let me know if you want an implementation without stencil, it can also be done with the alpha buffer). A few days ago I thought that it would be overkill for the processor or the graphic card to add this effect, but with a few optimisations the impact on frame rate - while still noticeable - is acceptable. I can render the Concorde with a debug build so all is not lost if your computer is not 10 years old. Some screenshots here : http://sites.estvideo.net/tipunch/flightgear/lab/shadows.html Let me know what you think of that. nb: only the AC is casting shadows atm, I still need to verify how are handled other objects in the scene graph (tile objects, AI objects, etc). Great work I am looking forward to that!! Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Ampere K. Hardraade wrote: Finally, is there a potential for this technique of generating shadow to be used on generating the effects of spot lights (eg. landing light, taxi light, logo light, etc.)? You are a genius, forget my previous reply. We can't lighten pixels from the framebuffer because of the low precision (8 bits) but we can of course darken them. Algo (works better at full night) : 1) render the scene and all non emissive geometry with a 'day' ambient term 2) render all lights (or emissive geometry) and update the stencil buffer ( stencil := 1) 3) render a quad on screen to darken everything where stencil == 0 with 1 3 the scenery goes dark/black as usual with 2 the scenery in light stay illuminated Its quasi free, simple, support a million (fake) spot light ;) Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Harald JOHNSEN wrote: I have started to add some volumetric shadows in Flightgear. It uses the standard stencil method to count shadow volume Wow, nice work. How are you handling silhouette optimization? For those interested, the basic idea behind stencil shadows is that, for every triangle in the input mesh, you render three infinitely long triangles from the sides of the original to a point along the line leading away from the light source. So the number of vertices you need to push goes up by a factor of four, and the number of pixels you need to fill goes up by a *lot* -- each small original triangle gets smeared all the way out to the edge of the screen in the shadow edges. I did a prototype stencil shadow engine about two years ago, and saw something like a 15x slowdown when stenciling was enabled. The standard way to optimize this involves detecting which triangles are on the silhouette of the object*, because those are the only ones which define the shadow volume. Since the silhouette is a 1D feature, and the polygon mesh is 2D, the number of edges on the silhouette goes roughly as the square root of the object's polygon count; so this can be a really important optimization. * Stated exactly: the silhouette is a subset of triangle pairs sharing an edge where one triangle is front-facing with respect to the light source, and the other is back-facing may be on the silhouette. The problem is that detecting this silhouette (or at least an approximation) in a situation where the object and light source can have any orientation is a big mess, and I never found a good way to do it. Lots of really complicated code got me nowhere. Basically, the whole experience convinced me that a shadow buffer approach, which is *much* simpler conceptually (just draw the thing into a texture from the point of view of the light source), was a better idea. Shadow buffers don't need the really complicated silhouette optimization work to make them run fast. It is true that shadow buffers don't work for self-shadowing objects (shadow of the vertical stabilizer on the wing, etc...), though. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Andy Ross wrote: * Stated exactly: the silhouette is a subset of triangle pairs sharing an edge where one triangle is front-facing with respect to the light source, and the other is back-facing may be on the silhouette. There is a pre process step where I look for the 2 triangles that share an edge. For rendering we only consider triangles facing the light. For each of its 3 egdes we check if the neighbour triangle is facing the light or not. The edge shared by 2 triangles facing the light is not a silouhette edge, if the neighbour triangle is not facing the light (or does not exist) then this edge is a silouhette. The problem is that detecting this silhouette (or at least an approximation) in a situation where the object and light source can have any orientation is a big mess, and I never found a good way to do it. Lots of really complicated code got me nowhere. The idea is to use a light in model space, not in world space. So if the object move it's like if the light was moving in the opposite direction. When I compute the silouhette for an object I climb the scene graph to find all the ssgtransform node and then I use the inserve matrix to rotate my light vector. The translation part of this matrix is nullified since the sun if far way I do as if the sun was moving with the object. The silhouette computation is only done when my sun vector change enought and I cache the list of silouhette edges so the cpu is not too stressed every frame while nothing changes. Basically, the whole experience convinced me that a shadow buffer approach, which is *much* simpler conceptually (just draw the thing into a texture from the point of view of the light source), was a better idea. Shadow buffers don't need the really complicated silhouette optimization work to make them run fast. It is true that shadow buffers don't work for self-shadowing objects (shadow of the vertical stabilizer on the wing, etc...), though. Andy I started a prototype before using hardware shadow maps. You are right it's a lot simpler, but it can't run on all hardware (and nvidia don't have the shadow ambient extension so shadows would be black...) and I think that shadows should be available to all users. And of course shadow maps a problem of pixelisation. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Harald JOHNSEN wrote: There is a pre process step where I look for the 2 triangles that share an edge. You're doing that per frame? Does it work well? I saw a huge CPU hit from that test, but that was about 2.5 years ago on a slower machine than is available now. Is the code complete enough to provide performance numbers? The silhouette computation is only done when my sun vector change enought and I cache the list of silouhette edges so the cpu is not too stressed every frame while nothing changes. If I understand you correctly, this has a glitch: the failure mode is that you find an orientation where a new silhouette edge should have been added but wasn't, and suddenly the shadow has a hole in it that looks like a big diagonal streak across the screen. What I started trying to do was pre-cache multiple sets of silhouette triangles for different orientations and using the union of all the ones needed so I was guaranteed to never miss an edge. But then you're required to cache and store (presumably in OpenGL display lists) *many* times more polygons than the object actually has. I forget the numbers, but they were pretty big. Anyway, if you made all that work or found a simpler solution, then I salute you and look forward to seeing the code. This stuff can be really fun. I started a prototype before using hardware shadow maps. You are right it's a lot simpler, but it can't run on all hardware (and nvidia don't have the shadow ambient extension so shadows would be black...) All modern hardware can do them; remember that only high end machines will be able to do the stenciling also. And the ambient extension isn't all that useful for a flight simulator. The only thing we really care about shadowing is sunlight, which is white by definition. (And even then, you can still do colored shadows without it, just not as fast, using an extra pass or two). Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Ampere K. Hardraade wrote: Forgive my annoyance, but here are a few more questions. =) First of all, I am seeing a potential problem when the sun is below the horizon (during dawn and dusk) and doesn't cast any shadow onto the ground. Does your code handle this special case at the moment? If so, how? Shadows must be disabled when the sun is below the horizon because of course there should not be shadows (or if we want shadows we could use the moon to replace the sun but this is not usefull atm since the night lighting is too dark, we could calculate the light casted by the moon depending on its phase but I am not sure it's worth it in a non military simulation) and also because drawing horizontal shadows for all scenery objects could kill the frame rate for fill rate limited cards. The sun-angle property is used to switch shadows on/off, it is also used to compute how much we need to 'darken' the background. Secondly, do objects with illumination (such as the flame from the f-16's exhaust) disrupt shadows? We have two problems here. First the flame will cast shadow because the geometry is like any other light occluder. Second the flame will be shadowed. The first case can perhaps be solved with some tag in the object to tell it not to cast shadow (a kind of 'noshadow' branch in the object tree). I don't see a simple solution for the second case, but perhaps it's not a real problem if the emissive light is hight enought, the shadow could be hardly visible. Finally, is there a potential for this technique of generating shadow to be used on generating the effects of spot lights (eg. landing light, taxi light, logo light, etc.)? I don't think it's possible. In modern games that do shadows the scene is rendered at least two times. In the first pass the scene is rendered with only ambient term. Then shadows are computed in the stencil. Then the second pass is done with all lightings (ambient term, lights contribution, specular term) with stencil test enabled to touch only non shadowed parts of the scene. This is the way to do correct illumination. In FG there is only one light and nearly no specular effect visible so the rendering is a bit different (in order not to render the scene two times). First the scene is rendered as usual with full lighting (ambient, light, specular), then shadows are computed in the stencil, then the stencil mask is blended on the screen to darken the shadowed parts. So to be clear for shadows I darken the pixels on screen, if we use the same technique for spotlight that mean we will lighten pixels, this will produce really bad result in totaly dark scene. And the same effect could be done with a cone, just using another blending equation. To have real lights in the dark the stencil should contain the spot volume, the scene should be rendered with normal night illumination outside the spot, then the scene should be rendered again with day light illumination inside the spot volume. I don't know if I am very clear... Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Would the buildings cast shadows ? What about creating a new animation type that will specify objects ( branches ) that cast shadows and objects that do not ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
http://sites.estvideo.net/tipunch/flightgear/lab/shadows.html Let me know what you think of that. Wow, that looks great. How much of a frame rate hit did you get? Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Harald JOHNSEN wrote: I have started to add some volumetric shadows in Flightgear. It uses the standard stencil method to count shadow volume (let me know if you want an implementation without stencil, it can also be done with the alpha buffer). A few days ago I thought that it would be overkill for the processor or the graphic card to add this effect, but with a few optimisations the impact on frame rate - while still noticeable - is acceptable. I can render the Concorde with a debug build so all is not lost if your computer is not 10 years old. Some screenshots here : http://sites.estvideo.net/tipunch/flightgear/lab/shadows.html Let me know what you think of that. nb: only the AC is casting shadows atm, I still need to verify how are handled other objects in the scene graph (tile objects, AI objects, etc). Looks awsome! It's probably worth adding especially if we can let the users turn it off/on to tune their own performance. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Harald JOHNSEN wrote: I have started to add some volumetric shadows in Flightgear. Here's a real life airplane shadow (shadow is at the end of the runway) from my flying adventure yesterday evening ... http://www.flightgear.org/~curt/Models/Current/EGN-1/Flying/Link/img_2637.html And ... http://www.flightgear.org/~curt/front-image-1.jpg Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
On June 17, 2005 03:02 pm, Harald JOHNSEN wrote: I have started to add some volumetric shadows in Flightgear. It uses the standard stencil method to count shadow volume (let me know if you want an implementation without stencil, it can also be done with the alpha buffer). A few days ago I thought that it would be overkill for the processor or the graphic card to add this effect, but with a few optimisations the impact on frame rate - while still noticeable - is acceptable. I can render the Concorde with a debug build so all is not lost if your computer is not 10 years old. Some screenshots here : http://sites.estvideo.net/tipunch/flightgear/lab/shadows.html Let me know what you think of that. nb: only the AC is casting shadows atm, I still need to verify how are handled other objects in the scene graph (tile objects, AI objects, etc). Harald. Finally, there is shadow in FlightGear. =) Couple of questions: Do the authors of the aircrafts have to specify the objects that can cast shadow, or is it all done automatically? On aircrafts that have multiple level of details, such as the MD-11, majority of the objects are made invisible. If these invisible objects cast shadow as well, it might produce huge overhead. Is your code intelligent enough to leave these invisible objects out of the calculations? Unlike other aircrafts where everthing is put into a single mesh file, the A380 model is split into multiple files to allow meshes of different format to work together. Does shadow work on the A380? Finally, what is the minimal graphic card requirment to be able to see shadow? Thanks, Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
I have started to add some volumetric shadows in Flightgear. Does the canopy frame cast a shadow on the cockpit interior? Do transparent surfaces cast shadows? ( I don't mean to be annoying, just curious. This would add a whole new level of realism to 3D cockpits :) Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Harald JOHNSEN wrote: I can render the Concorde with a debug build so all is not lost if your computer is not 10 years old. Some screenshots here : http://sites.estvideo.net/tipunch/flightgear/lab/shadows.html Let me know what you think of that. I don't even think of flying the Concorde even without any bells 'n whistles Do you need _any_ changes to the aircraft models (like Melchior did for the BO-105) or does it just work right out of the box with the existing models ? Anyway, this looks really great and I think your effort is definitely worth being added to FG, maybe switched off by default - for users like me :-) with a property to toggle it on demand Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Ampere K. Hardraade wrote: Finally, there is shadow in FlightGear. =) Couple of questions: Do the authors of the aircrafts have to specify the objects that can cast shadow, or is it all done automatically? It's automatic. All sub models of the aircraft (the ssg Vtx nodes) are preprocessed to extract the edges used by the shadow computation. On aircrafts that have multiple level of details, such as the MD-11, majority of the objects are made invisible. If these invisible objects cast shadow as well, it might produce huge overhead. Is your code intelligent enough to leave these invisible objects out of the calculations? This case is handled, I check the value of the ssgSelector in the object tree so select and range animations are correctly rendered. Unlike other aircrafts where everthing is put into a single mesh file, the A380 model is split into multiple files to allow meshes of different format to work together. Does shadow work on the A380? It should be ok if all your files are tied to the aircraft branch in the scene graph. Finally, what is the minimal graphic card requirment to be able to see shadow? It's hard to say, I just changed my graphic card but with the previous one - a Ti 4200 - I was not under the impression that I was fill rate limited. But the cpu has some impact too. There is a few computation needed to determine what to draw. The result of this computation is cached and updated when needed (when the sun moves or when an animation is doing a rotation for example). At the end it all depends on the model used, the Concord has like 30.000 polys, the c172p has less than 2000 polys. Dave Culp wrote: Does the canopy frame cast a shadow on the cockpit interior? Yes ;) Do transparent surfaces cast shadows? ( I don't mean to be annoying, just curious. This would add a whole new level of realism to 3D cockpits :) I didn't do anything special for transparent surface atm. So yes they cast shadows but I can't tell if this is a good or a bad thing. Martin Spott wrote: Do you need _any_ changes to the aircraft models (like Melchior did for the BO-105) or does it just work right out of the box with the existing models ? It's a bit early to reply that question. Perhaps we need to make the current model shadows conditioned by a property so that we have either the volumetric shadow or the one from the model. Anyway, this looks really great and I think your effort is definitely worth being added to FG, maybe switched off by default - for users like me :-) with a property to toggle it on demand Yes of course it will be optional ;) Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Shadows
Harald JOHNSEN I have started to add some volumetric shadows in Flightgear. It uses the standard stencil method to count shadow volume (let me know if you want an implementation without stencil, it can also be done with the alpha buffer). A few days ago I thought that it would be overkill for the processor or the graphic card to add this effect, but with a few optimisations the impact on frame rate - while still noticeable - is acceptable. I can render the Concorde with a debug build so all is not lost if your computer is not 10 years old. Some screenshots here : http://sites.estvideo.net/tipunch/flightgear/lab/shadows.html Let me know what you think of that. nb: only the AC is casting shadows atm, I still need to verify how are handled other objects in the scene graph (tile objects, AI objects, etc). Looks great, now some penumbra would be nice ... just teasing ... Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
On Friday 17 Jun 2005 20:02, Harald JOHNSEN wrote: I have started to add some volumetric shadows in Flightgear. It uses the standard stencil method to count shadow volume (let me know if you want an implementation without stencil, it can also be done with the alpha buffer). A few days ago I thought that it would be overkill for the processor or the graphic card to add this effect, but with a few optimisations the impact on frame rate - while still noticeable - is acceptable. I can render the Concorde with a debug build so all is not lost if your computer is not 10 years old. Some screenshots here : http://sites.estvideo.net/tipunch/flightgear/lab/shadows.html Let me know what you think of that. nb: only the AC is casting shadows atm, I still need to verify how are handled other objects in the scene graph (tile objects, AI objects, etc). Harald. That looks very very good:) LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Forgive my annoyance, but here are a few more questions. =) First of all, I am seeing a potential problem when the sun is below the horizon (during dawn and dusk) and doesn't cast any shadow onto the ground. Does your code handle this special case at the moment? If so, how? Secondly, do objects with illumination (such as the flame from the f-16's exhaust) disrupt shadows? Finally, is there a potential for this technique of generating shadow to be used on generating the effects of spot lights (eg. landing light, taxi light, logo light, etc.)? Thanks, Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
On Wednesday 12 May 2004 20:04, Andy Ross wrote: Lee Elliott wrote: Was the stencil shadow stuff for generating object shadows? How far off usable was it, and did it only work with your terrain engine? It was decidedly demo quality. But it was part of the model code, not the terrain engine. Doing shadows on terrain is sort of a 2D problem, and actually a little simpler (computationally faster, if not algorithmically easier) than doing a full-on general shadow implementation. Basically, there are two general techniques for doing shadows with 3D hardware: The first is to draw the object casting the shadow into a 1-bit-plus-depth shadow buffer from the point of view of the light source. You then use this buffer as a modulating texture for the light source when drawing the objects on which the shadow falls. This is a relatively straightforward process (although it requires some form of rendering to a texture, which wasn't standardized in OpenGL until recently) and works fast. The problems are that the resolution is limited to what you pick for the texture, so you can see pixelation effects if the viewer is close to an object which is far from the shadow caster. More seriously, you cannot use this technique for objects which cast shadows on *themselves* since the depth information in the shadow buffer isn't precise enough. Stenciling is the other trick. This is a geometric technique where you draw the shadow volume of an object into the stencil buffer. For each triangle, for example, you draw a tetrahedron containing its vertices and a vertex projected infinitely far away from the light source. You then use some nifty tricks involving the stencil buffer to tell which screen pixels are lit by the light source. This is a great technique, and works correctly in a very nice general way for every surface on the screen. It's also abysmally slow when implemented naively. Every (!) polygon ends up beign drawn as a big swath from its real position to one edge of the screen. This eats fill rate like there's no tomorrow. Production implementation need to do lots of bookeeping work to optimize the shadow volume such that only polygons on the silouette of the object are drawn (others are essentially useless). This is the part I didn't finish. :) Andy Thanks for the info. It's something I've wondered about, in a 'how do they do that?' sort of way, but it's a bit beyond my programming ability to do anything practical about it. Something to look forwards to, perhaps;) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Shadows and joysticks
I use a Saitek Cyborg 3D Rumble Force, and it is better than any other PC joystick I have used (not that many in the comparison group though, and no MS products). OK, so the rumble effect doesn't get used in FG, but it is a very nice indication of WOW in IL2, and if plib ever gets to support force feedback devices, it would be nice in FG too. Richard -Original Message- From: Lawrence Manning [mailto:[EMAIL PROTECTED] Sent: 23 June 2003 9:57 pm To: [EMAIL PROTECTED] Subject: [Flightgear-devel] Shadows and joysticks First post to this list... been playing with fg for a few weeks now and I have to say I'm very impressed. It runs super on my 2ghz AMD linux box with Geforce 4 gfx and the Nvidia drivers. Ok, questions... First of all, are there any plans to implement shadows? A shadow of the aircraft over the ground would obviously make judging the height visually much easier, and add to the realism. Of course, the ultimate is to make it so mountains and the scenery itself can cast shadows, even into the cockpit of the 'plane! But a good start would be aircraft shadows. I haven't a clue how feasable this is, and the question has probably been asked many times before, but here's me asking anyway. The second question is to ask if anyone can recommend a good joystick for flightgear use? The only thing it will be used for is fg. Not after anything too flashy; just needs the additional rudder and throttle controls. A friend recommened one of the Microsoft sticks, so I'm inclined to go for that (say all you like about MS, but they make good hardware! I love my MS optical mouse). I haven't bought a joystick since they used 9 pin D-type connectors and did 4 digital directions and a firebutton, so any guidance anyone can give would be great. Anyway, thanks for the superb software. :) I look forward to future versions and helping in any way I can. Lawrence ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ __ This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk __ __ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Shadows and joysticks
Lawrence Manning [EMAIL PROTECTED] said: First post to this list... been playing with fg for a few weeks now and I have to say I'm very impressed. It runs super on my 2ghz AMD linux box with Geforce 4 gfx and the Nvidia drivers. Thanks for the good words! First of all, are there any plans to implement shadows? A shadow of the aircraft over the ground would obviously make judging the height visually much easier, and add to the realism. Of course, the ultimate is to make it so mountains and the scenery itself can cast shadows, even into the cockpit of the 'plane! But a good start would be aircraft shadows. I haven't a clue how feasable this is, and the question has probably been asked many times before, but here's me asking anyway. This has been discussed, but not developed yet. It probably wouldn't be difficult to do an aircraft shadow. The second question is to ask if anyone can recommend a good joystick for flightgear use? The only thing it will be used for is fg. Not after anything too flashy; just needs the additional rudder and throttle controls. A friend recommened one of the Microsoft sticks, so I'm inclined to go for that (say all you like about MS, but they make good hardware! I love my MS optical mouse). I haven't bought a joystick since they used 9 pin D-type connectors and did 4 digital directions and a firebutton, so any guidance anyone can give would be great. The more expensive Microsoft sidewinders (Precision 2) are quite good. One caveate: for some people (including myself) there have been some problems with static electricity buildup with the Precision 2 USB. Microsoft has been aware of the issue, but perhaps it hasn't been frequent enough to require a redesign. Last I checked (4 months ago) the problem was still there. The symptom is that the stick will no longer be recognized. The cure from MS tech support is a somewhat abusive sounding process that involved repeatedly plugging and unplugging the stick into your computer's USB ports. Eventually the stick becomes damaged and won't recover using that procedure. If you want to risk it, you might fall into the majority of people that don't experience the problem. It seems to have something to do with the computer you plug it into (I tried three of the same model stick), but Microsoft doesn't offer any guidelines as which motherboards/USB ports have the problem. Currently I'm using a Saitek X45 and find it to be very nice. I also think Saitek's Cyborg's are supposed to be pretty good and a little less expensive. If you have a game port you might even want to pickup a Microsoft Precision Pro. It's older technology but they are very good quality and seem to last forever. New ones have been selling on ebay for $5-10. As far as MS hardware being good, I'm not sure about that one way or the other, at least in a general sense. Their more recent keyboards, for example, are lighter and don't seem to hold up as well as the older ones. Just the same, there is no doubt that they have made some good quality products. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Shadows
At 3/17/03, Jim Wilson wrote: Jon Berndt [EMAIL PROTECTED] said: Has anyone ever considered implementing aircraft shadows projected on the ground? Jon How about cheating? Add a rectangle under the aircraft, map a fuzzy silhouette texture onto it and animate it down to ground level (translate it based on AGL). Above 50m AGL you'd have to offset up a little to keep it above the terrain. If the sun angle is in the property tree that could be used to reposition slightly, although low angles (long shadows) would not be possible with the current capability. Very good idea. The shadow could be added to the model file as an extra object (w/ a transparent dark texture in the shape of the aircraft top view) which is then animated so that's always positioned on the ground relative to the aircraft. The alternative is to add a second model and animate that relative to the aircraft. I don't know if there's a way to load in two aircraft (i.e. the second model). This latter approach would be better because one would not have to modify the current aircraft model files. Regards, Michael ___ 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
Re: [Flightgear-devel] Shadows
Michael Selig [EMAIL PROTECTED] said: Very good idea. The shadow could be added to the model file as an extra object (w/ a transparent dark texture in the shape of the aircraft top view) which is then animated so that's always positioned on the ground relative to the aircraft. The alternative is to add a second model and animate that relative to the aircraft. I don't know if there's a way to load in two aircraft (i.e. the second model). This latter approach would be better because one would not have to modify the current aircraft model files. There are a couple ways. One easy enough method would be to just add it like the 3D instruments are added to the j3 (each is a separate model). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Shadows
- Original Message - From: Jon Berndt [EMAIL PROTECTED] To: Flightgear-Devel [EMAIL PROTECTED] Sent: Monday, March 17, 2003 7:24 AM Subject: [Flightgear-devel] Shadows Has anyone ever considered implementing aircraft shadows projected on the ground? I tried to work not with shadows but with light lobes but It requres multitexturing that PLIB NOT support and I think that will not support in nearest future. FlightGear is tightly connected with PLIB and Curtis IMHO will not release FlightGear w/o released PLIB with multitexturing Lets hope that OpenGL2.0 will come out in nearest future and Steve Baker start to work on implementing newest coolest shaders and other stuff in PLIB. Now only one opensoure scenegraph support multitexturing+newest shaders techniques - OpenSceneGraph Roman Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Shadows
Roman Grigoriev wrote: I tried to work not with shadows but with light lobes but It requres multitexturing that PLIB NOT support and I think that will not support in nearest future. FlightGear is tightly connected with PLIB and Curtis IMHO will not release FlightGear w/o released PLIB with multitexturing Lets hope that OpenGL2.0 will come out in nearest future and Steve Baker start to work on implementing newest coolest shaders and other stuff in PLIB. Now only one opensoure scenegraph support multitexturing+newest shaders techniques - OpenSceneGraph Did you take a look at the water demo of plib? It uses multitexturing without build-in support from plib. plib/examples/src/ssg/water Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Shadows
- Original Message - From: Erik Hofman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, March 17, 2003 12:25 PM Subject: Re: [Flightgear-devel] Shadows Roman Grigoriev wrote: I tried to work not with shadows but with light lobes but It requres multitexturing that PLIB NOT support and I think that will not support in nearest future. FlightGear is tightly connected with PLIB and Curtis IMHO will not release FlightGear w/o released PLIB with multitexturing Lets hope that OpenGL2.0 will come out in nearest future and Steve Baker start to work on implementing newest coolest shaders and other stuff in PLIB. Now only one opensoure scenegraph support multitexturing+newest shaders techniques - OpenSceneGraph Did you take a look at the water demo of plib? It uses multitexturing without build-in support from plib. plib/examples/src/ssg/water Yes, but you can't specify second texture's coordinates - It uses texgen I can work with second texture, Maqrten Stronberg gave multitexture patch to me at Summer 2002, but as you see there is no multitexture in PLIB CVS That's too sad :((( Roman Erik ___ 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
Re: [Flightgear-devel] Shadows
Jon Berndt [EMAIL PROTECTED] said: Has anyone ever considered implementing aircraft shadows projected on the ground? Jon How about cheating? Add a rectangle under the aircraft, map a fuzzy silhouette texture onto it and animate it down to ground level (translate it based on AGL). Above 50m AGL you'd have to offset up a little to keep it above the terrain. If the sun angle is in the property tree that could be used to reposition slightly, although low angles (long shadows) would not be possible with the current capability. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Shadows
Roman Grigoriev wrote: Yes, but you can't specify second texture's coordinates - It uses texgen I can work with second texture, Maqrten Stronberg gave multitexture patch to me at Summer 2002, but as you see there is no multitexture in PLIB CVS Didn't we go through this before? What you want to do with light lobes will work just fine with texgen and the texture matrix. You don't want to be computing your own texture coordinates when there are already features available to have the GPU do it for you. And as Erik points out, Plib is extensible. Write your own ssg node object and do anything you want in there. You're not limited by what you get out of the box. Andy -- Andrew J. RossBeyond the OrdinaryPlausibility Productions Sole Proprietor Beneath the Infinite Hillsboro, OR Experience... the Plausible? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Shadows
Jim Wilson wrote: How about cheating? Add a rectangle under the aircraft, map a fuzzy silhouette texture onto it and animate it down to ground level (translate it based on AGL). Above 50m AGL you'd have to offset up a little to keep it above the terrain. That would work very well for the (exceedingly) common case of an aircraft in a level attitude projecting a shadow on flat ground beneath it. Even the lighting would work correctly as long as the ground is flat (just pre-calculate an ambient color for flat ground and use blending to interpolate between the pre-existing frame buffer contents and this color). Getting a tiny bit fancier, you could pre-render this shadow map into a texture at load time. No need to do it per frame. And I've read stuff about people using texture LOD bias (an extension that forces use of different mipmap levels than normal) to get cheap soft shadows. The closest way to a correct way to do this is to render a shadow map from the light's perspective into a texture every frame, and multitexture it onto the shadowed geometry during render. This works for everything but self-shadowing (engine nacelles casting shadows on the wing, etc...), for which you need to use stencil. Stencil shadows are a big pain, and very difficult to make fast. I've been playing with these on my own project for the last few days; I'm pretty sure it's worth it, but it's not cheap. Andy -- Andrew J. RossBeyond the OrdinaryPlausibility Productions Sole Proprietor Beneath the Infinite Hillsboro, OR Experience... the Plausible? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Shadows
How about cheating? Add a rectangle under the aircraft, map a fuzzy silhouette texture onto it and animate it down to ground level (translate it based on AGL). Above 50m AGL you'd have to offset up a little to keep it above the terrain. Good idea, but how do you map the silhouette? It would be nice to see the aircraft's shadow change in a roll, for instance, so you can't use a static silhouette. Also, don't forget clouds -- if there are any, the silhouette has to be above them. How about this: after all scenery and clouds have been drawn, and before drawing the aircraft and panel, simply redefine the view/transform matrices so as to create a parallel projection that looks at the aircraft from the opposite direction of where the sun is -- i.e. the sun is behind the aircraft. Then draw the aircraft without any lighting, in plain grey, on top of the scenery with alpha-blending. This will darken out the shadow of the aircraft. Andras === Major Andras e-mail: [EMAIL PROTECTED] www:http://andras.webhop.org/ === ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] shadows that wings cast on the ground
Norman Vine [EMAIL PROTECTED] said: Michael Selig writes: External 3D views, hangars, trees. With the graphics, might shadows be next, such as shadows that wings cast on the ground? Here is an 'excellent' recent paper on shadows 'done right' if anyone wants to play :-) http://www-sop.inria.fr/reves/publications/data/2002/SD02/?LANG=gb Note IMHO if we are going to have shadows EVERYTHING needs a shadow .. Great article! The only thing is that it'd probably be best to develope plain vanilla shadow maps and then add this on as an option. It would appear that the performance cost would be high. But it's interesting to see what the near future holds (when we start throwing out our 1GHZ cpu's because they are too slow and geForce3 cards are under $100 because nVidia finally has real competition). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] shadows that wings cast on the ground
Michael Selig writes: External 3D views, hangars, trees. With the graphics, might shadows be next, such as shadows that wings cast on the ground? Here is an 'excellent' recent paper on shadows 'done right' if anyone wants to play :-) http://www-sop.inria.fr/reves/publications/data/2002/SD02/?LANG=gb Note IMHO if we are going to have shadows EVERYTHING needs a shadow .. Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
