P3D v4 visibility conditions for scenery objects

[tgibson]

Not that I know of, but you can create two indentical models, one with each texture. Then program them to appear and disappear opposite each other.

 

[Christian Bahr]

Now that we know how to change the visibility of a model's part with RPN code, is there a way to change a texture with RPN code?

For this purpose there is the new Material Scripting (LUA Script). There is an example LUA file in the SDK where an object changes the color of the diffuse channel depending on the season (Material Season Example.lua).

If you modify this example file, the script can be used to change textures, depending on the season, the day or whatever. We are currently updating some sceneries. It's all about snow-covered roofs and 3-D grass. So far, it does not seem to affect FPS

LUA code for changing the texture in the winter month:

!lua

local TextureWinter = "mh_flughafen_aeroclub_wi.dds"
local TextureSommer = "mh_flughafen_aeroclub.dds"
local month = varget("E:ZULU MONTH OF YEAR", "Number")

if month > 2 then

varset("T:DiffuseTexture", "string", TextureSommer)
else
varset("T:DiffuseTexture", "string", TextureWinter)
end

@arno
RPN = Reverse Polish notation (Postfixnotation)

 

[arno]

At the moment I am experimenting with duplicating the model part with a different material in MCX, but the script might be easier. Where would the script go in your addon scenery though?

 

[arno]

Has anybody compared the performance between LUA script and duplicating model parts? I guess the script is more elegant, but with a model with multiple materials you would also get many scripts to put with your scenery, Just read you can put them in a local scripts folder that you add via add-on.xml though.

 

[Christian Bahr]

Where would the script go in your addon scenery though?

Hi Arno.

The LUA Scripts come in the scripts folder of the scenery. The scenery itself is integrated as an Add-on Package in the P3D. Alternatively, LUA scripts can also be copied to the P3Dv4\Scripts folder.

Has anybody compared the performance between LUA script and duplicating model parts? I guess the script is more elegant, but with a model with multiple materials you would also get many scripts to put with your scenery, Just read you can put them in a local scripts folder that you add via add-on.xml though.

The previous method of duplicate objects (an object for each season) is labor-intensive and time-consuming. With the LUA-Script you only need one object, the script then takes care of the texture change. It is true: one object requires a LUA script. Currently there are 11 scripts for me. The performance or the fps has remained unchanged. Maybe you can even merge the 11 scripts into a single script later, but that still has to be figured out how it works

 

[arno]

Each material would require a script right? So for a complex object with multiple textures you get multiple scripts as well.

In MCX I have coded it as one option to have seasons, the tool will do the duplication and visibility conditions on export. So that's not really labor intensive. Also you still have one object, the duplication is inside the single object.

 

[Christian Bahr]

Of course, that made a big difference. In previous projects we had made several copies of the object. Each object had its own GUID and placement coordinates. So in the end we had 4 MDL files each for each season.

For the snow-covered buildings, it would actually have been enough to detach the roof from the building and make a copy of the roof. Each copy would then be tagged with the respective Season VisCode (summer and winter) and you would have had only one MLD file. The same applies of course to 3-D grass with four seasonal variations. It really depends on the work method, because everyone works a little differently.

 

[rhumbaflappy]

If the model's part changes by the condition, then setting a visibility code within the model makes sense. If it is just a texture change by condition, then a lua script might be batter way to go.

Another possibility is what if you wish to make seasonal vegetation from the autogen tree models? Then it might make sense to use attach points and visibility code in the model.

 

[arno]

I guess I'll just add both ways to MCX and let the developer choose what to use.

 

[arno]

Here's something really twisted. It shows an object from dusk to dawn, but only during the summer. It is based from the no_day above, to show the use of even more variable conditions.

    <PartInfo>
    <Name>no_day_summer_only</Name>
    <Visibility>
      <Parameter>
        <Code>
          (E:ZULU MONTH OF YEAR, number) 6.0 &gt;= (E:ZULU MONTH OF YEAR, number) 8.0 &lt;= (E:TIME OF DAY, enum) 0 == (E:TIME OF DAY, enum) 2 == (E:TIME OF DAY, enum) 3 == or or and if{ 1 } els{ 0 }
        </Code>
      </Parameter>
    </Visibility>
  </PartInfo>

Note the or or and order. We loaded the 'stack' with conditions. Then we bring them off in the reverse order. We detect night or dusk or dawn, and it must be summer.

Dick, I'm trying to understand the and and or in that condition. Why is there only one and in there? The summer check ifself is already month >6 and month <8? So do you not need two and's there?

 

[rhumbaflappy]

I think you're right.

 

[rhumbaflappy]

