Board index FlightGear Development Canvas

Two Images to a Texture

Canvas is FlightGear's new fully scriptable 2D drawing system that will allow you to easily create new instruments, HUDs and even GUI dialogs and custom GUI widgets, without having to write C++ code and without having to rebuild FlightGear.

Two Images to a Texture

Postby Algernon » Mon Sep 01, 2014 9:55 am

Hi all - I'm trying something experimental with materials, not an area I'm very strong in. Does anyone know if it's possible for FG to work with a texture which consists of two images, and manipulate those images seperately? The application here is airframe dirt - I'm trying to find out if I can have one texture for the aircraft livery, and another for accumulated dirt, which would gradually become less transparent as the airframe hours increase. I am aware of the questionable advisability of using alpha channels excessively in FG, this is just an experiment at the moment. I actually suspect it's not possible, as I'd imagine this would be done with the material animation and I can't see how. But I thought it was worth an ask :)

Cheers!
Algernon
FGUK - A FlightGear community in the United Kingdom and Republic of Ireland
User avatar
Algernon
 
Posts: 498
Joined: Sun Jun 27, 2010 3:55 pm
Callsign: G-ALGY
Version: 3.0
OS: W7U

Re: Two Images to a Texture

Postby Hooray » Mon Sep 01, 2014 11:37 am

there are probably several ways to do something like this, effects/shaders and even Canvas can be used to combine textures and adjusting alpha via Nasal.
So it's mainly a matter of your exact requirements and what kind of solution you'd prefer.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Two Images to a Texture

Postby radi » Mon Sep 01, 2014 11:50 am

As far as I remember, Emilian's IAR-80 accumulated exhaust gas dirt. I'm by no means an expert, but http://wiki.flightgear.org/IAR_80 points to the ubershader.
OSM buildings for LOWI, EDDC
Custom scenery for VHXX YMML
Edit .stg via the FG Object Placement Tool
radi
 
Posts: 643
Joined: Mon Aug 25, 2008 4:24 pm
Location: YMML, EDDC

Re: Two Images to a Texture

Postby hvengel » Tue Sep 02, 2014 3:11 pm

The uber shader has a dirt effect built in and it uses it's own texture to map out were the dirt is located and the amount of dirt accumulation can be set/changed at run time. This effect is specifically to do what you are asking about. I think this is how the IAR-80 does it's exhaust dirt. In any case check out the docs for the uber shader. If you are using other uber shader effects it should be easy to setup. If not then it will be more work since there is a learning curve involved but you will likely want to know how to use the uber shader in the long run anyway.
hvengel
Retired
 
Posts: 1128
Joined: Sun Dec 24, 2006 4:35 am
Location: Minden Nevada

Re: Two Images to a Texture

Postby Algernon » Wed Sep 03, 2014 4:55 pm

Good advice, thanks. I have been aware of the ubershader but not looked into it in great detail, and my work with models and materials is just getting to the stage where I understand enough to try shaders out.

To be more specific, then, in the hope of opinions on the most FG-friendly way to approach it, here is a brief precis:

The aircraft gets dirtier with more flights hours. Some code to do this is already in place, and tested on the other dirt application, the APU exhaust blackening on the port wing root. This is a localised and distinctive stain which you see on most Typhoons, so there I have just used a duplicate of the vertices and faces in that locality, placed a little away from the airframe, and used an alpha texture and the material transparency animation. It works a charm, and doesn't seem to have problems with alpha flashing. For the airframe, this probably isn't a viable approach. Part of the textures set for the airframe has a transparent dirt layer which has been tailored to the model to feature streaks from particular vents or around extensions like underwing pylons, so it would be desirable to be able to use this. This additional layer must remain unchanged through livery switches, and then be gradually introduced over time according to the property updated by the same Nasal function that dirties the APU exhaust while it's running (the airframe starts to gets dirtier over 80kts or something for the all over dirt). And if at all possible, it should be Rembrandt compatible.

I think that Rembrandt might rule out some of the shader approaches, but I don't know, I'm not really up to date on that. The idea of a canvas airframe texture is a fascinating one, and might be considered almost heretical over at FGUK! ;) But although I'm finding Canvas a bit inaccessible at the moment, if I can achieve combined textures with controllable transparency that works equally well with or without Rembrandt, I'd certainly be interested in using this idea as an entry point.
Algernon
FGUK - A FlightGear community in the United Kingdom and Republic of Ireland
User avatar
Algernon
 
