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.
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.
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 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 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.
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.
(Or visualize it?)
