Dynamically replacing textures using properties

[Hooray]

The recent "plugins" discussion was in part about a tool named "g2xpl" for XPlane (or tileproxy for FSX) which dynamically downloads textures, in order to render photographic scenery using google maps images.

In FlightGear, this is currently not directly possible (without changes to the C++ code), because there is no way to trigger a reload in order to replace a particular texture at runtime (scenery or aircraft).

The idea to dynamically insert (replace) textures in FlightGear is not totally new, the old "wishlist" thread also contained something similar:

I would also like to add a feature for using more external C++ code. I'm looking at possible modelling a Garmin 530W or similar GNS/GPS system. However, that screen would be very hard to draw with our methods AFAIK. This would include the capability for C++ to transmit a texture back to be used in the plane. Hopefully, again, this wouldn't need a large change.

And it just occured to me that we might be able to do this already: 2.5 years ago there was another discussion on the atlas tracker about someone doing something like this by 1) compressing and uuencoding the texture, 2) opening a telnet connection, 3) setting a property with the texture data (in string format).

Obviously, there is currently no way to dynamically load and render a texture from a property, but it should be possible to uncompress and decode the string in order to write it out to a temporary location using Nasal (io.nas) and then make it take effect by simply reloading the whole panel (fgcommand) which references said texture(?).

So the idea is not totally absurd, and there might be a real use for such a feature in FlightGear.

Of course, efficiency is a completely different matter: sending a texture of i.e. 512x512x16bpp via telnet is probably not the fastest thing to do, certainly not at a fixed rate of several hz.
Instead of doing this at a fixed rate, it would probably be better to only send updates conditionally (when required) and even then only send delta-compressed diffs to the previous texture. Updates could be incrementally done, so that the texture has to be re-assembled from e.g. 10-20 different "packages", spread over a number of frames/seconds.

Otherwise, the framerate might really suffer, you could try for yourself by using a shell script (uuencode, netcat) to actually set a property to a string that is > 500 kbytes

I assume, the simulator will probably freeze - so I am not sure how useful this really is?

A faster method would be to simply write out the file to a shared location and simply send the path+filename to FlightGear, which could in turn use a background thread to load the texture. But that only works for processes on the same machine or setups with common network storage.

But it might be interesting to have a custom protocol for this, something that simply connects to a server and requests a texture by sending the current [timestamp, position, altitude] and some custom data (depending on use).

In FlightGear, one would need to use a visitor to replace textures with data taken from properties (just exchanging filenames of modified will still be more efficient though).

Any ideas? Would anyone else have a real use for this??

[Gijs]

You did read this topic? It's about placing remotely-hosted textures on scenery.

[Hooray]

You did read this topic? It's about placing remotely-hosted textures on scenery.

While this discussion is of course somewhat related, it is only marginally relevant here.

The point is not the particular use (google maps imagery for scenery use in that case), but more the implementation on a lower level (adding and replacing textures using properties, which may for example be inserted into fgfs using a network connection, such as the props interface). Otherwise I could have just as well posted to the plugins or wishlist threads.

Scenery and aircraft textures that can be updated or switched just by writing to properties, that in itself is a pretty powerful idea. You would for example also need this to implement runway skid marks or even bullet holes that are placed dynamically.

And as "flameout" has previously shown, there are other uses for this particular technique (he talked about feeding in textures for use as a moving map background).

For example, having this in place would allow you to render atlas maps as a background layer for arbitrary instruments. So it's not just placing google imagery in FlightGear scenery (which is of course questionable practice).

For use in aircraft, one would need a way to address textures by handle (texture ID), while individual scenery textures are probably best addressed by using their lat/lon position.

[ot-666]

Something like this could be very useful for my idea to get a decent rain / snow / ice effect to the cockpit glass with working wipers by simply changing the textures of an overlaying model.

And you could get the visual effect of a wet runway or snow based on weather settings.

cheers, oliver

[Tuxklok]

Something like this could be very useful for my idea to get a decent rain / snow / ice effect to the cockpit glass with working wipers by simply changing the textures of an overlaying model.

And you could get the visual effect of a wet runway or snow based on weather settings.

cheers, oliver

shaders would almost certainly be the best approach for stuff like that...