I tried to set a visibility condition for an attach point. My idea was to use a different library object for a Scrub_Pine_9m... an autogen item. I can't get it to work. I can merge veg_tc_Pine_Scrub_9m.mdl and veg_tc_Pine_Scrub_9m_hw.mdl, produce a Pine_Scrub_9m.mdl and then assign visibility to each part, but attach points would have been nicer.

  <PartInfo>
    <Name>season_winter</Name>
    <Visibility>
      <Parameter>
        <Code>
          (E:ZULU MONTH OF YEAR, number) 12.0 &gt;= (E:ZULU MONTH OF YEAR, number) 2.0 &lt;= or if{ 1 } els{ 0 }
        </Code>
      </Parameter>
    </Visibility>
  </PartInfo>

  <PartInfo>
    <Name>season_not_winter</Name>
    <Visibility>
      <Parameter>
        <Code>
          (E:ZULU MONTH OF YEAR, number) 3.0 &gt;= (E:ZULU MONTH OF YEAR, number) 11.0 &lt;= and if{ 1 } els{ 0 }
        </Code>
      </Parameter>
    </Visibility>
  </PartInfo>

This shows a pine correctly.

 

[Deleted member 1281]

"It shows an object from dusk to dawn, but only during the summer ...."

In the interest of transparency, I would suggest using intermediate boolean operators rather than stack them all at the end ... kinda makes following the logic easier. Say, like so:

(E:ZULU MONTH OF YEAR, number) 6.0 >= (E:ZULU MONTH OF YEAR, number) 8.0 <=  and   // make sure it's summer

(E:TIME OF DAY, enum) 0 == (E:TIME OF DAY, enum) 2 == (E:TIME OF DAY, enum) 3 == or or  // 'or' the desired times of day; or simply use (E:TIME OF DAY, enum) 1 != (as mentioned before)

and    // join the two clauses since both need to be TRUE to enable the stated condition; and finally ...

if{ 1 } els{ 0 }  // explicitly leave TRUE or FALSE on the stack (not strictly necessary, I think, but good practice anyway).

Just for laffs, the following would also work, making use of the infamous 'quit' operator:

(E:ZULU MONTH OF YEAR, number) 6.0 < if{ 0 quit }  // if earlier than June: set FALSE and quit processing what follows
(E:ZULU MONTH OF YEAR, number) 8.0 > if{ 0 quit }  // if later than August: set FALSE and quit processing what follows
(E:TIME OF DAY, enum) 1 != if{ 1 } els{ 0 }    // set TRUE if it's not day

Note, not tested...

 

[arno]

Thanks @mjahn i already found the intermediate boolean way by looking at the default modeldef.xml, seems a more clear approach and also gives control over the order of the conditions (like using brackets normally).

 

[rhumbaflappy]

Seasons for models, as we know, don't follow the seasons.bgl . So we're stuck with what we get the xml coding. The season examples in the default modeldef.xml are only an approximation of northern latitudes. They are wrong in the southern latitudes. Here is something containing latitudes as a condition:

  <!-- Season visibility -->

  <PartInfo>
    <Name>season_spring_north</Name>
    <Visibility>
      <Parameter>
        <Code>
          (E:ZULU MONTH OF YEAR, number) 3.0 &gt;= (E:ZULU MONTH OF YEAR, number) 5.0 &lt;= and (O:WorldBase.Latitude, radians) 0.5 &lt;= and if{ 1 } els{ 0 }
        </Code>
      </Parameter>
    </Visibility>
  </PartInfo>

  <PartInfo>
    <Name>season_summer_north</Name>
    <Visibility>
      <Parameter>
        <Code>
          (E:ZULU MONTH OF YEAR, number) 6.0 &gt;= (E:ZULU MONTH OF YEAR, number) 8.0 &lt;= and (O:WorldBase.Latitude, radians) 0.5 &lt;= and if{ 1 } els{ 0 }
        </Code>
      </Parameter>
    </Visibility>
  </PartInfo>

  <PartInfo>
    <Name>season_fall_north</Name>
    <Visibility>
      <Parameter>
        <Code>
          (E:ZULU MONTH OF YEAR, number) 9.0 &gt;= (E:ZULU MONTH OF YEAR, number) 11.0 &lt;= and (O:WorldBase.Latitude, radians) 0.5 &lt;= and if{ 1 } els{ 0 }
        </Code>
      </Parameter>
    </Visibility>
  </PartInfo>

  <PartInfo>
    <Name>season_winter_north</Name>
    <Visibility>
      <Parameter>
        <Code>
          (E:ZULU MONTH OF YEAR, number) 12.0 &gt;= (E:ZULU MONTH OF YEAR, number) 2.0 &lt;= and (O:WorldBase.Latitude, radians) 0.5 &lt;= and if{ 1 } els{ 0 }
        </Code>
      </Parameter>
    </Visibility>
  </PartInfo>

  <PartInfo>
    <Name>season_spring_south</Name>
    <Visibility>
      <Parameter>
        <Code>
          (E:ZULU MONTH OF YEAR, number) 9.0 &gt;= (E:ZULU MONTH OF YEAR, number) 11.0 &lt;= and (O:WorldBase.Latitude, radians) -0.5 &lt;= and if{ 1 } els{ 0 }
        </Code>
      </Parameter>
    </Visibility>
  </PartInfo>

  <PartInfo>
    <Name>season_summer_south</Name>
    <Visibility>
      <Parameter>
        <Code>
          (E:ZULU MONTH OF YEAR, number) 12.0 &gt;= (E:ZULU MONTH OF YEAR, number) 2.0 &lt;= and (O:WorldBase.Latitude, radians) -0.5 &lt;= and if{ 1 } els{ 0 }
        </Code>
      </Parameter>
    </Visibility>
  </PartInfo>
  <PartInfo>

    <Name>season_fall_south</Name>
    <Visibility>
      <Parameter>
        <Code>
          (E:ZULU MONTH OF YEAR, number) 3.0 &gt;= (E:ZULU MONTH OF YEAR, number) 5.0 &lt;= and (O:WorldBase.Latitude, radians) -0.5 &lt;= and if{ 1 } els{ 0 }
        </Code>
      </Parameter>
    </Visibility>
  </PartInfo>

  <PartInfo>
  <Name>season_winter_south</Name>
    <Visibility>
      <Parameter>
        <Code>
          (E:ZULU MONTH OF YEAR, number) 3.0 &gt;= (E:ZULU MONTH OF YEAR, number) 5.0 &lt;= and (O:WorldBase.Latitude, radians) -0.5 &lt;= and if{ 1 } els{ 0 }
        </Code>
      </Parameter>
    </Visibility>
  </PartInfo>

  <!-- end season visibility -->

