Realistic moving grass

Help and Feedback Scripting Support
#1

So while gathering information from a new project I was going to try work on, I kind of came to a dead end. I was thinking, what would make a map look much better? Grass. But there is a problem to that on Roblox.

  1. What would be better? decal, part, mesh, etc.
  2. How would you place down a lot of grass without making all of the game lag just from the grass.

I was thinking of trying to do something like this: https://gyazo.com/b4c2e930b829e1d0c901c481f8190bd8

How would you guys do something like that, that looks good, (so not just. 3 decals slapped together), and moves. (to be honest, I don’t even care if the grass moves, just looking for a good way to make grass that I can put down a lot of on a big map and it won’t lag.)

And last but not least, why are other games (not on Roblox) able to place down a lot of detail that we normally can’t in Roblox? for example, again grass. Like the Gyazo video I posted, how are other games able to do stuff like that with not much lag? Is it because their base engine is more powerful? Is it because the computers that run the games are stronger?

If you took the time to read that and answer, thank you very much. (also first post so sorry if I did something wrong, as in wrong tags, category, etc.)

10 Likes
How do i make my bush wave/
#2

For the grass with out lag, I suggest using This plugin for the grass. (made by XAXA) it’s very useful to reduce lag, for realistic grass moving, in sorry but I can’t help you there.

1 Like
#3

How exactly does the plugin reduce lag? It seems to me that all the plugin does is place models down like a paint brush.

#4

You can increase the size of the grass brush, and basically there would be only a few pecies of grass, which would reduce lag because, you would have to only paint about 4 times for it to cover the baseplate, instead of duplicating a model, all over the place, the plugin reduces the grass to only a few. It’s also helpful time wise :wink:

1 Like
#5

The way I would tackle this is to use beam objects - you basically need two attachments and a beam object for each blade of grass, or for every group of grass. You could then write a client-ran script that moves the top attachment around in a windy-like fashion. It’s something I haven’t tried yet myself, but it seems to be the only effective way to achieve this effect in theory, unless you want to use meshes or parts.

And the reason why other games are able to do grass so much effectively most of the time is because they’re strictly using sprites, unlike Roblox where you have to place down a ton of parts or mesh parts that quickly eats up the triangle count. Of course, you could try the beam method, as it’s the closest thing we’ll probably ever get to a true sprite system.

1 Like
#6

I don’t want to start anything, but you could reduce the amount of grass by deleting some. You made it sound like the plugin had a magical way to reduce lag.

#7

Yes very magical.
It’s fine if we don’t share the same opinion about it, but if you don’t want to use it to reduce lag, you can use it to save time!

1 Like
#8

I don’t build much, but if I did the plugin would be a life saver!

1 Like
#10

Recently, @Maximum_ADHD posted an uncopylocked version of his 3D grass project in the WAYWOC 2019. Skimming through the post, it uses particle emitters on attachments.

You can either use the local script provided in the place, or, for the sake of learning, reverse engineer your own solution from it.

6 Likes
#11

@EchoZenkai did something like this and It’s actually extremely impressive! (In my opinion)
https://twitter.com/LordZenkai/status/1075132465906360320

2 Likes
#12

I have read a book (it’s on the web if you want to read about it) about important programming patterns, especially in game design, and I think I know why Roblox is not able to create things like moving grass, mainly because it’s too much data being loaded individually.
The ability to load tons of individual things onto memory, each with individually loaded textures and such, can lag the game a ton, even if it is the same TextureId every time it is used. This is the place where the flyweight comes into play in most Triple-A games. The idea is that the data from each object is separated into two states:

  • its intrinsic state, the data between the many instances that are similar,
    – in this thread, it’s the TextureId
  • and its extrinsic state, which is the data that makes them different from each other.
    – this could be the timing of the wind blowing through them

The renderer then uses the same data from it’s intrinsic state and loads it into every decal, and loads its extrinsic state individually for each decal of grass.
Apparently, the idea behind this method is to reduce the amount of data that needs travel to the GPU so that it can use this data faster.

I don’t think there is a technique in Lua that utilizes the same exact data to load Instances in roblox, only the ability to spread and copy the data into them, which is not what this design pattern was made to do.

It’s like, say you had a table with a thousand different Vector3 positions in workspace, and let’s call this table partPositions. You want to generate a part for each position in the table, and each part is exactly the same except for the position.

Usually, you would do this:

for i = 1, 1000 do
    local part = Instance.new("Part")
    part.Position = partPositions[i]
end

What the flyweight pattern demands for, however, is this:

local part = Instance.new("Part")
part.Position = partPositions[1], partPositions[2], partPositions[3],...

or to make it simpler:

part.Position = partPositions -- the table itself

Essentially, the part is rendered in every spot from the table, all at the exact same time. Surprisingly, this probably wouldn’t slow down your PC too much because it’s just one part in a thousand positions, instead of a thousand parts each manifesting one position.
I would understand why this isn’t included in Roblox, because it’s really complex and it would be hard to create an api for, not to mention that it would make rendering parts very inflexible and confusing, and how you would you go about creating a physics solver from this?

However, this could probably be done with decals, since you would be creating just one texture in many different positions (and orientations), and you would only have to worry about rendering it since it does not interact with physics or anything else.

I could be very, very wrong, and Roblox engineers are well aware of the power this design pattern has, and are actively using it in the engine, or at least have a reason not to use it. I don’t really know anything behind the scenes, but this is my opinion.

4 Likes
#13

This was a very interesting read. With the method you included tho, using decals and such. Would that not remove the ability for grass to interact with physics?

Grass in most game engines is simply a billboard texture… While there are thousands of ways to render grass. I do believe optimization is the issue here. And tbh the flyweight pattern seems to be the best fit for Roblox. Either that or entirely optimizing instances so that all grass can be batched into one draw call. Not entirely sure that would help though. I planned on trying a “Instanced” method hoping to rely on that very functionality of batching the same mesh, with the same material into one draw call.

1 Like
#14

In theory, the decal Instance itself would be the state that is copied between all other grass decals, while the physics would need to be handled by something else, like either the actual part its parented to or a simple script.
Do you think that would be plausible or even beneficial to let the decal’s parent deal with physics, because I wouldn’t really know the kind of workflow the engine has to go through to calculate all this, or etc.

#15

Usually grass is just an animation. While it is a billboard… it’s literally just an animation. And only the grass that’s near you would need to interact with physics… so its quite optimized already.

But with Roblox it’s all or nothing. I’d say the first thing to do would be to create some very minimal strand of grass… That way it can take advantage of draw call batching. And then to run an animation on it… maybe keep track of the strands in some data structure… All the while have another script check a region 3 and interact with that the strands within a region. If you set the grass to non collidable, and anchored that should ease up on some of the performance issues. As well as add all grass outside of a “Draw Distance” to Debris to ensure more optimizations. This is all theoretical and I’d like to try it. Do you see any possible issues?

1 Like
#16

Wow, except a few minor flaws, this is amazing! Thank you so much for your help. This will make the grass factor of the map so much more easy. And for those few flaws, I will just find ways around them.

#17

I’d recommend to use a grass mesh that does not have a high number of vertices/faces. For the movement, the closest you could get would be to use animations. It would be very time consuming, but it’d be worth it in the end.

#18

Ripull has actually attempted this that works, he uses LOD for his grass.

Also, if you keep scrolling down in the comments. He explains that the grass is clumped together into a group as a mesh for performance reasons which might give you a better hint. Disclaimer, he also says that making it move will make it look weird since its in a clump… You could tween it to squish down instead as he explains though.

Hopefully that helps. :stuck_out_tongue: Good luck!

5 Likes