Posts: 498
Joined: Sun Jun 27, 2010 3:55 pm
Callsign: G-ALGY
Version: 3.0
OS: W7U

Re: Two Images to a Texture

Postby Hooray » Wed Sep 03, 2014 5:11 pm

Algernon wrote in Wed Sep 03, 2014 4:55 pm:The idea of a canvas airframe texture is a fascinating one, and might be considered almost heretical over at FGUK! ;) But although I'm finding Canvas a bit inaccessible at the moment, if I can achieve combined textures with controllable transparency that works equally well with or without Rembrandt, I'd certainly be interested in using this idea as an entry point.

Canvas should work fairly well actually - Tom added support for pretty much "arbitrary" placements, so that canvas textures can be placed anywhere on the aircraft, but also in the scenery (and obviously also in GUI dialogs/windows). We once toyed with the idea of also making effects and shaders available to Canvas - Tom also mentioned this once on the devel list, and we have code doing this for the whole canvas - even though Tom said that it would be better to support this "per-element". Obviously, that would bring a ton of flexibility to Canvas-based efforts like yours.

I am not sure why you find Canvas "inaccessible" - but maybe you should consider posting a few more specific questions so that we can fill in any gaps - or even post some code snippets.
I do realize that most code snippets recently added to the wiki are about different use-cases - i.e. not specifically about airframe textures/liveries, but then again - the Canvas doesn't care at all where you use a certain texture - in other words, you could prototype the whole thing using a GUI dialog and once you are satisifed with the outcode you would use another placement to show the texture elsewhere. The good thing about your particular use case is that it low-bandwidth, i.e. the texture probably doesn't need to be updated per frame - so performance issues due to Nasal/Canvas overhead should not be a factor.
I think you could certainly prototype the whole thing fairly quickly - and if/once effects and shaders become available to Canvas, your approach could be updated accordingly.

For starters, you could look at this: http://wiki.flightgear.org/Howto:Using_ ... ash_Screen

This will open an existing splash screen image and show it in a Canvas dialog.
You can copy/paste the code to load a few different images, to learn more about Canvas image handling, see: http://wiki.flightgear.org/Canvas_Image

Note that you can also use/apply sub-textures and overlay/transform those arbitrarily - i.e. a lot of fancy stuff without having to know anything about effects or shaders :)

You can also overlay individual images using the "z-index" attribute: http://wiki.flightgear.org/Canvas_Element#z-index
And then, you can basically do pretty much anything using the core Nasal APIs documented at: http://wiki.flightgear.org/Canvas_Nasal_API
To adjust transparency, you'll want to use the alpha channel.

To animate the livery/texture, you'd basically use a timer/listener to change the texture's canvas property tree - i.e. by hiding/showing some sub-texture, or transforming groups/elements.

Feel free to start a new thread in the Canvas sub forum and let us know if you got stuck somewhere (please post your code).

I don't know if we have placement-related docs anywhere, but you could take a look at any aircraft using a dynamic Canvas-based texture, the c172p-canvas should be a fairly lighweight example compared to the 777/747 probably :D

If you're interested in pursuing this, I'd love to see the whole effort documented via the wiki so that we can turn this into a "Canvas Liveries" tutorial/howto if you agree :?:
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Two Images to a Texture

Postby hvengel » Wed Sep 03, 2014 8:28 pm

The uber shader works with Rembrandt and the dirt effect does exactly what you are trying to do. Plus the uber shader gives you reflection and normal map (bump) effects.

The canvas approach seems to have some desirable features since the canvas can be placed anywhere on an existing model (IE. no need for a duplicate offset mesh) if I am not misreading what Hooray wrote. This might also be useful for doing liveries that involve having different amounts of painted surface over metal. One of the issues with using the reflection shader functionality in the uber shader is that any painted surfaces on the aircraft needs to have the reflectivity disabled in the painted areas (by increasing the transparency of the reflection texture to 100%) and which areas need to have this done will be different from livery to livery. Since it is not possible to change the reflection texture at run time you can't really have more than one livery based on a partly painted bare metal airframe without resorting to some type of trick such as using duplicate offset transparent meshes. Is using canvas another possible "trick" for this type of thing?
hvengel
Retired
 
Posts: 1128
Joined: Sun Dec 24, 2006 4:35 am
Location: Minden Nevada

Re: Two Images to a Texture

Postby Hooray » Wed Sep 03, 2014 8:47 pm

