F-20 development

[Flying toaster]

Uh Oh .... I realise that the redish glow you see in the non afterburning shot is due to the ambient light lighting up the afterburner duct when it really should be obscured

I guess I should try to do something about it (for instance shut the ambient light on the object if the sun is setting)

[Thorsten]

Actually I also hypothesise that in my previous post

So you did. I'm sorry, I overlooked that.

I guess I should try to do something about it (for instance shut the ambient light on the object if the sun is setting)

Don't go there in the model design. The model gets to adjust the color and texture of an object, the rendering framework gets to decide upon the light - that's the convention. And it makes sense.

Consider - ALS is going to render precisely the same model. But ALS does not have colored ambient light at all, only directional light has color, and that fades quickly after sundown. So if you kill the ambient color channel to fix the appearance in default, you'll almost inevitably mess up the appearance in ALS.

And there are lighting situations which you might not have anticipated - underneath a cloud shadow, directional light is gone for instance. Rembrandt can give you mountains casting shadows. You can't anticipate all of those and you can't xml-check on them, because we only really check within the rendering pipeline.

[abassign]

I noticed that the condensation and the trails are visible even at night. Of course it is not possible, it should correct the declaration "<Particlesystem>" from this code:

Code: Select all

<PropertyList>
   <particlesystem>
...
      <emissive>true</emissive>
      <lighting>true</lighting>


to this code:

Code: Select all

<PropertyList>
   <particlesystem>
...
      <emissive>false</emissive>
      <lighting>false</lighting>


This also applies to the other statements of particles that do not emit their own light.

[Flying toaster]

I noticed that the condensation and the trails are visible even at night.....

Thanks for the tip, I'll fix that right away

So you did. I'm sorry, I overlooked that.

Nevermind I was just kidding

Regarding what I should do and what I should not do in model design I must admit I am a bit lost. For instance ALS screws the reflection maps bad time, Rembrandt screws emissivity also bad time and textures need compensation because they look waayyy too dark.
I love Rembrandt because I don't have to do all the hassle about lightmaps and shadows are really a helper to mesure your height above the ground (plus it looks so much more realistic), I love ALS because of the lovely skies and I love the default renderer because it gets very decent FPS on my old wreck and still gets almost everything right... But any time I chose one eye candy provider I loose on another front,.
Don't get me wrong I am happy everything is available and I am sure the core gfx developpers are working hard to get everything to converge (wish I could help), but in the current situation it is hard to know what to do to make the model look good (or at least as expected) for each of those gfx rendering modes, because I really mean it to be as enjoyable as possible with Rembrandt, ALS et al. ... Any pointers ?

[Thorsten]

For instance ALS screws the reflection maps bad time ...Any pointers ?

You should perhaps start by telling me, because if you're using model-combined.eff, it's supposed to be supported just fine - and if not, it needs to be fixed. Which I can't do without a bug report (all planes I have tested reflect just fine in ALS, but I haven't tested everything of course). So, do we have a screenshot and the *.eff file you use?

I love Rembrandt because I don't have to do all the hassle about lightmaps and shadows are really a helper to mesure your height above the ground (plus it looks so much more realistic), I love ALS because of the lovely skies and I love the default renderer because it gets very decent FPS on my old wreck and still gets almost everything right... But any time I chose one eye candy provider I loose on another front,

Well, the GPU to give you high framerate, the full atmosphere and shadows isn't invented yet. Which is why you need to make a choice what your graphics card should do. The plain fact of the matter is that we have only so and so many GPU cycles, and if you try to do everything, you end up rendering still images.

but in the current situation it is hard to know what to do to make the model look good (or at least as expected) for each of those gfx rendering modes

White light is the same in all frameworks. I think what you need to do is provide a model that renders fine in white directional light (= at noon) and leave it to the rendering frameworks to get the rest. If a model doesn't render okay at low light, I usually see this as my problem and try to fix it.

The issue with default (and possibly Rembrandt) is admittedly that there isn't currently much maintenance happening, but I think you might still try to talk Erik into adjusting the light curves for the sun below the horizon.

[hvengel]

I have been using model-combined.eff for reflection (bare aluminum skin) and normal maps (rivets/screws/panels seams..) and with the "model" effects setting turned up in the effects menu the aircraft's skin looks almost exactly the same in all three rendering modes. If the reflection maps are not working in ALS then it is likely that model-combined.eff is not being used.

