SUMMARY
Plants placed in a POI's cultivation .toc render only from certain camera
positions/angles. The same plants, unchanged, blink in and out as you move the
view around them. Objects from the list_xref in the SAME .toc are unaffected.
It looks like it depends on the TERRAIN ALTITUDE: at ~583 m the plants blink;
the identical file at ~4 m is rock solid.
(1) REPRODUCTION
Attached: two POI folders. They are byte-identical except for their location
and the terrain height under them. Same generator, same three plants
(conifer/00, palm/08, shrub/11), same 150 m comm mast as a reference object.
A) w11678n3485_pl_ab_high_kdag - KDAG runway 26, terrain 583 m
B) e00789n5418_pl_ab_low_heligoland - Heligoland, terrain 4 m
Copy both into Documents/Aerofly FS 4/scenery/poi/ , restart, then:
1. Go to KDAG (Barstow-Daggett). You start lined up on runway 26 facing 270.
The POI is 400 m down the runway.
2. Move the camera around the plants: closer, further, higher, lower, orbit.
=> the plants appear and disappear. The comm mast never does.
3. Go to Heligoland and do the same with B.
=> the plants stay visible from every angle.
(2) EXPECTED vs ACTUAL
Expected: a plant behaves like any other scenery object - visible whenever it
is in view.
Actual: at 583 m the plants are culled from most normal viewpoints. They come
back when the view is wide / far / looking down. Two of us hit this
independently, with different files, before comparing notes:
- "the plants can be seen in KDGA if the view is far enough away"
- "the trees are only visible from certain camera angles"
The plants, when they DO draw, are in exactly the right place at the right
height. So this is not a placement problem - it's a visibility/culling one.
(3) WHAT WE THINK IS HAPPENING
The terrain altitude is the only variable we changed, and it flips the
behaviour:
Heligoland 4 m -> stable from every angle
KDAG 583 m -> blinks (579 m apart)
tm.log shows the tree system is a tile grid built at startup:
tmterrain_trees: gridsize=4 maxvis=32 tiles=864 texbufmem=243MB
tmterrain_trees: treevisr=32 numtiles=864 treenv=262144 treevbsize=5120kB
Our guess is that a tree tile's bounding volume is computed WITHOUT the terrain
height under it - i.e. as if the ground were at 0. At KDAG that puts the tile's
volume 583 m below the trees it holds, so the frustum test rejects it from any
normal viewpoint; only a wide/distant/downward view still intersects the volume
down at sea level, and then the trees pop in - drawn correctly, because only
the CULLING was wrong, not the placement. At Heligoland the terrain is already
~0, so the volume is roughly right and nothing blinks.
That's a guess from the outside - but it fits both observations (visible when
far, visible at certain angles) and it explains why sea level is immune.
(4) WHY IT MATTERS
The world's own vegetation is unaffected in normal flight, so this has probably
been invisible until now: it only bites plants placed in a POI at altitude. It
makes list_plant unusable for any POI above the coast, which is most of them.
Same behaviour on 2 machines, 2 different sets of files, FS4 current build,
Windows 11 / Vulkan.
(5) WHAT WE ALREADY RULED OUT
Not the file, and not placement:
- The .toc parses with zero complaints. tmfile_properties validates every
property and reports unknown ones by name; it says nothing about ours.
(We confirmed the log DOES speak by adding a bogus property on purpose:
"WARNING: property 'pct_canary' is not a member of type 'plant'".)
- The list_xref in the SAME file renders its mast from every angle, always.
- The plants draw in the correct position and at the correct height whenever
they do draw.
- Not <[bool][autoheight]>: that one is understood - true forces every plant
to height 0 and ignores its altitude, which is a separate thing (thanks to
ApfelFlieger for finding it). These files are all autoheight=false.