Just to clarify: the whole method came up as an idea - this isn't currently being used anywhere as far as I know. But it would seem that we're mainly missing people who want to experiment a bit.
Canvas was never designed for creating/modifying "liveries" obviously - but canvas is very good at one thing: creating/modifying arbitrary textures at run-time and adjusting pretty much arbitrary parameters by setting a few properties.

Thus, I'd consider Canvas more like a "toolbox" whose tools may not be directly designed for this particular purpose, but which are sufficiently generic and which can still be used "creatively" - e.g. there are some things that are only possible per-canvas, and not per "element" (group, image, paths, text, map) - in such cases, you typically need to use a workaround by using multiple canvas and referencing them via the canvas:/// markup as another raster image. We used this method a few times to implement "workarounds" - so in general, the implementation is pretty generic and even "recursive".

We don't currently have any support for effects/shaders in 3.2 (or git) - but whenever you add a canvas-based texture to any of your models, you're adding a layer of indirection - so while some static textures may not be easily changed at run-time in some C++ subsystems, Canvas is all about managing dynamic textures - which in turn may consist of static textures (or variations of those).

So, I guess with some more feedback/brainstorming, we can probably explore and see what's possible already, and what might be missing to support this particular "livery" use-case in the most generic fashion. Like I said, support for shaders/effects is relatively straightforward to add - Tom and I both have experimental code doing this kind of thing (per canvas only here) -and this would be useful for other purposes, too (think FLIR/night vision support etc).

From an effects/shader development it would make sense to be able to not only use those feaures via Canvas, but to also expose Canvas textures themselves to shaders/effects:
https://www.mail-archive.com/flightgear ... 37873.html
Tim Moore wrote:It would be nice if the Effects framework had a way to load arbitrary textures and make them available to effects.


Given all the work that Thorsten has done, this would seem like a worthwhile thing to explore - also to help unify the various photo scenery approaches we've been seeing, i.e. without requiring a patched binary: http://wiki.flightgear.org/Photoscenery
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Two Images to a Texture

Postby hvengel » Wed Sep 03, 2014 9:20 pm

Hooray wrote in Wed Sep 03, 2014 8:47 pm:...
https://www.mail-archive.com/flightgear ... 37873.html
Tim Moore wrote:It would be nice if the Effects framework had a way to load arbitrary textures and make them available to effects.
...


This is the basic issue I was referring to. If the effects framework allowed for the reflection map texture to be changed by the livery system this would allow one reflection map per livery. This would solve the livery with a bare metal aircraft background issue. This issue has been mentioned on a number of threads here - the first time about 3 years ago - so it is a long standing issue. Since most aircraft do not use the effects framework most are not affected by this. But it is an issue for some of the more advanced aircraft we have.

I would just as soon not use canvas for doing livery work and would prefer that the effects framework and the livery system provided this functionality. But I asked about using canvas just in case that could be made to work while waiting for the effects framework to support this.
hvengel
Retired
 
Posts: 1128
Joined: Sun Dec 24, 2006 4:35 am
Location: Minden Nevada

Re: Two Images to a Texture

Postby Hooray » Wed Sep 03, 2014 9:41 pm

As has been recently pointed out by Curt on the devel list, the effects framework isn't being worked on currently (and hasn't been in years) - its developer/maintainer is busy with other things and a few core developers have also been pointing out issues related to the effects system, including memory leaks and more recently race conditions in multi-threaded code - which is one of the more serious reasons why 3.2 hasn'yet been shipped.

It's only thanks to Torsten that someone is looking into this at all currently. The effects system is incredibly sophisticated C++ code so not exactly easy to troubleshoot, and the fact that OSG is using threads doesn't make it easier. In other words, I wouldn't hold my breath when it comes to new effects related additions.

Also, effects pre-dates Canvas by several years - meanwhile, it would be one of the more natural choices to optionally provide support for interfacing/integrating both, without this integration bein specific to a single use/case (e.g. aircraft/liveries). We've got other useful work related to effects that never made it into git and that predates Canvas by several years - but when it comes to managing dynamically created textures, canvas can probably be considered the common denominator and it doesn't make much sense to add even more disparate features that cannot be used elsewhere.

However, like you say it's obviously a long-standing feature request - and it would probably make sense to file a feature request for this.

Personally, I think that a simple Canvas-based livery system could probably be prototyped in under 50-100 lines of Nasal/Canvas code - so there really isn't much of a barrier to entry compared to working with some of the most sophisticated, and least-documented, pieces of C++ code added to FlightGear.