[Flying toaster]

You should perhaps start by telling me, because if you're using model-combined.eff, it's supposed to be supported just fine - and if not, it needs to be fixed. Which I can't do without a bug report (all planes I have tested reflect just fine in ALS, but I haven't tested everything of course). So, do we have a screenshot and the *.eff file you use?

Err you got me on that one ... I use a hand made effect file (makes me feel a bit silly )

Code: Select all

<PropertyList>

 <name>Aircraft/F-20/Models/SpecialLiveries/dutch-mirror</name>   
 <inherits-from>Effects/reflect</inherits-from>
 <parameters>
    <texture n="8">
     <image>Aircraft/F-20/Models/SpecialLiveries/dutch-mirror.png</image>
     <filter>linear-mipmap-linear</filter>
     <wrap-s>repeat</wrap-s>
     <wrap-t>repeat</wrap-t>
     <internal-format>normalized</internal-format>
   </texture>
   <reflect_map>1</reflect_map>
 </parameters>
   
</PropertyList>


Well, the GPU to give you high framerate, the full atmosphere and shadows isn't invented yet. Which is why you need to make a choice what your graphics card should do. The plain fact of the matter is that we have only so and so many GPU cycles, and if you try to do everything, you end up rendering still images.

Quite agreed

The issue with default (and possibly Rembrandt) is admittedly that there isn't currently much maintenance happening, but I think you might still try to talk Erik into adjusting the light curves for the sun below the horizon.

