I really wish to create that kind of nature that’s got realism whilst not being too memory-heavy.
So I’ve tried using the decal method, where the trunk is a mesh and the leaves are decals.
While it’s got something, it’s very complex to place the leaves properly. To me it feels nothing like an actual tree unless you’ve got perfect spots to place the leaves.
So my second idea was having everything on the tree a mesh. (Trunk + leaves)
This looks REALLY awesome. But it’s only good for a small amount of those trees. If it were a forest like that, the players would need a really high-end PC to run it without lag. Which is such a shame!
Does anybody know a way somewhere inbetween? Or maybe make the high quality trees a possibility without being too laggy?
You could do the leaves as one low-poly mesh with all UVs over the same spot and put a transparent leaf texture on that. If you use a SpecialMesh instead of a meshpart, you can even place the leaf texture as a decal and make the part itself transparent and it’ll be less glitchy than transparency with decals already is.
Since Roblox now loads unique meshes as a single asset, if you figured out a way to make the trees box collision, cancollide false, and a transparent collision part underlay, you’d be surprised how far you’d go in making a forest.
That is, if you’re only using a limited number of different meshes.
Could you explain that a bit more indepth, please? (Or visualize it?)
I’ll try to help visualize it if needed once I’m on a computer. Basically, what I think they mean is for you to do this:
Set the collision of the tree mesh to box collision
Turn CanCollide off on the tree mesh, so players walk through it
Make an invisible cylinder block and drag it inside the tree
Group the tree and cylinder into a model
Use this model for the trees in the forest
The cylinder is there to make sure players collide with part of the tree. By changing the tree’s collision to box collision you’ll have a lot less complex geometry for the physics to handle, which should improve the conditions for lower end devices.
Awesome thanks!! I think I got it now
How could I handle the shadows properly @Extuls? Because it doesn’t cast a shadow now. Which is fine if there’s no other way, but I’d love to know haha.
I think it needs physics of the mesh to cast shadows. This must be a side effect of using box collisions.
I’m not too experienced in using meshes so if there’s a way hopefully someone else can help figure it out.
It won’t cast shadows if it’s a specialmesh, it does with regular meshes though.
Also, instancing doesn’t work with specialmeshes yet, so it’d be better to use regular meshes if you plan to use a bunch of trees (to reduce lag)
They’re all MeshParts. So that shouldn’t be a problem, correct?
Ah, I thought it was a specialmesh… But in that case, for instancing, it shouldn’t be a problem
I don’t understand why it isn’t casting shadows though (since it’s a meshpart)…
When I changed the Collission setting from ‘Default’ to ‘Box’ it vanished. I’m sure it’s related to that, but I’m not sure why lol.
Ah that makes more sense, why not keep it on ‘default’ with cancollide disabled then?
You can always make a test place with a bunch of trees with those settings to see at what point they start lagging for you (with instancing)
I assume that the collission is the reason why it’s laggy. Like @Extuls mentioned:
The reason I think why CanCollide is disabled, is to make sure people don’t walk against a literal box of emptyness around the trees. Can’t say that for sure though.
I don’t think having cancollide disabled with default collision calculates physics though (I’m not sure about this)
I don’t know a lot about this either. I was just explaining what someone above said.
However, if casting shadows requires the physics, then even with CanCollide off and default collisions it would still be doing something more. But again, anyone with more knowledge is free to jump in and correct anything, of course.
Even with collision turned off, the engine still needs to calculate physics. One example is most likely because the lighting uses the physical properties of a mesh to cast a shadow.
But even if a MeshPart’s collision is set to false, it still needs to calculate the physics of a shape because of the “Touched” event. Your character can still interact with Parts that don’t have collision, therefor the engine needs to calculate the physics in order to give you accurate results if you happen to use a Touched event on a “Default” CollisionFideltiy MeshPart.
I’ve spent a lot of time making tree generators, it’s a balance between quantity and quality. Here’s something I made 4 years ago:
If you implement a performant level-of-detail system they can be as detailed as you’d like though. Here’s what Shard Seekers uses:
The problem is that you can’t see the trees in water reflections or through glass, and sun-rays go right through them.
Edit: Fixed dead gyazo links
Yep, LOD seems to be the best case here. Let users see those juicy trees up close and further away ones be more like bilboards
But how? As far as I know, meshes can’t be deformed. So making them lower in detail in-game wouldn’t be possible.
- Switch out the models entirely as needed.
- Toggle their collision + transparency as needed
As long as you switch out models say via a queue and not all at once, should be relatively lag-free to switch between the two. Actual games outside of ROBLOX don’t do LOD via mesh deformation but switch between created/generated meshes as well. So idk where mesh deformation was suppose to play a part.