P3D v4 Daytime Only Visibility Condition

[=rk=]

Manfred, are you unable to accept the evidence that the code actually works, via a demonstrational screen shot? I don't need to work out the code calculations you offered, because Arno already devised that code syntax, asserted that it works and I myself also tested that code syntax and found that it worked, exactly as intended.

Yet still you persist, with your "enum's" and your gauge syntax, sir, this is not a gauge syntax thread, please, for the sake of people just learning this for the first time, adapt. All this cross talk about attach points and effects, spreads disinformation and confuses, because this procedure has no association with either.
Now, I'll address your code conundrum. Remember, I am coming from a perspective of knowledge that my code already works.

What I am worried about (and so, with all due respect, should you) is taking this as a master pattern for a wholly different calculation using a) a different variable, b) different units, c) different operators, d) different value ranges.

It is not at all a "master" pattern. It is a pattern and I am a code cipher. It is a simple, logical extension, to substitute values for working code, to get functional derivatives. In that regard, my master pattern is the clock and the calendar. If you are unable to interpret that the values between the parenthesis, in red in the example below, can be removed and substituted, in order to get a different result, then the situation is beyond my ability to explain.

(E:ZULU MONTH OF YEAR, number) 12 == if{ 1 } els{ 0 }

So, I began my search. I searched "dawn," "dusk," "visible," finally I hit on "time" itself and again, without any logic beyond my monkey like ability to substitute, I hacked this

<Code>(E:LOCAL TIME, hour) 12 % 10 *</Code>

into the above and as the French say, voila.

Evaluating this expression in sim (FSX) and successively selecting day, dusk, night, and dawn environments, I get the followng readouts in season spring :

I am sorry, I do not understand how you evaluate this in FSX, by changing environments, to get a "readout" in spring. What is this readout and from what software is it generated? Since I am unable to follow this logic trail, I will analyze the code snippet that I know works. Understand, this is not technical, it is my interpretation.

(E:TIME OF DAY, number) 8 &gt;= (E:TIME OF DAY, number) 17 &lt;= and if{ 1 } els{ 0 }

(E:TIME OF DAY, number)
E is a variable. It is defined as the time of day and it is controlled by a whole number.

8 &gt;=
8 is the first whole number. If the number (representing the actual hour of the day, inside the sim) being tested against the operation is equal to 8 or greater than 8, the operation proceeds, with an affirmative flag. If the number being tested against the operation is less than 8, the operation proceeds, with a negative flag.

17 &lt;=
17 is the second whole number. If the number being tested against the operation is equal to 17 or less than 17, the operation proceeds, affirmative. If the number being tested against the operation is greater than 17, the operation proceeds, negative.

and if{ 1 } els{ 0 }
Finally, if the sum total of both numerical comparisons is flagged affirmative, then yes (render the conditional visibility materials), otherwise (els), then no (do not render the conditional visibility materials).

So, beside my pig logic of making the expressions work to my pleasing, they also work within the simulator, where it matters.

 

[Deleted member 1281]

Yet still you persist, with your "enum's" and your gauge syntax, sir, this is not a gauge syntax thread,

In post #1 you said:

Can someone offer the proper syntax to make the intended condition render?

I fear it's time for us to agree to disagree.

Wish some of the great code gurus here could chip in one way or another. Currently I stand by everything I said, but will be more than happy to recant if shown the error of my argument.

Cheers,
Manfred

 

[=rk=]

I stand by everything I said, but will be more than happy to recant if shown the error of my argument.

I get the distinct feeling that you do not read the words that I type, the attached should communicate approximately 1000 of them. I am less concerned about the recantation, than I am the ability to edify.

In post #1 you said: Can someone offer the proper syntax to make the intended condition render?

This is true, and in post #3 I stated:

Thank you so very much for the observation. I searched through the modeldef.xml, using "time" as the term. the search uncovered a visibility condition for a clock gauge needle and I knew I'd found my code snippet.

This was in reply to your suggestion. It was posted the day after I opened the thread and here we are, an entire page and one week later, yet in a state of disagreement.

Why you would need a code guru, when the visual and even material evidence is right here, begs the question, are you spoofing me? The proof has been in this thread since the third post. Additionally, there is evidence that this is not the purview of traditional simulator code guru's, as evidenced in the "enum," "number" discrepancy.
Don't believe the picture? You have the code snippet, copy/paste it into your modeldef.xml. You will have to use the example of a seasonal visibility condition to apply a name to this new daytime visibility condition, I called mine, "daytime_visible." Compile off a model in MCX and test it for yourself, you'll need to use the Hierarchy Editor to select the materials which you intend to affect.

