It could, but if he was to be doing it on the server, it would be a lot of things that the server would need to handle, assuming the trees would have scripts inside of them for simulating movement.
All 10 tree models that are in game are static with no special changes apart from colors on server-startup.
2 Likes
This is exactly what I was going to tell you, just differently.
Hereās what I was thinking. Your server has the folder of the trees in ServerStorage. You require and init the module on the server, where your init function turns your treesā meshes into tables. (storing the information of the trunks and leaves and the necessary info) In this instance, itāll also connect to players joining and sends a remote with that table for the client. (Because ModuleScripts donāt share the same info in different contexts) When it finishes, just destroy the folder.
On the client, you would load the trees from there. This is good since now you could set up some like graphics settings in case the trees might be too much for the client. The coloring would also be handled by the client via remotes, the server just telling the clients to render āthisā tree type with āthisā data and whatnot. Hopefully it makes sense.
3 Likes
Makes complete sense. Iāll try this out and let you know how it goes.
Since the trees are models with 2 parts (trunk and leaves), how would I go about positioning?
Well, within the table, also store their CFrame coordinate within the table. I could give an example of what I mean. (Had to do this for a few games to save data)
Should I store the tree models themselves or the actual parts themselves? Since each model has 2 MeshParts, trunk and leaves, would it be easier to do it that way?
In terms of obtaining the CFrame, do you mean of the model?
1 Like
You should be storing information of the parts themselves. It would be better to do it that way since they have the meshes in them already, whilst the model doesnāt. The CFrame being the individual partās CFrames.
1 Like
1 Like
Sweet, exactly what we were talking about before. This also just saves performance and render time on the server anyway, so itās good practice to do this, especially if the objects are being mass-duplicated for just visual showcase. Hope everything goes well on your project, by the way! (Would love to see some progress of it if possible)
In case others might be trying to find a similar problem, it would be cool to mark the most helpful post as the solution. Not asking to mark my post, but just to help others who might be seeking the same answer. ^^
1 Like
Yeah no worries, I got you. Thank you for the help!
Knowing this can save performance and render time on the server, this could also be used for filler/background buildings too, or any static building really
1 Like
How would I go about streaming them? My game uses StreamingEnabled, and client sided objects donāt get streamed in/out, itās persistent.
Also this is strangeā¦ the memory remains the same (actually increased, but I think itās an outlier)
Before:
After:
1 Like
Hmm, is there any reason as to why theyāre persistent and not atomic or anything? Iām reading that the use of too many persistent models could actually have a negative impact than anything.
Persistent models are intended for very rare circumstances, such as when a small number of parts must always be present on clients for LocalScript use. ā¦ Persistent models are not intended to circumvent streaming, and overuse may negatively impact performance.
My next reply will be in a message though, so we donāt have to keep bumping this topic, haha.
1 Like
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.