Dirty airplanes??

[flycanarias]

Well, I want to ask if there could be build an effect that make an aircraft look "dirty"?? Just to give the sim a realistic "used look".

I found a photo, relating to FSX stuff, but this is basically what I'm looking for... http://flightx.net/index.php?thread/560 ... /&pageNo=2

If you have any ideas, please leave a comment.

[Johan G]

Yes, you can!

One of the guys behind the current model shaders once demonstrated how it could have a dirt layer that for example would cause there to be more soot and oil stains behind the exhaust of his IAR-80.

It started as the "Übershader", trying to combine various then existing mostly mutually exclusive shaders (in essence you could use one or two, but not all model shaders). Later it turned into the current Model-combined effect shader. You can only find some very little information in the linked FlightGear wiki article, but much more in the readme file you find a link to at the bottom of it.

I am a bit uncertain of which models uses a dirt map, so unfortunately I can not direct you to an existing example and addition to the readme.

[flycanarias]

Thank you for your reply! Unfortunately, I never did anything with shaders, so I would definitely be the wrong person to start modeling some kinds of shaders...
But I think the 757 is "detailed enough" to have those shaders... If there is probably someone who is able to develop that shader, it would be great!!!
Maybe you can, it seems you have a lot of knowledge about this topic...

[Hooray]

http://wiki.flightgear.org/Howto:Dynami ... via_Canvas

[Johan G]

[...] I never did anything with shaders, so I would definitely be the wrong person to start modeling some kinds of shaders...

Thankfully the shader is already written. However, to be used it needs some (mostly copy and paste?) configuration and of course textures.

If there is probably someone who is able to develop that shader, it would be great!!!
Maybe you can, it seems you have a lot of knowledge about this topic...

I only know this much mainly because it have passed my eyes while skimming through this forum for some years. I have never modified an existing one or added one to an aircraft myself either...

[Thorsten]

Well, I want to ask if there could be build an effect that make an aircraft look "dirty"?? Just to give the sim a realistic "used look".

It's a matter of the degree of sophistication needed.

If you want to have a dirty airplane, it'd be easiest to make a dirty livery by painting the dirt on the texture and simply select the livery as needed.

The model shader supports a dirt model in which you can specify a dirt colors as (rgb) in xml and a dirt distribution via a texture channels and the base texture layer will be altered accordingly with a mixing fraction determined by a parameter. In that way you can dynamically get parts of your plane dirty over time or when specific events happen (for instance a burning engine might dirty the fuselage where the soot clings).

Canvas as linked by Hooray offers you a dynamical way to alter a texture runtime, so you can paint moving spots on it if you need - it's the most general framework but likely an overkill for dirt.

However, in any solution you have to provide the artwork, i.e. the dirt distribution, in some way, there's no magic fix 'switch this on and it'll get dirty'.

[flycanarias]

Thank you very very much!!
Okay, I think the solution using the model shader will be the best way to get that what I want. So on the one hand, I nee to specify the colors, which will be mostly grey and black, right? As far as this is just .xml-writing, I think I can do that. Just need to know where to find the file to modify... Then, I need some kind of "overlaying texture" for the aircraft to direct the dirt to the spots where it should appear?! Where shall I paint it on?? Could you explain this a little more detailed, so I can start trying it out?

Thanks in advance

[Thorsten]

I don't know of so many planes with a dirtmap implemented, but it's really the same as a lightmap (except dirtier) - so do you perhaps have experience with a plane that implements a lightmap, then you can work from that example to learn how to derive and assign an effect?

The Shuttle has lightmaps in cockpit, but I hesitate to recommend that as example as they're not standard but use custom shaders.

The maps always share the uv-mapping of the original texture, so if you paint dirt on the texture coordinates where the base texture layer shows some feature, that feature will be dirty later.

Technically, the dirt is declared using the block

Code: Select all


      <dirt-enabled type="int">0</dirt-enabled>
      <dirt-multi type="int">0</dirt-multi>
      <dirt-color type="vec3d" n="0">0.0 0.0 0.0</dirt-color>
      <dirt-factor type="float" n="0">0.0</dirt-factor>
      <dirt-color type="vec3d" n="1">0.0 0.0 0.0</dirt-color>
      <dirt-factor type="float" n="1">0.0</dirt-factor>
      <dirt-color type="vec3d" n="2">0.0 0.0 0.0</dirt-color>
      <dirt-factor type="float" n="2">0.0</dirt-factor>