It took me far less time to figure this entire procedure out, than it has taken to get to this point of "disagreement." I apologize for the level of my ability to articulate, but I know it works and I feel I've proven how it works, conclusively. Beyond that, I can not force you to learn.

 

[n4gix]

Guys, (E:TIME OF DAY,number) is a pre-calculated token variable that will only return one of four results that coincide with roughly dawn, day, dusk or night.

(E:LOCAL TIME, hour) 12 % 10 * on the other hand is a token variable that will return the local CLOCK TIME as hours only, as the math operation strips out the minutes entirely. Hence if the actual local time is 14:32, the formula will return only 14. This 'magic' is the result of using the modulus math operator.

That is precisely why Rick's 'formula' works.

Nota bene: I actually used this over a decade ago when I was still working for Eaglesoft DG to show/hide pilot's sunglasses in the Liberty XL.

 

[=rk=]

Thanks, Bill and I was probably wrong about gauges in relation to this thread. I was thinking about it at work and there are a lot of visibility conditions that must apply to gauges, my clock snippet being one of them. However, the syntax looks different to me, between what I see in the modeldef.xml and examples Manfred has posted. His is similar to what I am used to seeing, as compared to what I see in the modeldef.xml and I can understand the disconnection, or are they actually the same, with a slightly different format, or something?

Also, please Bill, this was my solution for the P3D v4 version of the addon, there is an FSX version, for which I did not provide sunglasses. I am guessing that I still can, by using actual geometry, with an attach point, to mimic your Liberty XL. Is this at all correct, or close? Any hints on procedure?

 

[Deleted member 1281]

Wellll ... the contested formula is

(E:TIME OF DAY, number) 8 >= (E:TIME OF DAY, number) 17 <= and if{ 1 } els{ 0 }

