I would say look also at the ground texture, it’s generally a multitexture lightmap, but it’s not just strict separation of various but obvious texture, in the xenoblade example they are pushing the hardware to have HUGE open field, so the texture is quite simple with obvious repetition, but here is final fantasy explorer:
Around 5m
You can see the ground has a flower texture that is intermittently blended with plain grass, look at how the grass mesh are strategically place as groups that contrast with group of flower, also in way to break the empty space into area, and how smaller group of grass is placed at edges and objects. The same technique are used with denser grass system. The point is to use the splat to blend the various ground texture in way that help merge with the spot of grass. You can see there is also bare ground strategically place visually around the map, and they use texture to simulate cloud, that give even more life. Pay attention at how they manage the horizon shapes too, the whole composition really help, even though you care only about grass, the whole impression is what give the cachet.
Now when you look at that, you realize that’s not so dense after all, there is a lot of line of sight management with tree blocking the horizon very often, more fuller bush (which are close), open sight are much sparser with shorter simpler element of grass and bush, and grass itself is extended by the ground texture, ie under the grass the texture tend to be close in color, and then it shift to another color, still close, but less saturated. So the whole composition help in managing the impression. Notice there is at least 3 tiers of height for solid mesh, from bush to small tree and big tree, and they come in 3 variation each even if just a slight color shift.
How big is your terrain? Is it one terrain object or multiple terrain objects? I haven’t used Unity in a while, but messing with terrains can be hella cumbersome. There are tools that make this easier, like CTS (Complete Terrain Shader). It will allow you to use PBR textures on your terrain and there are several blending options for each texture. You can also adjust the lightness/darkness, hue, etc of each texture. I would try this out.
As I said, building a terrain can take a very long time. Like months if it’s “large”. There’s a lot of tedious work involved. You should export your heighmap (which should be a built-in tool in Unity) and apply that heightmap as displacement to a plane in Blender (or your modeling tool of choice). Use that model and Photoshop (or Gimp) to create a splatmap for the terrain (this is the tedious part).
There are other tools that can help you make splatmaps and terrains. Check out WorldMachine:
Another Tip: If you want a “realistic” looking terrain, you’re going to have to spend money on tools. OR it’s going to take you quite a while to create a terrain will be a direct reflection of your artistic ability.
I’d like to point out that a lot of the examples people are giving of “AAA games do this badly, so don’t expect too much” are considered extremely bad implementations in pro game studios. Just because some titles choose to have crappy graphics in this area doesn’t mean it’s acceptable (especially: not to players!). Most of the examples above are so bad they’d have been ridiculed even 10 years ago, let alone today. (I was working in a major FPS studio when TES 4 / Oblivion came out, and the first thing that happened was the graphics programmers laughing at how bad the grass rendering was. It’s a fantastic game, but in the words of one of our graphics leads: “Bethesda has never bothered to learn - or spent the money to hire - anyone competent at terrain rendering, they focus their money on content-generation/quests/gameplay”. I thought it was a bit rude, but had to admit it seemed accurate :)).
@SomeGuy22 good work on persevering with this, and thanks for documenting your ups and downs. It’s great to see where this is still difficult in Unity today, vs where different approaches are now easy, and how effective they each are.
(I’ve been lurking on the thread for ages because I have a project in progress that’s going to need some good grass sometime soon, and the few quick tests I’ve done using mainstream asset-store packages have been painfully bad, so I’ve been resigning myself to the probability I’ll have to invest a few weeks hacking together a solution that doesn’t suck. I’ve written basic geom/vertex grass solutions in the past, so I have a rough idea how to hopefully merge some of the techniques here, but I’m not looking forwards to it … Seeing your trials and successes is a great help!)
Line of sight blocking should indeed help hide the transition between grass and terrain, and bushes as you mentioned can also break up this pattern. When I get a chance to work again I’ll try to add more of these types of plants and see how they flow with the scene. I also think tall rocks and cliffs could help the background and maybe make it feel more complete.
For this level, I use 4 terrain objects which are neighbors, and each are about 2000x2500. All of my levels will need terrains of this size, and many of them have 4-8 actual terrain neighbor objects. They’re not completely covered in grass, but it’s still a lot considering I have that at least 5 levels which need this sort of treatment.
I see… even if I do this though, I wouldn’t have the texture data which is again stored arbitrarily as a splatmap based on what Unity decides is best. Arguably the texture data is even more important than height, it’s to know which splat color correlates to which texture unless I do trial and error, and even that is prone to failure/change if Unity deems it necessary.
Personally I’m not a fan of this mentality, I don’t think any dev should ever “have” to purchase tools to get what they want out of their game. Of course, I think these kinds of tools are helpful and maybe it’s true that some games can’t be made without them. And yeah, there are limitations in Unity which need extension to deal with. But I’m not convinced that these limitations can truly set back a talented artist who has a clear design in mind. I’m obviously not good enough to really know how to push past these boundaries, but I’ll at least attempt to work with what I have or find some custom workaround to these sorts of issues. Maybe for some people that’s a waste of time, and that’s perfectly okay. But I think this is a good exercise in understand design constraints and how to work with them to get the best possible product. And I’m sure devs appreciate finding workflows which don’t require as much extension to work as close to Unity’s provided package as possible.
But as far as this problem goes I’m not against using external tools to get the job done. It’s just that I feel like I’m most of the way there already with this method and I think it’d be better to just exercise better design/planning instead of breaking the bank.
Yes that’s kind of my worry here. As I was telling my friend before who urged me to work on something else, the end user doesn’t care how many dozens of hours I spend on grass. Just because Unity limits shader rendering for grass doesn’t mean the player will understand that limitation or accept that it’s the best I can do. Unfortunately it’s on me if the grass/nature assets aren’t up to par, and when that negative review rolls in about grass quality it’d be my own fault for accepting a result I wasn’t happy with. That’s why I’m trying now to work with what I have and at least design the environment assets as best possible even with being stuck on this shader.
Off topic a little but I actually wouldn’t say that’s a bad thing. When it comes to development sometimes studios have to make sacrifices which impact the final product. For the example TES I’d say back then content generation and quests might have been arguably more important for players than grass rendering. It all comes down to how the player perceives it, and I’m sure that a majority of players preferred that focus on quests above grass at the time.
Thanks, I’m glad this thread is appreciated. As you can tell I tend to write a lot, but it’s only because I like being thorough and I know more information is better for people that stumble across this in the future. I will continue to update here as I work on grass and share what I’ve learned. I’m confident at this point that 90% of “good grass” is just design and artistic prowess*, even with Unity’s limitations it should be possible to make something I’m happy with. As the other user mentioned above, when it comes to working with “old” tech, look towards old solutions to the problem. Those older games are great references because they have figured out what works for them using tools potentially even worse than Unity’s terrain. Obviously it won’t fly for every project depending on style/target platform, but it’s a good starting point. Every time I see a new Final Fantasy reference I end up kicking myself because the grass techniques seem easy to replicate–I just didn’t have the vision or foresight to worry about it. I will study old games some more and see how I can improve the look of my scene.
EDIT: Okay maybe more like 60-70%. It’s hard to see the big picture until you have it running in your scene and some understanding of Unity’s workflow is important to work with it. Different Engines may have better solutions for grass density, etc. But if I’ve learned anything from level design timelapses it’s that you need good assets to make good levels. And beyond that, you need good placement and understanding of which assets to make to improve your scene. I really wish there were tutorials/timelapses out there which talk about how to make a level from scratch that don’t just pull from some pre-built library of store bought objects.
Why do you expect him to run when he’s struggling to walk, I personally choose very basic example so he can have some fundamental down, just like using contrast, placement, etc … so he can develop a sensitivity to it. Once he master that, he can then open an actual landscape manual to improve the composition, or find better tech to improve the density.
Also skyrim sold very well, so player might laugh, but so does bethesda’s banker.
AND if you find a better grass on wii level hardware (ie 3ds, gamecube or ps2) PLEASE SHOW ME so I can learn from it
Sounds like you’re trying to make a big game, which I don’t recommend. But if you DO try to make a big game, you’re severely hurting yourself if you don’t use 3rd party tools. Because it’s just not practical for one person to develop a big game. Why? Because it takes too long.
Modeling
Texturing
Animating
Sound
Gameplay
Coding
UI
and the list goes on
Its a time problem. This is why development studios have so many people.
Regardless of the size game you’re making, if there’s a tool on the asset store that accomplishes a specific task you need, use it. That’s what it’s for. If not, THEN make it yourself (which is what I did for my grass shader). Also, if you’re going to be a solo developer, you must learn how to write shaders. Shaders are the foundation of graphics.
Because what OP’s demanding is very reasonable and fair to demand from a game engine in 2015, let alone in 2020. The fact that it’s so difficult to get working in Unity today says a lot about how bad Unity’s terrain rendering setup is right now (and they agree! Improving terrain for artists is one of Unity’s big focuses right now! But grass isn’t at the top of the list, there’s worse problems they’re solving first, so for now … we have to self-help / help each other).
In case it wasn’t clear: the criticism of Bethesda’s tech was on the assumption that everyone already knew it was selling / going to sell millions of copies - as gamedevs, we knew very well that sometimes choosing to make bad graphics is the right decision :). But it didn’t change the fact that the world’s best open-world terrain-based game had one of the world’s worst (embarassingly bad) terrain rendering systems.
Sorry, I missed the part where OP said they were targetting 20-years-old hardware (PS2 launched in the year 2000). If OP’s trying to do that - sure, decent-looking grass is a waste of time, never going to happen.
I strongly agree on all this. But every pay-for grass solution I’ve tried from the asset store sucked donkey. The “classic” ones haven’t had the rendering system updated in years, and look embarassingly out of date today (seriously: Unity itself has greatly improved their handling of instancing, geometry shaders are now supported nearly everywhere, etc - it’s really sad to see these grass shaders using no new tech since 2013 or so).
Regardless, even if I had 3rd party tools, I still need to make the actual assets. It may look somewhat better in the end sure, but there’s a cost vs. payoff management which you haven’t considered. I haven’t told you anything about the project so if I was making the game free and just wanted to work better within Unity’s workflow I couldn’t justify spending $50 on CTS. Or if this is just a hobby project I wouldn’t care too much about expanding with complicated tools and would rather learn how to design as best possible with what I have. Of course, that’s not the case here. But for those hobbyists out there who feel this idea matches their project, that is where this sort of studying comes in handy and is a good reference for those kinds of people. And I still stand by what I said earlier grass being mostly artistic prowess.
I know as well as anyone that you can’t expect to just buy an asset store plugin and make all your problems go away. You need to learn to work with the tools and make environments accordingly to actually get good results. I’m sure many veteran devs will tell you this. If I don’t have a sense of what grass technique I want to go for then no amount of density or shader tricks will actually improve the look of my game, at least after a certain point.
Sure, but there’s a cost to it. And I’m not just talking about the monetary price. One would also need to learn how to use these tools which in all honestly could be days/weeks depending on the complexity of the asset. Any disruptions to workflow just add more time to development, which is totally fine for some. And then there’s compatibility with your Unity version and support as Unity gets more updated–will your assets go out of date and become unsupported? Will they work for multiple projects or just one? Is the cost of the asset worth the value you get from it? Can you recoup that cost with the amount of players gained by using this tool? Maybe for a lot of people the answers are yes. But again, I personally feel like it’s not necessary in this case, as I already have the tools I need, I just want to work better with them or find better tricks in using them.
Well yes, I know how to write basic shaders. I know how to plug in maps and modify colors and surface parameters. I’m no expect so there’s certainly more to learn here. But if you’re talking about adding performant LOD to grass objects I’d say it’s a little above what I normally do. I’m trying to be honest about my capabilities here, so yes I could probably do more research in that. But as you’ve already mentioned I have modeling, texturing, animating, sound, etc. to worry about. Learning more advanced shaders for this problem seems, again, like a time sink. I’d prefer to work with the workflow I’ve already started–the modifications to Unity’s grass shader I have in mind seem far simpler to accomplish than slice-based culling at any angle. I’ll do more research into shaders when I have less to worry about.
Just to be clear, I don’t think Unity’s terrain rendering setup is all that awful. I’ve been using the Terrain Tools package and it’s helped my workflow a ton. But you’re right that there’s definitely improvements to be made. It seems like normally we’d be able to edit the grass shaders but due to a change in 2019 that’s no longer the case. Aside from that I was able to get density down, it just required using neighbor terrains which wasn’t exactly clear. And I had to figure out wind and detail meshes, which again wasn’t explained but the framework is all there. Really what I’ve learned is that Unity just needs more documentation and tutorials on these sorts of techniques for customizing grass and working with dense fields in large worlds. Aside from that it should be passable for my tastes so long as I can make the assets well enough and that my design is solid.
Again I will stress that from those examples of old games that you don’t need top of the line rendering features to make something that suits your project. It’s really the design and art that pulls everything together. So long as your tools allow you to properly express your art. I wasn’t feeling like that was the case due to shader lockdown but after modifying the texture a ton I’m starting to get better results. Sure it could be better. But it’s not the end of the world, there are always alternate solutions, that’s why I’ve tried to explore them in this thread.
I’m not targeting old hardware, and I do think Xenoblade has mostly decent looking grass, even by today’s standards. It’s a more stylized approach which is why it seems to work in the game, at least imo. FFXV for sure has decent grass, again imo. That’s been my biggest inspiration and as you can see they don’t have giant full fields but rather carefully crafted grass with plenty of variations to fade well with the ground. That kind of stuff is actually achievable on old tech, and probably my best solution as it’s easier to manage. Though I will try and mix it with my field ideas from earlier now that my grass is matching the floor a bit better. Again, design takes the stand here–I don’t think hardware is the limit but rather the tools at my disposal and how I’m able to work with them.
@a436t4ataf I think we misread each other, I focused on artistic technique, no matter of tech will help you make something decent, only offer you a bigger palette. OP explicitly told about FFXV as an inspiration and if you followed the thread, he also struggle to make something artistically.
I think you’re missing the point here. My grass shader is the only shader I’ve ever written using shader code. Any other shader I made used the graph editor. It took me two days to write. I also spent weeks looking for the right grass solution for my application. Couldn’t find it, so I wrote that shader to do exactly what I needed. Then I just gave it to the community to “give back”. Writing shaders isn’t hard to do, you just have to know exactly what you need. In your case, you need these grass patches to:
Blend well with your ground texture
Perform well on big terrains
Have a draw distance
You can do all of this with a shader. The examples you have shown from Final Fantasy probably use some sort of shader technique combined with billboard grass.
Remember, billboard grass is heavy on the CPU - that’s why instancing was created. Geometry shaders are all GPU - which is what the GPU is good for.
Rule of thumb - if you have many many duplicated static objects, geometry shader is by far your best route.
Sure, but there are complications. For one, how would I get color information from other objects at a specific point? The shader as far as I know only understands it’s own rendering properties and pixel info, so I’d need some way to pass extra information into it to work with the terrain. Making a shader “perform well” is… well complicated. And the reason I say it is because draw distance would normally be determined through some distance calculation in relation to the camera. If I have a lot of patches that could get very expensive. Again, I’m not saying it’s impossible. I can do it if I take the time to research it. But as you can see from this thread I’ve spent an absurd amount of time on grass already so I’m hesitant to go deep into shaders for this sort of problem. I’m aware that understanding shaders is good for game programming, I’m just not confident that it can be written in a short amount of time.
But as I already explained it’s not just the shader which is stalling me from using this method, it’s also the idea of having to rebake the ground every time I want to make an adjustment to grass. Even if it only takes 5 mins per bake, that still pales in comparison to the 5 seconds it takes to paint in a new patch of grass or remove it in Unity’s detail tools, which makes iteration and testing much quicker. It also removes the guesswork because I can directly paint on the ground textures I know will be a certain color. Under your proposal if I make a change to the ground then I’d have to figure out a way to export that map to Blender, then repaint in blender, then export a splatmap with a custom tool, then probably modify it to work with your script. As you can imagine, even if I figure out a way to do this and work out all the tools I need to build to make it happen, it’s still a long process.
I’ve said this multiple times already but I’m already 90% of the way there with my current method. So apologies if it wasn’t clear but right now I’m just looking for ways to improve the method I’m going with (working best with Unity detail grass) and how to design my level and assets accordingly to get what I want. It’s more of an artistic/workflow approach at this point.
Thanks for the reference. I’ve already seen it actually, but it’s nice to review the basics. However, he doesn’t really go into asset creation itself which I think is what was holding me back for a while. He’s also using smaller terrains which means the grass plane method was dense enough in his scene. I use the grass detail method which are actual custom objects, and it seemed harder to match colors with that for some reason, possibly due to texture backgrounds/matte in PSD.
I’ve been working on tweaking colors a bit and making some extra nature assets which help to make the scene more lively:
One trick which I found to help was that I went into my grass textures and actually painted the bottom as black to give the illusion of shadowing at the base. Unity’s grass shader recieves shadows (based on terrain darkness) but doesn’t give them, so this was a good workaround that also is pretty performant.
I think at this point it’ll be all about placement and just more objects. I need a lot to get to the point I want to be at but at least now I have a clear direction. I talked with an artist on Twitter and he was able to give me a lot of suggestions to improve the fields and overall level direction.
That’s just how my setup tool works to make it easy to setup. It’s not necessary once you understand how my shader works. My shader takes any point cloud you give it. You can export your terrain into an fbx object, import that into Blender, subdivide the model to make it dense, then delete all the points you DON’T want grass, save just the point cloud (remove lines and faces), then bring that back into Unity as a mesh and apply my shader to it. No splatmaps would be needed for this.
All my setup tool does is create the point cloud for you while ignoring the black on a provided splatmap. But you can create this mesh yourself.
You can create a car model and import it as a point cloud and still apply my shader to it. I’m not saying you should use my shader, I’m just pointing out the power of using shaders in general. Don’t just toss out shaders as an option.
This expensive task is what GPUs are built for and there are specific functions in shaders that help with “distance from camera” called ObjSpaceViewDir. If you want draw distance on your grass, there’s no better place to do that than the GPU. If you do this with the CPU, you are severely hurting performance.
Keep that. But also try adding an Ambient Occlusion Post Processing effect.
Yes I understand, but even doing what you just described would require my terrain height to be final–if I ever need to redo a section or rework a part of level, say to direct a path in a different direction, or just shrink a certain space which already has grass, I’d need to go through the process of exporting, deleting faces, waiting for bake, etc. Perhaps in a AAA studio where everything is tested beforehand and designed with dozens of concept artists across multiple teams that would fly. But my process tends to be more iterative and rearranging level assets is a must for my working methodology. I’m not complaining here, just pointing out a limitation of pre-baking meshes without any sort of built-in paint tool. Obviously such a tool could be created for this purpose as an Editor extension, but again it’s a big undertaking and probably not worth it here when I already have Unity’s detail system.
Thanks for the tips. I do have AO as a processing effect already, I just didn’t want to mess with my settings and thought some extra shading on the grass would be less destructive to the rest of the scene. Not to mention if the user turns this effect off in the graphics options it’ll still show through.
I’ve encountered a pretty bad bug with grass currently and I don’t know what’s causing it. When I try to paint grass using the detail object method like I used to, it seems to be ignoring my target strength and just painting at max density all the time. Here are my settings: (If you still can’t see images due to forum weirdness you can click on each one to bring up the link)
Which doesn’t look right considering I was supposed to paint at .06 density. For reference, my terrain still has my older paints where the density actually worked, and here’s a few rocks which I believe were actually painting at a density higher than .06:
The target strength slider also seems to be locked down to incremental values now instead of being pure float, which also seems wrong. The opacity slider seems to work which still lets me paint in smaller densities, but it becomes an issue removing grass because apparently the shift-remove option uses that same opacity. This means if I paint grass with low opacity I can only remove it with low opacity as well. Previously I could just set my opacity to max with a low target strength, allowing me to paint low amounts of grass but still remove them instantly. Now I have to wait for the removal since it factors in the opacity which I must use, unless I go in and adjust it every time I want to remove, but of course that destroys the whole convenience of the shift key in the first place. Regardless, whatever is happening here is clearly a bug or some feature removal or something, it’s not right.
There are two candidates: 1. I’m using the latest Terrain Tools package (version 3) which could’ve messed with the setting and 2. I’m on Unity 2019.3.4f1. Unfortunately I’m unable to determine which is causing it since I updated my Terrain Tools before painting any grass on this version of Unity.
Perhaps @wyatttt can weigh in on this, since I’ve been relying on Terrain Tools for all of my terrain editing and it’s become necessary for my workflow. Maybe I could test if Terrain Tools is the issue by uninstalling it, but I’m concerned about what would happen to my project data as a result of that. I have Layer Palettes for multiple terrains in my assets folder, would they get ruined or interpreted incorrectly if I remove Terrain Tools? Is there any loss of data from my Terrain assets by doing this or can I safely reinstall Terrain Tools later? I know everything is just stored into splatmaps so I’m hoping I can do that but I’d like to be sure.
If this target strength thing is a bug with Unity 2019 I can submit a bug report. Actually I just thought of a way to test this, I will try it out in a blank project that doesn’t have the package installed and report back with my findings.
This seems to be the opposite problem of the bug I listed earlier here . My hypothesis is that target strength becomes somehow tied to the patch density somehow in the terrain settings, because my terrain patches are at max. This may explain why some people have an issue of not enough grass while I have too much. Regardless, this is pretty horrible and somewhat scary. It’s not the end of the world as I can still paint with low opacity at lower convenience, but having less control here will absolutely make terrain editing much more difficult as I rely a lot on having many detail objects and having specific strength values for each. I can’t afford to wait months on a potential fix this time.
Okay, so it looks like Unity 2019.3.4f1 is the issue. I’ve discovered that the target strength is factored in to the paint operation, however the value appears to be scaled by a huge amount. To demonstrate, here is the result of painting at the lowest possible target strength (.0625) vs about half strength (.625):
Brush size is 100 for both, and I’m using default patch settings. It seems that the patch resolution does indeed impact the paint as well, which I’m assuming is normal behavior. Here’s what happens when I half the patch resolution and try the same experiment:
Now it seems like this shouldn’t be a problem at first glance. If target strength is just getting multiplied by some weird value then I can just divide my paint target strength by the same value right? But that’s no longer possible. In 2019.3 the target strength slider only works in steps, as mentioned above. .0625 is the absolute lowest it will go, even if you type into the slider field. That’s a huge issue because it means we have lost granularity and precision that came with 2019.2. I have no clue why the target strength “multiplier” value changed in the first place.
I realize I probably should’ve made a new thread for this, but I thought it was part of Terrain Tools so it would be a specific workflow problem that I could solve immediately. Sadly, that’s not the case. I will still document it here and see about starting a separate discussion for this bug. Also sadly, I’ll have to spend some time submitting a bug report which will halt development yet again. I will keep testing and providing updates as I try to get this issue fixed.
I already did and got the automated email reply. The case number is 1227935. I will update here if I discover anything new or if they list an issue tracker for it.
Quick update in case anyone runs across the same problem: Thanks to the direction of another user, I’ve managed to recreate the entire Terrain Detail tool using the Experimental Terrain API which exists in base Unity 2019.3. This replacement tool has a fully unlocked target strength value, allowing me to bypass the interval lock which exists in the current version. I’ve posted the code on this thread in case anyone wants it. After that headache, I’m finally able to resume painting at my desired densities as explained above with the detail mesh method.
