Release Notes for 638

Hi everyone, happy August 15! On this day in 1914, the very first cargo ship passed through the just-completed Panama Canal.

62 Likes


See NOW we’re talking.

25 Likes


relevant post from last week before anyone gets excited:

27 Likes


THANK YOU :pray:

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.

33 Likes

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.

7 Likes

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.

12 Likes

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?

7 Likes

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.

9 Likes

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.

5 Likes

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.

7 Likes

I’m guessing i have no hope of even getting an FFlag for that either then, unfortunate.

6 Likes

What does this mean? Won’t this break game visuals?

6 Likes

It will fix issues like this when you’re in first person

11 Likes

Is this release some type of bug fix? Aren’t all changes are from old releases?

7 Likes

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.

6 Likes

This also adds the LocalTransparencyModifier property for these instances in case anyone was curious about the implementation

27 Likes

okay nice, finally we got this!

7 Likes

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

7 Likes

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.

5 Likes

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.

5 Likes