Custom Vegetation Draw Distance

[Wookie042]

Hello,

so I decided to start again with some scenery development after a long hiatus from MSFS and since I'm mostly interested in bush and backcountry flying, a huge part of the sceneries is vegetation.
Now it seems that custom vegetation seems like a blackbox topic, since I can't really find a lot of information on it in general.

I created a prototype spruce tree for testing purposes. The tree is build in Speedtree and then textured and exported through Blender.
For the foliage I use simple planes using an atlas as texture with transparency so to only render the actual small branches. So far so good. Pretty standard technique (see attachments 1 & 2)

When I place them in my testing scenery, they work ok, apart from some obvious color correction that I have to do.
The problem is when I move away from the tree, the planes I use for the branches start to disappear, meaning the draw distance of the branch planes is way less than that of the actual trunk and the larger branches.
This leaves the tree looking like a dead tree without any foliage just after a few hundred feet distance (see attachments 3 & 4). The model is a single model comprised of different meshes (trunk, big branches and the planes).

The second in-game screenshot has been taken with the camera only around 400m away. The disappearing effect starts before that, but after 400m no foliage is left.
That doesn't seem a huge problem for smaller vegetation types as for example bushes, since at those distances they are to small to see this change very prominently (as far as my limited testing showed).

Now the question. Does anybody know how to prevent that happen or a technique that is better suited for the job? I had hoped that I could ditch cross section vegetation all together and go for full 3D models.
The invisible cube or plane technique won't work here, since it's only parts of the model disappearing and not the entire object. However, I haven't tested this with the trees yet.

Any help or hint is appreciated!

 

[GaryGB]

Hello:

Did you use LODs in your 3D model ?

If you do not intend to do so, you could extend the horizontal planes of the tree limbs outwards to fool the LOD rendering system.

The area peripheral to the end of the tree limb extents would of course need to be transparent so the extended planes would not show.

GaryGB

 

[=rk=]

Construct your tree model such that part of it is an extremely large, low polygon box that remains underground. I believe you can also achieve this effect using a 2d polygon. You can experiment with sizes to suit your preference over where your override cuts in, that glitches the LOD algorithm.

 

[rhumbaflappy]

As usual, you probably need to zip the problem object, and attach it to a post or personal message. You should include the glTF, the BIN and the textures, as well as the XML.

 

[Wookie042]

First of all, thanks for all you answers and help.

Instead of starting to follow some of your advice, I stubbornly started out to try different things myself (which of course doesn't mean that I don't appreciate your inputs)
Fortunately, I think I found a solution to the problem that doesn't involve LODs, invisible geometry or excessive scaling.

The solution is to create a double sided material for those small branches in Blender, which completely gets rid of the decimating mechanic in MSFS (as far as my testing went).
In order to get a double sided material, I duplicated my BSDF Principled shader, mixed them with a Mix Shader and blended between them using the backfacing input from a Geometry Node (see attachment 3).
I then baked the materials into on texture map (the usual thing I do), created a MSFS standard material with "Double Sided" checked and it worked.

I include this info here, so that when others run into the same issue, this may help them, since there is a general lack of knowledge for custom vegetation.

I will probably return with more problems that I encounter in the future, but for now this seems to have been solved.

Another thing I need to figure out is, why the color change occur when moving away from the tree model. It starts out as quite bright saturated green and get's increasingly darker the further I move the camera away.
Maybe someone knows why that is.

Attachment 1: First prototype (right), second prototype with bigger planes (center), third prototype with double sided Blender and MSFS material (left)
Attachment 2: View from some distance. I could not see the decimating effect to come into work even with much larger distances.

 

[GaryGB]

That is an intriguing report of run time behavior by the MSFS rendering engine.


Although I do not yet tinker with Blender much, in Sketchup, by default, all Faces are already double-sided.


IMHO, convoluted wiring algorithms in Blender's GUI to make a double sided Face, is less likely to encourage any use of Blender.

Almost as much fun as what GMAX and 3DSMAX used to require in order to make a double-sided Face.


I always use (multiple) crossed planes for vegetation using textures on both Faces of the planes that have Alpha channel transparency.

The Alpha channel transparency is applied in the graphics application used to prepare the vegetation image before mapped to Faces.

It is interesting that MSFS' rendering engine may not resolve- or not use- Z-sorting distance from A/C camera to 3D model for "culling".

How far out from 3D models have you tested for 'culling' of the 3D models from any visibility within the (distant) scene at run time ?


Christian Bahr and others have shown methods here for increasing run time visibility distance of airport lights using large planar Faces.

This was necessary in FS2Kx, and purportedly was found to be necessary in MSFS as well.

https://www.fsdeveloper.com/forum/threads/3-d-lights-in-msfs.449625/post-869145


Rhumbaflappy posted an example from which one might infer an approximate distance at which culling may occur based on planar size:

https://www.fsdeveloper.com/forum/threads/msfs-scenery-lights.455868/post-906887


This interesting reported quirk of MSFS' run time rendering engine visibility with 3D Faces that are double-sided merits further testing.

GaryGB

 

[Wookie042]

Sorry for the late reply, I've got sidetracked a little

IMHO, convoluted wiring algorithms in Blender's GUI to make a double sided Face, is less likely to encourage any use of Blender

Within Blender, every material is double sided by default too. In all my renderings, I've never needed to use it, but somehow, it makes a difference for MSFS.
Convoluted may be the wrong term. The node setup shown in the picture takes 30 secs. to set up.

I've done some more tests and it seems that even though the alpha planes for the branches stay much longer when setup as double sided materials within Blender AND the MSFS standard material,
the entire tree model get's culled at a distance of roughly 5km or 3.1miles, so I guess I have to revert back to the invisible geometry to make the tree model stay visible for longer distances.

 

[Joker]

Hello,
Any help or hint is appreciated!

I also model my trees in speedtree. MSFS texture compiler is not perfect. He, often, does not quite understand what you need in the end. There is a problem in mip maps. Or rather, in the alpha channel of mipmaps. Therefore, I recommend that you do the following:
I do everything in photoshop
1. Flip the Texture Vertically
2. Save it in bmp format with a name, for example: "Trees". Then reduce it by 50%, be sure to pre-configure the "best for reduction" interpolation. Save this file, for example: "Trees_1"
3. Repeat step 2 until the texture sheet is completely reduced. (It all depends on the original size) Your final texture will be about 4 x 4 px.
You will get several textures like Trees.., Trees_1.., Trees_2.., Trees_3 and so on...
But that is not all! Now the most important
...you, in parallel, and separately, need to do similar manipulations with a decrease by 50%, as well as the Alpha channel of this texture. Why separately..? Because the alpha channel of the texture must be reduced with the interpolation "clear edges"
To do this, I immediately create an additional document with a black and white image of the alpha channel in Photoshop, and, with each decrease in the size of the main texture sheet, using the copy-paste method from the additional document, I insert this reduced black and white image into the alpha channel of the main texture sheet.
3. Then you will have to run, for example, the ImageTool utility. Open the "Trees" texture in it
Activate the Add Mipmaps function and, having selected all the textures of the Trees_1.., Trees_2.., Trees_3 and further types, add them. Then Image - > Format - > DXT 5 and save this texture sheet with a name, for example: "Trees.PNG.DDS"
This method is complex and requires a mature nervous system. But, having done this once, you save this texture in a safe place, and, every time after compiling your scene, you replace this texture with the one compiled by MSFS.
You will like this method of texture replacement much more. Now, when moving away from a tree, a sudden autumn will not come for it.
I apply this technique not only to tree textures. But it's much better for trees.

 

[rhumbaflappy]

For those less inclined to pay for SpeedTree, there is a freeware alternative: Tree It
There are examples you can download, and although the author doesn't want his examples used in the game, you can use them as a base for making your own variations, and those are allowed.

I export as OBJ, then make the PBR with MCX. You'll have to make LODs or else your forest will kill the FPS! It becomes addictive.

 

[Joker]

... but I really like the default MSFS trees.
They are much more beautiful than custom ones with "inverted" normals. They have almost no effect on FPS and look very convincing from a distance. We don't need high poly trees in the Sim. We don't go there to pick mushrooms. And I, for several days now, have been looking in vain for a way to arrange default trees one at a time and clearly at specific coordinates. Unfortunately, this is not possible with polygonal spacing. Something suggests that the default trees in the Sim are implemented by the method of effects. Because they react to the wind, they have only one polygon, and this polygon is always turned to face the user.
But this topic, for some reason, is heavily conserved ...
Many years ago, I was well versed in the technique of creating and placing effects in FS 9 and FSX ... But I can’t find information anywhere on how to do this in MSFS 2020, and create my own custom trees similar to the default ones.
I would appreciate any help.

 

[GaryGB]

I believe Arno's ScenProc is a W.I.P. en route for a rendezvous with destiny, to enhance MSFS with more accurate vegetation placement.


Meanwhile, we need a MSFS 'Polygon-fill' placement randomizer with "jitter" of scale / interval distance / heading ...as we already have for FS2Kx.


Indeed, MSFS default trees appear to be Rotate-To-Camera (aka "Face-Me") Sprites with reduced color bit depth and very shallow LOD switching.

They also seem to have a Alpha- (or other ?) 'fade' mechanism that dissolves the object into a "dithered" detail texture as it vanishes.

https://en.wikipedia.org/wiki/Dither


The odd thing is, a LOD and/or angle of camera view change relative to a tree, results in a different tree Sprite texture image MIP / size / angle.

In some cases a tree MIP does not even match the original tree as seen in a original straight, line of sight, user A/C camera view of the tree.


