Material instance parameters that affect only LandscapeGrassOutput nodes do not appear in the material instance editor’s parameter list. As soon as such a parameter is connected such that it affects also the main material, it will become accessible in material instances.
Version: 4.9.0-2672455+++depot+UE4-Releases+4.9
Repro steps:
Create a new Blank Blueprint project.
create a new material and rename it to, say, Mat.
create a new material instance from the just created material (right click → New Material Instance). The editor will name it to Mat_Inst.
Open the Mat material in the material editor.
Add a LandscapeGrassOutput node.
Add a ScalarParameter node and set its Parameter Name to, say, FooParam1.
Add another ScalarParameter node and set its Parameter Name to, say, FooParam2.
Connect the FooParam1 node to the LandscapeGrassOutput node.
Connect the FooParam2 node to, say, the Base Color input of the Mat material node.
Save the material. The Apply button becomes also automatically grayed out.
Open the Mat_Inst material instance. You will see that only FooParam2 is listed in the Parameter Groups list.
If you go back to Mat and connect the FooParam1 node to, say, also the Metallic input of the Mat material node and save or apply the material, then also this parameter will become accessible in the material instance Mat_Inst.
I have gone through with a test project and recreated what you see. However, this is intended behavior of the engine. The grass layer is not meant to take scalar Parameters. instead it is used with materials to paint layers.
Here is a link to our documentation that deals with the grass output node in the above mentioned workflow.
Thank you for your answer. I understand that the default use case for a Grass Output node is to just sample from a hand-painted layer via a LandscapeLayerSample node, as in the tutorial you mentioned.
I have a setup of this type, except that I have some additional computations between the LandscapeLayerSample and the LandscapeGrassOutput node. In my case, this is to have less of the primary grass type when approaching water level, and to have a patch of different foliage at a certain distance from water.
Yes, I could paint these foliage variations by hand, but my point was to make it procedural, so that the foliage reacts automatically when sculpting a large landscape.
The problem is that touching any constants in these additional computations will trigger a lengthy recompilation of the terrain shaders. Parameterizing these constants would permit tweaking them with no shader recompilations, taking the iteration time from around 5 min down to real-time response.
It is easy to circumvent this problem by connecting such parameter nodes also to some dummy inputs in the main material network. However, I would guess that changing the Grass Output node to detect upstream parameter nodes, just as the master material node does, would be relatively trivial? I think that this would be a justified change, given that the whole goal of the Grass system is to facilitate a procedural approach?
I definitely see where you are coming from and what you are intending to do. However, procedural foliage by design looks for the information you have assigned to that particular layer. It calls the function, say “look at layer x” and tries to associate it’s given information with that layer.
So if you assigned a foliage to a layer grass, that foliage is looking for that material that you have on that layer. At this time it is suggested to paint lightly a layer around the edges you want less dense grass a lightly saturated material.
At a value of 1 when you paint your material on your landscape the foliage will be at it’s most extreme and will call at 100%. If you went around manually, and I know this is counter intuitive to a procedural workflow, and painted a material with an intensity of .5, your foliage will have an intensity of 50%.
At this time a true falloff function derived from procedural created foliage is not supported. If you would send me a screenshot of your material and how you are intending to implement this, I will look into a possible feature request for this workflow.
The landscape in the screenshot is painted with 100% ‘Grass’ everywhere, except for the rocky areas on the right side of the cove. The ‘Hand-painted Wetness’ layer that is referenced in the blueprint is not used in this area of the landscape.
The amount of grass (controlled by the ‘Dry Grass’ output) goes gradually to zero as the ground level approaches the water level, and there is a patch of ferns at a certain height (controlled by the ‘Damp Grass’ output).
The bunch of ‘Wetness value’ connections going down in the blueprint control the shiny, wet look of the actual landscape material near the shoreline (best seen on the sides of the cove).
Having this as a procedural system makes it possible to sculpt the landscape and immediately see how it looks with the final vegetation in place, which makes sculpting large landscapes not just a lot faster but also even more fun as what it has always been. (yes, it was fun already in Populous! :D) It would be indeed nice to see this workflow become also officially supported.
Thank you,
Hiili
Edit: The ‘Shore Wetness Distance’ parameter in the ‘Wetness value’ block works because it affects also the main material via the bunch of links that go downward in the blueprint. However, it is currently impossible to parameterize the ‘Dry grass sampler’ and ‘Damp grass sampler’ blocks, as described in the first post.
What is the status of this feature? I am making a landscape material where the user can paint different types of landscape and i want the user to be able to set the foliage density per landscape type. To circumvent the problem i drag off after the parameter instances multiply it by 0 and connect it to emmisive color to make it appear in my material instance. Please fix this :s
I’ve also just encountered this issue.
It isn’t really an issue per se, but it would make landscape development much faster. I use several parameters that control the masking of LandscapeLayerSample meshes, but in order for the parameter changes to take effect I have to resave the parent material. That is currently the only way to force any sample meshes to update.
As I am working with a landscape material, each save takes about 50 seconds. It isn’t a show-stopper, only frustrating if you are impatient like me :).
I was hoping I would find a [Update All LandscapeLayerSample instances] menuItem/command in the Landscape tool or LandscapeLayerAsset that would force a refresh of such nodes, but I knew that was just wishful thinking.
(yes, it was fun already in Populous! :D) It would be indeed nice to see this workflow become also officially supported.