The issue is really with Rembrandt (ALS color balance is just fine), and if it is going frozen (note : I am not criticizing that, it's good people get back to RL from time to time) I'd rather do then some light maps to recover some lighting and claim the model is not rembrandt compatible... BTW is there any impossibility to implement heat haze and shadows that were present in the plib version using OSG ? I miss those features so much I may give a it try ...

[Thorsten]

BTW is there any impossibility to implement heat haze and shadows that were present in the plib version using OSG ?

I have never seen either (I thing I had plib FG on my computer once, but when I became really interested it was osg already). I have heard that the plib shadows were just projected quads onto the terrain underneath - and we do have that capability and can even render this pretty fast - see the tree shadows. The EC-130 for instance has such an attached shadow (I think it projects to level ground, as the tree shadows show we can also project co-planar in rough terrain in principle). The Ec-130 is also a good example for using model-combined.eff to good effect in all frameworks.

I'm not sure how the heat blur worked. We can't do the real thing outside Rembrandt, because in a forward renderer, there's no cross talk among adjacent pixels because they're all processes in parallel - which is what a blur requires. In Rembrandt, it's all rendered to a texture, so you can post-process the texture with filters (but you need an additional rendering pass for that, which costs).

I have some doubt however that plib did this with deferred rendering, so probably it was just a mockup of some kind - and that we might be able to do. I guess I need to see how it looks like to say more.

[Flying toaster]

I have never seen either (I thing I had plib FG on my computer once, but when I became really interested it was osg already). I have heard that the plib shadows were just projected quads onto the terrain underneath - and we do have that capability and can even render this pretty fast - see the tree shadows. The EC-130 for instance has such an attached shadow (I think it projects to level ground, as the tree shadows show we can also project co-planar in rough terrain in principle). The Ec-130 is also a good example for using model-combined.eff to good effect in all frameworks.

I found it in simgear 1.0.0 source tree ... Only uses the stencil buffer. Here is the comment describing the method :

Code: Select all

 geometry and edge list
 - traverse object graph until leaf to get geometry
 - what about transform and selection ?
   - use sub objects rather then objects
   - get local transform and selection
      - range anim : ssgRangeSelector ( min, max ) => ssgSelector ( true/false )
         => selection [0..n], kids [0..n]
      - select/timed anim : ssgSelector ( true/false )
         => isSelected( nkid )
      - spin/rotate/trans/scale/... : ssgTransform ( matrix )
         => getNetTransform
 - on new object :
   - for one object branch
      - for each leaf
         - save geometry
         - save address in cache
 - when rendering object
   - for each leaf
      - getNetTransform + object global rotation (ac) => transform for light position
      - go up in tree and check isSelected( self )
 - generate connectivity each time the geometry change
   => using local light so connectivity never changes
 - generate active edge list when :
   - light moves
   - subpart moves (animation code)
   - ac rotate
      => cache rotation matrix and generate edge list only if something change
      => even if it changes, no need to do that every frame

 - static objects have static edge list if light does not move

 shadowing a scene
 - render full scene as normal
 - render occluder in stencil buffer with their shadow volumes
 - apply stencil to framebuffer (darkens shadowed parts)

   shadows using the alpha buffer
   http://wwwvis.informatik.uni-stuttgart.de/~roettger/html/Pages/shadows.html
*/

// TODO
//   - shadow for objects
//      * aircraft
//      * tile objects (from .stg)
//      - ai objects
//      - random objects => tie shadow geometry to lib objects and reuse them
//   - zfail if camera inside shadow
//   - queue geometry work if lot of objects
//   * add a render property on/off (for aircraft, for scene objects, for ai)
//   * add a render property in rendering dialog
//   * filter : halo, light, shadow, disc, disk, flame, (exhaust), noshadow


I'm not sure how the heat blur worked. We can't do the real thing outside Rembrandt, because in a forward renderer, there's no cross talk among adjacent pixels because they're all processes in parallel - which is what a blur requires. In Rembrandt, it's all rendered to a texture, so you can post-process the texture with filters (but you need an additional rendering pass for that, which costs).

I have some doubt however that plib did this with deferred rendering, so probably it was just a mockup of some kind - and that we might be able to do. I guess I need to see how it looks like to say more.

Interestingly enough, the source code for heat blur is still inside the simgear 3.2.0 tree shadanim.cxx even though commented out. It seems to be a 2 pass algorithm with the scene being rendered without the haze then the render buffer is used to generate programmatically the texture on the blur object I don't know if that qualifies as deferred rendering... And I don't know if OSG allows such fine control either.

[Flying toaster]

Here comes a new update I'd like to submit for comments and suggestions.
The improvements compared with the previous versions are :
- Flares will now release from the good location
- Complete and much updated nozzle animation
- Engine startup procedure now modelled (electrical system always powered though)
- Afterburner effect fixed, turbine glows blue at night
- Working speed brakes
- LERX vortices no longer self illuminated (even though may be a bit dark)
- First draft of the flight manual in the root directory

I have ran into an issue with startup sounds since it seems that the <pitch> control does not alter the pitch of the sound as much as I would like it to. Pointers are welcome.

Feel free to provide suggestions/corrections on the flight manual

and of course, the download link (15Mb) :

Cheers

Enrique

[abassign]

Very nice ! But I have a first observation:
1. The menu F20 is very cute, but I wish it would disappear when you press F10 and always reappear by pressing F10, otherwise I can not take good pictures!
2. I keep thinking that the output of the turbo-reactor at 500-700 ° C temperature of the exhaust gas must have the internal disc of the after-burner and a part of the tube visible at night with a red light that varies with the regime. Otherwise like the IR missiles to shoot it down ?
For the rest it is a really nice job, but need to be improved, the colors inside the cabin.

[Thorsten]

2. I keep thinking that the output of the turbo-reactor at 500-700 ° C temperature of the exhaust gas must have the internal disc of the after-burner and a part of the tube visible at night with a red light that varies with the regime.

Dave Culp reports having seen a jet engine exhaust at night and reports a blue color. So why would you think that - do you think the actual observation isn't relevent, or that Dave can't see colors, or that the engine of the F-20 is so different and much cooler?

Otherwise like the IR missiles to shoot it down ?

Because they see the IR band, and they'd see a spot being much brighter than the sky even if it's 150 degrees and doesn't emit anything significant in the optical band. 'is hot' doesn't mean 'is red glowing'.

IR missiles aren't very discriminative - flares burn at several thousand degrees, much hotter than any engine exhaust - if they'd try to specifically look for engine signatures, they'd never fall for the decoy. But they tend to go for the highest contrast (well, not the most recent variants...)

Looking into the shadow and heat blur code: It's (unfortunately) all stuff that requires a second pass. We could attach shadow volumes to objects and do a pass using the stencil buffer right now, but we'd need to compute the lighting twice, which isn't fun.

And the heat blur requires to render to a texture buffer and then do an additional pass on that buffer, so we're talking two additional passes if you want to have both. It's not that it could not be done at all, but:

Which means if you're not seeing vsync everywhere and your current framerate would be of order 90-180 fps, you can assume it gets slashed by 2/3. Which sounds like a hefty pricetag to me to have these effects.

[Flying toaster]

Regarding the glow of the afterburner liner, I won't go for lighting it up before afterburner is ignited, as I cannot come to think this is realistic. The only reason it gets red hot is because there are fuel sprayers all over the place but when the fuel flow is cut you won't see any open flame in there and the temperature is too low for any visible light coming from the liner during daytime.
For an example look at this video : https://www.youtube.com/watch?v=LcyEJ8V1AJo
At 32s once the afterburner is shut the engine tailpipe is completely dark.
If that does not convice you... Well it is open source after all, so feel free to taylor it your way

Looking into the shadow and heat blur code: It's (unfortunately) all stuff that requires a second pass. We could attach shadow volumes to objects and do a pass using the stencil buffer right now, but we'd need to compute the lighting twice, which isn't fun.

I can agree with that, but still getting shadows without all the fuss about Rembrandt would be a real improvement (even if limited to the aircraft)

And the heat blur requires to render to a texture buffer and then do an additional pass on that buffer, so we're talking two additional passes if you want to have both. It's not that it could not be done at all, but:
Which means if you're not seeing vsync everywhere and your current framerate would be of order 90-180 fps, you can assume it gets slashed by 2/3. Which sounds like a hefty pricetag to me to have these effects.

You get 90+ fps ? Really ? Gee my 30fps setup is real crap !
I agree that heat blur is really eye candy and can be dispensed with. The up side of having that kind of effect is that you could also make for instance refraction effects (coupled with procedural texture shaders), mirrors, electro-optical systems that way...
I can think of, render the scene without blured objects, re-use the z-buffer, retaining the frame buffer and only re-render the effect affected objects. That should be much less expensive than re-rendering the whole scene as you performance hit estimate implies. But I guess that really is a pain in the neck for a scene-graph oriented API. Conversely, in a FSAA render, this can be accomodated in one of the jitter passes (if jitter is used for this effect of course).
For other render to texture needs, generally you will need a different camera setup, so I would go for lower resolutions to decrease frame rate impact (acceptable for cameras rendered to cockpit displays or small size mirrors).

But what I said also applies to me, if I am not happy with what is available, its time for me to take a OSG 101 lesson

[Thorsten]

You get 90+ fps ? Really ? Gee my 30fps setup is real crap !

Not ALS at highest quality with decent visibility in hires terrain - that gives me between 20 and 30 dependent on weather. But one notch down in quality gets me vsync of 60 steady. So I suppose I could tolerate a second rendering pass theoretically and retain some decent quality visuals.

But not with Rembrandt - configuring it such that it doesn't flicker badly gets me 15 fps even in modest visibility

I can think of, render the scene without blured objects, re-use the z-buffer, retaining the frame buffer and only re-render the effect affected objects.

I have thought about this whether ALS should optionally render to a texture and then do a final fragment pass over that texture, perhaps using stencil buffer to mark regions of interest (more because I was interested whether I could work out how to do that...). You're right in that this might be cheaper than the naive estimate would suggest.

I can agree with that, but still getting shadows without all the fuss about Rembrandt would be a real improvement (even if limited to the aircraft)

Admittedly, I never got that point. I know many people are excited about shadows, and so I spent the next five real-life flights actively looking for shadows in the scene. I saw it once, very blurred, on a cloud. Usually the scene light on the ground is fairly diffuse so that they don't show, then they can't always be seen from the cockpit, the terrain is usually so flat that it casts shadows chiefly on itself,...

You do see very prominent cloud shadows from above, but those we have.

So, whenever I draw my list of 'things in the scene which actually dominate my real-life visual impression during flight', shadows score very low, and so I wouldn't commit much framerate to get them (ALS pretty much works down that list... most of what forms the visual impression of the scene is distribution and color of haze in reality...)

[Johan G]

The only reason it gets red hot is because there are fuel sprayers all over the place but when the fuel flow is cut you won't see any open flame in there and the temperature is too low for any visible light coming from the liner during daytime.
For an example look at this video : https://www.youtube.com/watch?v=LcyEJ8V1AJo

Another good view of that and a bit closer in can be found here: http://youtu.be/CVHuyr1x4Eg?t=7m18s (A very interesting channel if anyone is interested in jet engines by the way. I have had many Aha! moments there.)

When the temperature of the (bypass air cooled) liner is to low to be visible it can still be seen with anything that picks up infrared; it is still way to hot to touch.