Paul Surgeon wrote:
P.S. Now all we have to do is implement seasonal textures. :P

There was a discussion about such a feature a couple of days ago, depending on the complexity that you desire, it would not need to be all that difficult to implement a _basic_ mechanism to support seasonal textures.

The easiest one would probably be to define different materials within
the XML file and assign them directly to seasons, for example by
providing an optional "season" parameter to textures, so that FG
knows for what seasons a texture is valid - and could OPTIONALLY
pick the appropriate textures.

So, it would not even need to be really complex to have some
simple mechanism (as a start)...

Of course, dealing *graphically* with textures and trying to
convert/manipulate them at runtime is a lot more difficult -
but one could start by using a rule-based conversion scheme, that
way you'd still need to inform FlightGear what kind of texture you
are using, but having a simple lookup table one could define a
handful of conversion profiles - e.g.:

        1) woods (summer) -> 2) woods (autumn) -> 3) woods (winter)

So, you would then manually have to tell FlightGear that a shift
from 1) -> 2) is mainly about artificially reducing the green parts
from the texture and substituting them with browinish/yellow,brown
pixels .... likewise one could deal with the RGB values for the
conversion from 1->3.

... I guess I don't need to go ahead with what else is theoretically possible ? :-)


Flightgear-devel mailing list

Reply via email to