Hi everyone, happy August 15! On this day in 1914, the very first cargo ship passed through the just-completed Panama Canal.
THANK YOU
I was always so bothered by the fact that most games dont bother to do this, even though they support first person camera, and some even have trails or auras.
Does this also address the limit to how many parts can actually be exported? From quick testing, it seems to preload and generate the geometry for all parts (around 144k) however it will only save 36k of them.
No. The goal here wasn’t to overhaul the underlying export logic, just to have it not hang Studio (and the perf improvement came mostly for free as a result of the async code being trivial to add some parallelism to)
TL;DR: The limit comes from the fact that a lot of users get out-of-memory crashes without it, it’s not trivial to raise without changing the architecture a lot more.
Right, but if thats the case then why also preload and generate the geometry for all provided parts? Would it not make sense to by default only preload that small sub section of parts?
Because different parts have wildly different amounts of geometry. One MeshPart could be a simple box or half the level geometry, until you have preloaded them you don’t know which is which. Preloading them in and of itself doesn’t create a memory pressure problem because Roblox mesh format (binary data) is much denser than the obj mesh format (textual representation).
It could be made to work but it would require a pipelined solution where the data is streamed out to the disk piece by piece instead of the entire obj file being generated at once and then written like it is right now.
Fair enough i guess. Any change for some sort of setting that would let us change how many parts we could export at once? Dosent have to come with an entirely new system or whatever, just something so i could use to get around the limitations since i got the resources for that.
Yes if there’s enough pressure from creators, but generally there’s a lot of resistance to adding “random hack” settings like that lest Studio end up with an incomprehensible jumble of settings that arguably shouldn’t be needed in the first place.
I’m guessing i have no hope of even getting an FFlag for that either then, unfortunate.
What does this mean? Won’t this break game visuals?
Is this release some type of bug fix? Aren’t all changes are from old releases?
Sometimes the initial fix doesn’t get the job done. In that case two releases contain code to fix the same issue, and the release notes may or may not end up containing a duplicate entry depending how things were handled.
This release note does have quite a few of those though, more than normal.
This also adds the LocalTransparencyModifier property for these instances in case anyone was curious about the implementation
After this update in a place file with a large map, we are experiencing massive lag when dragging parts around. I think it may be due to this:
Here is a gif of the lag when trying to drag a part:
https://gyazo.com/b38c0a221ea3c3db1cca16f56f8de761.mp4
The hiding for first person particle emitters inside a character doesn’t mention the sparkles object. Is that planned to be hidden as well because it’s also a particle which should count.
Are you sure you don’t just have a large grid snap value set? (can’t tell exactly what I’m seeing in the gif). The change in question hasn’t been enabled yet and I’m not aware of any (intentional) changes to the draggers being enabled this week.