where you have three channels which use the reflection map rgb for dirt distribution.

To enable full-color black dirt using the r-channel of the reflection map, you would change this to

Code: Select all


      <dirt-enabled type="int">1</dirt-enabled>
      <dirt-multi type="int">1</dirt-multi>
      <dirt-color type="vec3d" n="0">0.0 0.0 0.0</dirt-color>
      <dirt-factor type="float" n="0">1.0</dirt-factor>


[Hooray]

Canvas as linked by Hooray offers you a dynamical way to alter a texture runtime, so you can paint moving spots on it if you need - it's the most general framework but likely an overkill for dirt.[

Agreed, in general, effects/shaders are considered the "most correct" way to do this sort of thing - but the Canvas system could even be used to visualize bullet damage in the proper places, as long as you have a UV-mapped livery so that you can place a Canvas on it. We also have posted screenshots and code snippets integrating both systems (effects/shaders and Canvas), this can for example be accomplished by allowing a Canvas to access materials, but also so that an arbitrary Canvas can be registered as a material - at that point, all th effects/shader machinery would be available in Canvas space without requiring any major programming.

[Thorsten]

If a canvas is internally referencable as a texture, it ought to be possible to dynamically also generate normal and reflection maps, no? And this ought to be a path to solve the feature request to provide the option to change such maps along with the livery?

Also, another thought in a similar vein: How does canvas manage memory? If I declare a 20kx20k canvas and put just a few small raster images on it - do we need the full memory space of the 20k texture, or is there cleverness applied by dispatching lookup calls to the smaller texture (which likely costs extra performance, but hey...)?

[Hooray]

If a canvas is internally referencable as a texture, it ought to be possible to dynamically also generate normal and reflection maps, no? And this ought to be a path to solve the feature request to provide the option to change such maps along with the livery?

That sounds like it should work, but I don't know enough about the requirements for such a normal/reflection map ?
But actually, a Canvas really is a texture, it's a Texture2D object that has a bunch of listeners/callbacks registered that deal with texture related events (think size, background color etc) - and from then on, everything else is handled by "elements" (images, text, paths).

So the top-level primitive is a Canvas, which is just a property-enabled osg::Texture2D, so that the RTT can be updated "on the fly" without having to exit/restart fgfs or patch any C++ code.

The screenshow that I posted a few years ago showing the Canvas-driven airports/taxiway dialog was registering the corresponding Canvas with the materials manager, so that the effects/shader machinery would become accessible, I think I got in touch with you to ask about adapting some effects for testing:

http://wiki.flightgear.org/Canvas_Devel ... 2F_Shaders