Nasal is usually not used because it's such a great choice but because core development is a very real bottleneck for base package developers - like you said: this has been discussed for 3-5 years - and we've seen similar discussions about things like photoscenery or dynamically created runway skid marks - so it kinda makes sense to prototype new features in scripting space, and see where that leads us - while it's true that there are many features that should no longer be implemented in Nasal, the culprit is to be found elsewhere - i.e. C++ development generally not being as responsive to base package additions, even though that's where the manpower is when it comes to sheer hours and number of contributions/month.

Even the extra500 developers stated quite clearly that they would have preferred if the C++ infrastructure provided the corresponding tools to develop the Avidyne Entegra R9 - and that they'd consider Nasal/Canvas to be too generic and too slow for their needs - but as can be seen, they still settled with this "workaround" - arguably, because the barrier to entry is so much lower once you can simply use a scripting language and an SVG editor like Inkscape.

We can definitely conduct some experiments and see what is missing to use Canvas for livery-related features - but I guess there really isn't much missing to use Canvas this way, even though it was clearly never designed for this - but it's a generic 2D rendering system after all - so the main "challenge" would seem to be placing a canvas on the aircraft... afterwards, all existing APIs can be used as if the whole livery were a conventional GUI dialog and/or MFD screen that requires very little in terms of updating :D
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Two Images to a Texture

Postby Hooray » Mon Sep 15, 2014 6:45 pm

ok, I've added a snippet of Nasal/Canvas code demonstrating how to modify the livery at run-time:

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

We can extend this over time - I just added the map to have some "dynamic" content - this could be just as well raster images, SVG files, maps, paths or any combination thereof - it's really rather flexible and only needs ~10 lines of code. Obviously, texture mapping of the 3D model is still applied, so needs to be taken into account.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Two Images to a Texture

Postby hvengel » Mon Sep 15, 2014 7:12 pm

The other advantage to this is to be able to use vector graphics directly so that the apparent resolution is not limited by the raster textures. Not sure how using vector graphics would scale on low end hardware?

Is it possible to place these anywhere on the model (IE. a number of smaller "textures" or SVG objects that cover only part of the model) and if so how do we specify the location of these "textures" on the model. Also how to we relate these "textures" to the UV layout for the model?
hvengel
Retired
 
Posts: 1128
Joined: Sun Dec 24, 2006 4:35 am
Location: Minden Nevada

Re: Two Images to a Texture

Postby Hooray » Mon Sep 15, 2014 7:17 pm

right, we recently had a discussion about SVG overhead on the wiki, I think HHS and i4dnf were also concerned about that. However, such a texture would be "relatively static" in comparison to an animated screen (MFD). Internally, canvas will turn all SVG commands into OpenVG primitives and then maintain a raster image which is rendered each frame, but usually only updated when absolutely necessary (modified/animated).

Yes, you can use pretty much arbitrary locations as long as you've previously mapped those in the 3D model: the only thing I did here is working around the livery system and directly using the texture IDs in the *.ac file to replace those textures.

Internally, that's using the visitor pattern IIRC (at least it was in the pre-canvas/od_gauge days).

Thus, your texture mapping is normally based on your 3D model and what you've done there - if you want this to be more flexible, you need to assign flat textures and do all the mapping in Nasal/Canvas space by using texture maps and sub-regions of a texture and draping those properly using transformations.

So this was just supposed to be an example to prove that we can replace arbitrary textures, including liveries with Canvas textures.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Two Images to a Texture

Postby hvengel » Mon Sep 15, 2014 10:20 pm

[quote="Hooray";p=218627...Yes, you can use pretty much arbitrary locations as long as you've previously mapped those in the 3D model: ...[/quote]

Not sure what this means. This is why I asked about the UV map which is how normal textures are mapped onto the 3D model. But you say "mapped those IN the 3D model" so I am confused.
hvengel
Retired
 
Posts: 1128
Joined: Sun Dec 24, 2006 4:35 am
Location: Minden Nevada

Re: Two Images to a Texture

Postby Hooray » Mon Sep 15, 2014 10:28 pm

any texture-mapped surface has a symbolic name to which a static texture is normally assigned, the way this works internally is that the scene graph branch is looked up and the texture replaced.
In other words, an untextured model cannot be textured with textures - while anything that has a texture/name can be looked up and told to use a canvas texture instead.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am

Next

Return to Canvas

Who is online

Users browsing this forum: No registered users and 7 guests