If E:TIME OF DAY only returns 0, 1, 2, and 3 (as per SDK, Bill's comment, my earlier posts) then the 'and' operator will yield 0 and the overall result will also be 0. Used in the context of a vis condition it means that the part associated with that condition will never show.

Note that I am careful using an "if" in the above statement, and everything depends on it. So if anyone can show that E:TIME OF DAY under certain circs is apt to return numbers like 10 or 17 or 24 or 1001 then the conclusion is invalid, and I for one would be very surprised.

I'll accept Rick's picture as some kind of counterevidence. As he has challenged me to replicate it, I will do so in a moment. Standby.

 

[Deleted member 1281]

This, in a 3DS Max viewport, is a Follow-Me Jeep experimentally fitted with five 3-D parts representing the figures 0, 1, 2, 3, and 4. Parts 0, 1, 2 and 3 have been linked to environment conditions dawn, day, dusk, night using "my" code as shown on page 1 of this thread. Part 4 I have linked to Rick's "daylight visible" code, to wit :

<PartInfo>
    <Name>daylight_visible</Name>
    <Visibility>
      <Parameter>
        <Code>
          (E:TIME OF DAY, number) 8 &gt;= (E:TIME OF DAY, number) 17 &lt;= and if{ 1 } els{ 0 }
        </Code>
      </Parameter>
    </Visibility>
</PartInfo>

 

[Deleted member 1281]

And here are the results, zulu and local times circled in the 2d popup.

To spell it out, part 0 shows at dawn, part 1 in daylight, part 2 at dusk, and part 3 at night. As anticipated, part 4 ("Rick's part") does not show at all.

Now that we have two contradictory pieces of visual evidence, the logical follow-up question is to inquire into differences in our development processes. One, perhaps too simple, answer is, I am using Max (the SDK's suggested design program), Rick is using MCX (a post-processor). I have a hunch that if we take it from there, a solution to the contradictory evidence will be found.

For anyone interested in interrogating this further, here is a zip that includes the jeep mdl and the modeldef code used.

https://www.dropbox.com/s/7ha4bg4u5xuuq35/jeep-ac.zip?dl=0

 

[=rk=]

Now that we have two contradictory pieces of visual evidence, the logical follow-up question is to inquire into differences in our development processes. One, perhaps too simple, answer is, I am using Max (the SDK's suggested design program), Rick is using MCX (a post-processor). I have a hunch that if we take it from there, a solution to the contradictory evidence will be found.

The visual evidence is NOT contradictory, the simple answer is incorrect and you don't need a hunch, you need to read and understand what I have been telling you since the thread opened.

As of P3D v4.4, there is an altogether new way of allowing conditional visibility, through material rendering only.

This information was detailed quite clearly in Arno's post, which I duly linked in the Original Post, fulfilling my responsibility to inform:

This evening I have been testing Prepar3D v4 a bit more and I have especially looked at using visibility conditions in scenery MDL files. Before these were not supported at all for MDL files placed through BGL. We had to use SimObject for them, as tools like SODE do.

But with Prepar3D v4 things have changed a bit here, and I have been testing what that could mean. So what I did is add a simple visibility condition to part of an object.

The link to the above statement is in the OP and also several places throughout this thread. I have spent several posts, simply trying to apprise you of this one, singular fact. Thank you for showing me that the old school technique still works. Now you can pay me back for my due diligence, by providing me the code statement that actually works, using traditional, old school. attached parts, so I can make my FSX version also, conditionally render sunglasses. I'm sure I could figure it out and I'm sure I've already expended the necessary energy, simply championing the truth. Thank you in advance.

As he has challenged me to replicate it, I will do so in a moment. Standby.

I did not challenge you to debunk it. I challenged you to reproduce it, by assigning a conditional visibility condition to a material. You used attached objects, that is not a reproduction of my procedure.

This, in a 3DS Max viewport, is a Follow-Me Jeep experimentally fitted with five 3-D parts
[/code]

 

[mole_man99]

Been following this, and trying in vain to combine daytime visible with seasonal visible. I wish to hide a volumetric seasonal grass model at night as it looks bad under dynamic light.

Spring visible code;
(E:ZULU MONTH OF YEAR, number) 3.0 &gt;= (E:ZULU MONTH OF YEAR, number) 5.0 &lt;= and if{ 1 } els{ 0 }

Dawn day dusk visible code from mjahn
(E:Time of Day, enum) 0 == (E:Time of Day, enum) 1 == (E:Time of Day, enum) 2 == or

Struggling to combine the two into one visibility code. Is it possible?

 

[=rk=]

You've not told us your simulator version. It is absolutely possible, as I've told you before. Bill and Manfred have laid out the traditional technique to do so, all that is lacking is the actual code and I'n pretty sure there's enough information here to establish an optimistic series of variation testing, to get a final working result. I am hoping that one or the other of them will gift us with that snippet.

I've done the same for the P3Dv4 technique. You should not use the term "zulu," imo, because it applies to universal time and by your description, you need to trigger from local time. There is also a term "absolute" for time, which is usually related to engine components.

 

[Deleted member 1281]

Been following this, and trying in vain to combine daytime visible with seasonal visible. I wish to hide a volumetric seasonal grass model at night as it looks bad under dynamic light.

Spring visible code;
(E:ZULU MONTH OF YEAR, number) 3.0 &gt;= (E:ZULU MONTH OF YEAR, number) 5.0 &lt;= and if{ 1 } els{ 0 }

Dawn day dusk visible code from mjahn
(E:Time of Day, enum) 0 == (E:Time of Day, enum) 1 == (E:Time of Day, enum) 2 == or

Struggling to combine the two into one visibility code. Is it possible?

Yes; and you better do use "ZULU" because that is what both the SDK and the provided modeldef.xml indicate.

The Time of Day setting you can shorten to (E:Time of Day, enum) 3 &lt; (meaning 'if E:Time of Day is less than 3, i.e. 0, 1, or 2 i.e. dawn, day or dusk, then ...')

Combine this with the Month of Year group thus:

(E:ZULU MONTH OF YEAR, number) 3.0 >= (E:ZULU MONTH OF YEAR, number) 5.0 <= and (E:Time of Day, enum) 3 < and if{ 1 } els{ 0 }

Translation: "If month is in { March, April, May } and Time of Day not night then show the part else don't."

Caution: not tested, just a suggestion. Can't test it here because I don't have P3D 4.4 and I don't do scenery stuff.

--Manfred

 

[GaryGB]

https://www.fsdeveloper.com/forum/threads/daytime-only-visibility-condition.445222/post-821384

And here are the results, zulu and local times circled in the 2d popup.

(image not included in quote)

To spell it out, part 0 shows at dawn, part 1 in daylight, part 2 at dusk, and part 3 at night. As anticipated, part 4 ("Rick's part") does not show at all.

Now that we have two contradictory pieces of visual evidence, the logical follow-up question is to inquire into differences in our development processes. One, perhaps too simple, answer is, I am using Max (the SDK's suggested design program), Rick is using MCX (a post-processor). I have a hunch that if we take it from there, a solution to the contradictory evidence will be found.

For anyone interested in interrogating this further, here is a zip that includes the jeep mdl and the modeldef code used.

https://www.dropbox.com/s/7ha4bg4u5xuuq35/jeep-ac.zip?dl=0

Hi Manfred:

Thank you for your ongoing efforts to explore and test this example of implementing conditional display in MDLs.

I believe this "vigorous discussion" may contribute to a better understanding by the FS Developer Community, of how we might utilize options available within the criteria required by version-specific FS SDKs, to generate source code in a format that is compatible for use with specific versions of MSFS / LM-P3D compilers and run time rendering engines.

As we follow this discussion, and endeavor to increase our understanding of the subjects being explored and tested, some of us would welcome the opportunity to see the Jeep MDL rendered in MCX as well as in FS / P3D ...with the mapped texture Materials.

I believe that would allow us to better test whether / how conditional display may actually be able to toggle texture Material visibility by "direct" control over rendering of only the mapped texture Materials ...versus indirect and "incidental" control over rendering of mapped texture Materials by toggling of the 3D model geometry onto which the texture Materials are mapped .

Would you please also make available for download, the mapped textures for the Jeep MDL linked above ?

Thanks very much for your consideration, and your patient participation in exploring how to use these SDK options.

GaryGB

 

[Deleted member 1281]

Gary, I don't think it's worth the effort. IMHO, MCX, based as it is on a process of decompilation, translation, and recompilation, is not particularly suited for testing code. (Runs for cover.)

 

[Deleted member 1281]

@Rick: Don't mean to annoy you any further so I'll bow out of this thread.

 

[mole_man99]

P3Dv4.5 it is.
Solved my desire in the end with the seasonal visibility and a transparent lm with blend emissive mode to hide the object at night.

Will try out the combined visibility string though suggested above.

 

[Christian Bahr]

Will try out the combined visibility string though suggested above.

If I'm not mistaken and if the object is in a BGL Lib, then please adjust the code so that it has an "O" in the code and not an "E". Since P3Dv4 you can also put variables into objects. They are the so-called object variables. It exists in addition to the already existing variables. See the SDK here:

With these object variables is very much possible. You can combine them very diverse. This is how you can tell an object that it is displayed in precipitation (rain or snow) and given precipitation strength (PrecipState) in combination with the visibility (fog). A classic example would be the lighting of an airport such as CenterLights, TaxiLights, RunwayEdgeLights etc. It should even be possible to create a proximity sensor. With him it would be possible that a hangar gate opens when you are from a predetermined distance to it. But how that works, there we are at the moment still puzzling

In one of my previous projects, a zeppelin flies a scenic flight over the city. However, only at certain months (summer season). In winter, the zeppelin does not fly. The code for this is quite simple and corresponds by and large to the code shown by Manfred

 

[n4gix]

Also, please Bill, this was my solution for the P3D v4 version of the addon, there is an FSX version, for which I did not provide sunglasses. I am guessing that I still can, by using actual geometry, with an attach point, to mimic your Liberty XL. Is this at all correct, or close? Any hints on procedure?

As the Liberty is an FSX model, the exact same script will work in both FSX and P3D (any version).

 

[=rk=]

Thank you everyone, who participated in the thread. It is one of the most informative I've had here. I just completed conditional rendering of a FSX model, thanks to Bill's observation that I already had all the information necessary to complete the model. In fact, I used the exact same mathematical argument, or XML operation, self (and FSDeveloper) taught, I am unclear about the term.

I'm going to conclude that the LM conditional material rendering enhancement, is almost entirely redundant. I am able to claim this because my procedure in MCX was materially, forgive the pun, identical. In MCX Hierarchy Editor, for P3D, I pick the model part, which somehow corresponds to it's texture - at that level, the part name is visible, the part texture is visible, number of polys is visible and the only fields that can be changed are vis condition, mouse react, etc. In MCX Hierarchy Editor, for FSX, I pick the model part and somehow, the underlying geometry is selected, as attached, to which the visibility condition is applied.

It seems somewhat "double slitty" to me, as in the conditional assignment applies to that which the user expected, else, it seems like I never actually applied the P3D conditionally rendered material enhancement.

 

[arno]

As the Liberty is an FSX model, the exact same script will work in both FSX and P3D (any version).

For scenery such conditions are only supported since P3Dv4. Before that they need SimObjects placed with SimConnect.