The code contains the intermediate boolean notation as described by mjahn above. The radian of 0.5 is about 30 degrees north. This is all pretty general, and won't match the seasons.bgl exactly. But it presents possibilities.

You could code for a more general month span, but also include conditions for latitude, longitude, altitude, temperature, and snow ( for hard winter ).

For a specifically placed model ( for example a hanger at Chicago's O'Hare International Airport, you could control the model displayed with pretty good accuracy (this would also apply to ground polys for specific airports).
For a dog house, you could control conditions for modeling of snow on the roof for low temperature or snowing conditions, regardless of season (the same being true of conifer trees that only are modeled for summer or hard winter).

Some applications can use the same model, but different textures depending on the location and environment. That would suggest a lua script.

 

[arno]

Hi Dick,

In MCX I use the day of the day for the seasons. That way you can make your seasons allign with the landclass scenery, you just need to check in the season.bgl what is the right day for each season to start. This is also explained on the wiki:

https://www.fsdeveloper.com/wiki/index.php?title=How_to_determine_the_season_of_the_terrain

 

[rhumbaflappy]

Hi Arno.

I was thinking of a bgl library of objects that would somewhat mimic the autogen vegetation. I get asked about this occasionally. Such a library wouldn't be for a specific location, but more of a global library. Trees displaying the wrong model would still be acceptable if they were near the season date, as some trees turn color or display snow before or after others. The modeldef.xml example wouldn't help in the southern hemisphere.

 

[robystar]

Hi,

After having read this thread for the umptieth time, I managed to convert a static (!) windsock into an animated one (a simple one). but that was not what I was really after.
Animated or not, the idea was to have it rotate to the prevailing wind as set in the weather options.
And that is something that, although mentioned by Dick, was not discussed any further.
As far as I could find out, it is a combination of extra model entries in the hierarchy editor (O: variables) and extra entries in the xml.
I would like to forego the use of SODE, though a really good program, now that we know of the extra possibilities presented in MCX, there should be a way to do without it.
Is anyone working on that as well (I know Aerosoft has found a way but they will almost certainly not divulge their methods)?
To be honest, I do use the info here not only for my freeware sceneries (only two published I thought were good enough) but also for an update of a payware one to come around St. Swithin's day.

Cheers,

PS: St. Swithin's day would translate to Sankt Nimmerlein or St. Juttemis in respectively German and Dutch?

 

[Christian Bahr]

Animated or not, the idea was to have it rotate to the prevailing wind as set in the weather options.

Hi.

A windsock turning in the wind? Nothing easier than this

Essentially, you turn the windsock pole 360° around its own axis. This animation should be a quaternion animation: Keys 0, 25, 50, 75, 100). This animation is tagged with this recipe:

(O:Weather.AmbientWindDirection, Degrees) 360.0 / 100 *

Now you only have to attach the first bone of the sock to the pole. In the P3Dv4, the windsock is now dynamic - it turns into the wind.

Hope it helps a little further

 

[arno]

I think you can also do it without bones, by just animating the pole itself and attaching the sock part to that.

Adding the animation with the keys can even be done in MCX now, in case the object was made in a tool that doesn't support animations, like SketchUp.