Obviously, this would work both ways, i.e. we could implement "chains" of materials where some are the input for a Canvas texture, while others are the "output" of a Canvas texture - which would mean that even schemes like Rembrandt (deferred rendering) could be implemented largely in fgdata space (effects/shaders, for the time being, Rembrandt is using C++ code to set up the corresponding buffers and stages to put everything together, because there really is zero Nasal overhead involved as long as only Canvas stage is used, i.e. none of the elements (an empty Canvas referencing a material created by another Canvas/effect).

And that point, you could have a multi-stage, and multi-pass, rendering pipeline implemented solely on top of the FlightGear property tree, by setting up a handful of "buffers" (Canvas FBOs/RTTs) and using them in a "creative" way to chain them together and create the final output.

Also note that we're talking here about roughly 50-100 lines of C++ code to teach the materials manager to retrieve a texture from the Canvas subsystem (instead of the base package) - ThomasS recently implemented the code for the Canvas specific side of this, because he also required hooks to get a Canvas as an osg::Image - so that he could serve it via http (i.e. as a jpeg/png):



The Canvas C++ code already has a getTexture2D() callback that we can use.

Also, another thought in a similar vein: How does canvas manage memory? If I declare a 20kx20k canvas and put just a few small raster images on it - do we need the full memory space of the 20k texture, or is there cleverness applied by dispatching lookup calls to the smaller texture (which likely costs extra performance, but hey...)?

Not sure what exaxctly you have in mind: It's a conventional OSG texture that is allocated - I doubt that any clever schemes are currently being used to preserve memory - but if OSG has any corresponding functionality, it could certainly be used by the Canvas system, I just don't think it's currently being done that way.

However, the Canvas image element already supports texture mapping, i.e. you can treat a raster image (including another Canvas) as the source for a raster image, and only get a portion out of it: http://wiki.flightgear.org/Howto:Using_ ... xture_Maps

Once you stop manipulating a Canvas in the tree (and especially its child elements), it's all native C++ code that is running - i.e. no Nasal or property overhead once the corresponding data structures are set up, but that only holds true until the next "update", at which point everything is removed, re-parsed and updated/re-drawn (like you said in the other thread about rendering starting usually fresh).

[Thorsten]

Not sure what exaxctly you have in mind: It's a conventional OSG texture that is allocated

Say I have a 512x512 texture sheet on a 16x16k background. Theoretically this could be stored by not writing a 16x16 k table but by having a 512x512 table and a translation matrix and it'd take 125 times less memory. If you could design the lookup that way.

My question is - is it? Or does it generate a huge, largely empty table?

It's moderately relevant for cockpit elements like tapes (which tend to be pretty long and then are clipped and could be designed in a different way). It's more relevant for an idea I've been toying with which relies on not having a memory overflow.

That sounds like it should work, but I don't know enough about the requirements for such a normal/reflection map ?

Formally it's just a normal texture. The magic is all in what its color values are.

[Hooray]

If it's just a texture, then Canvas will work, because that is really what a Canvas is "under the hood", too.
The main difference is that certain OSG parameters are exposed in the form of properties, by setting properties using a certain name, type/value, it will call the corresponding OSG machinery to update the texture internally.
For instance, for Rembrandt, that would require additional hooks, because things like the internal texture format are not currently configurable via "Canvas properties", i.e. it's a hard-coded thing - however, Rembrandt makes extensive use of different kinds of buffers and in-memory representations, probably for pretty much the same reasons that you have in mind regarding the first question you asked.

I guess, to answer your first question, we would need to look at the way Rembrandt is setting up, and managing, its buffers and compare that to the standard Canvas FBO - but I really think that it's not doing anything fancy at all, because that would introduce hard-coded assumptions that may fail under certain circumstances.

Basically, what you are suggesting would require some way to encode the internal representation using a configurable lookup.

What is really taking place behind the scenes, is that the Canvas system is built on the old FGODGauge code, Tom ended up rewriting it from scratch basically, but it's still using the same mechanism that hard-coded "owner-drawn" (OD) gauges like the agradar/navdisplay were using.

The allocation (OSG setup) can be found here: https://sourceforge.net/p/flightgear/si ... e.cxx#l218
The internal representation/format is a hard-coded thing: https://sourceforge.net/p/flightgear/si ... e.cxx#l255

And even the cameragroup stuff is using the same hard-coded assumption: https://sourceforge.net/p/flightgear/fl ... p.cxx#l994

Rembrandt, and effects (simgear), are much more flexible (for now), e.g. see: https://sourceforge.net/p/flightgear/fl ... e.cxx#l164
https://sourceforge.net/p/flightgear/fl ... r.cxx#l769

Thus, I think that, depending on what you have in mind, the format/sampler of the corresponding Canvas texture would need to be configurable, just like dimensions/viewpoint are currently: https://www.opengl.org/wiki/Sampler_(GLSL)

I don't know what exactly you have in mind, but if you can come up with a really reduced test-case, I may be able to resurrect my old patches, and/or update the corresponding code to give us a little playground to tinker with the whole idea of integrating Canvas and effects/shaders in the form of extending the materials manager so that it can use a Canvas FBO as the input/output buffer for a material.

[Thorsten]

I've toyed with the idea of making the cloudsphere for Earthview dynamical by having textures of individual storm systems and trying to move them around on a background (which for resolution purposes has to be very large).

I haven't even finished the design of this in my head, it's just in a fact-finding phase.

[Hooray]

So the technique you describe, are you using it elsewhere in FlightGear or is this commonly done with other OpenGL/GLSL software ?
Once I can look at a corresponding piece of code, I can work out what is missing to support this via Canvas