Palm trees in MSFS' default Las Vegas roadway median strips are now volumetric / manifold / able to occlude and reflect street lights.

[EDITED]

Perhaps there may be a Fresnel Ramp "Shader" Material Functionality utilized as Anthony31 alluded to here...

https://www.fsdeveloper.com/forum/threads/cross-plane-shading.455131/page-2#post-912042

https://www.fsdeveloper.com/forum/threads/cross-plane-shading.455131/post-912116


Those of us that recall how FS2Kx Autogen tree "Alpha fade" was replaced by quad-based draw call batching for rendering performance, might wonder whether some sort of Vertex shader mechanism is being used to "fade" MSFS tree Sprites.

[END_EDIT]


If one reads the FAQ on the Tree It web page Dick linked to above:

For those less inclined to pay for SpeedTree, there is a freeware alternative: Tree It
There are examples you can download, and although the author doesn't want his examples used in the game, you can use them as a base for making your own variations, and those are allowed.

I export as OBJ, then make the PBR with MCX. You'll have to make LODs or else your forest will kill the FPS! It becomes addictive.

...some additional useful info is disclosed:

http://www.evolved-software.com/treeit/treeit

"How can I export wind animation?

The wind animation is a procedural effect handled by a vertex shader using vertex colors for reference. Check out this GPU gems 3 article for detailed explanation about how this procedural animation technique works. Wind info for vertex colors is exported as part of the dbo and fbx formants.

Chasing the above GPU Gem 3 link:

https://developer.nvidia.com/gpugem...ation-procedural-animation-and-shading-crysis

...we see this info:

"Chapter 16. Vegetation Procedural Animation and Shading in Crysis
Tiago Sousa
Crytek

At Crytek, one of our primary goals for Crysis was to define a new standard for computer game graphics. For our latest game, we have developed several new technologies that together comprise CryENGINE 2. A key feature of Crysis among these technologies is vegetation rendering, which is composed of several parts, including procedural breaking and physics interaction, shading, procedural animation, and distant sprite generation, among others.

Vegetation in games has always been mainly static, with some sort of simple bending to give the illusion of wind. Our game scenes can have thousands of different vegetations, but still we pushed the envelope further by making vegetation react to global and local wind sources, and we bend not only the vegetation but also the leaves, in detail, with all computations procedurally and efficiently done on the GPU.

In this chapter, we describe how we handle shading and procedural vegetation animation in an efficient and realistic way."


Plenty there to keep us busy studying / testing this methodology for a while.

GaryGB

 

[=rk=]

For those less inclined to pay for SpeedTree, there is a freeware alternative: Tree It

What a find, eh? On a site dedicated to "Dark Basic" and here I'd thought our hobby was niche. One consideration about Speedtree, is that the speed part of the name applies to movement, in case some of us had thought it implied easy to use. They are animated and that is kind of the big draw for that product. By default, they have a kind of snakey, sinewy gyration and keying that to the MSFS wind, seems ambitious. Your alternative might be more practical.

Something suggests that the default trees in the Sim are implemented by the method of effects. Because they react to the wind, they have only one polygon, and this polygon is always turned to face the user.
But this topic, for some reason, is heavily conserved ...
Many years ago, I was well versed in the technique of creating and placing effects in FS 9 and FSX ... But I can’t find information anywhere on how to do this in MSFS 2020, and create my own custom trees similar to the default ones.
I would appreciate any help.

I have not seen evidence of default trees moving or changing in relation to wind, I have seen grass move in heavy wind. Is tree wind reaction similar to this?

If you watch this pattern, it looks like the grass is sequentially depressed, it does not actually move laterally and to me it looks almost exactly like the grid pattern of the ocean swell, implying the water surface is "grown and shrunk" similarly.

As to effects, the MSFS engine is a particle system, almost exactly like the FSX system, in that particles rise and fall according to temperature. If I were to draw an analogy, I would say the MSFS system is "less focused," we cannot (yet) make those laser like bullet trails, water fountains, or convincing fire, but water drop effects, smoke flares, anything "smoke," is essentially identical. As far as the information being "heavily conserved," I see little financial, or other incentive to withhold development aspects of a visual adjunct to an otherwise fully functional flight simulator. More likely, the information simply does not exist. The base code was rewritten from 20 year old software and all the bells and whistles, AI traffic, visual effects, sounds, came along with it. Some things made the transition better than others and we, my friend, are essentially pioneers, is the way I look at it. This is a whole new take on the old simulator, yet to be fully discovered.

 

[Joker]

I have not seen evidence of default trees moving or changing in relation to wind, I have seen grass move in heavy wind. Is tree wind reaction similar to this?

they are moving. And this is absolutely true. But this requires a little strong wind. However, everything is just like in real life...
Try to speed up the wind speed and you will surely notice it.