ROBLOX Has Issues With Large Parts

I’ve noticed that large parts seem to drive ROBLOX crazy. For example, I currently have a place that uses diamond square terrain. My friend made a map in it (1600) parts but I could not insert it as a model because ROBLOX would hang for over 30 minutes trying to insert it. We did a test, and he made the same map use 6400 parts and it took 30s to load.

We finally got the map (a 3200 part version) into the place by moving everything over to the rbxl file that has the map. The map is only 3200 parts but the rbxl file takes approximately 1 minute to load. When I open one of my other places that has 20k parts (none large) the place opens in 2s.

There definitely seems to be a huge performance hit with large parts. They also often tend to hang your studio when you try dragging or moving them. The sad part is, when injecting large models, ROBLOX only uses 5% of my CPU power :frowning:

[size=2]This is not a specs issue as im sure most of you know. I’m running an i7 3770k at 3.9GHz and have 16GB of ram. I also happen to be running this file off of an SSD. It’s definitely a ROBLOX performance issue.[/size]

Are you using an XML-format place file or a binary format place file?

The XML-format place file takes a lot longer ot read and load, so that may be why.

[quote] Are you using an XML-format place file or a binary format place file?

The XML-format place file takes a lot longer ot read and load, so that may be why. [/quote]

Is there a way to change from Binary to XML?

Rotating a 2000 stud sphere is pretty choppy with the rotate tool, rotating it with a script like a planet will pretty much crash roblox. Big parts are evil.

Edit: I just had the great idea to use sphere meshes instead, works flawlessly, rotates without lag. Must be physics on that scale causing issues.

[quote] Are you using an XML-format place file or a binary format place file?

The XML-format place file takes a lot longer to read and load, so that may be why. [/quote]

Is there a way to change from Binary to XML?[/quote]

You mean XML to binary? Just make sure that when you save a place/model, it does not say “XML” in it.

Can confirm Large Parts Load very slowly. A friend of mine made a Track for a racing game which only consists of 267 parts, with a lot of Giant Parts, however, it takes around 1 minute to actually join a server that has the Track on it. On the other hand I made a Track that consisted of 2k Plus Parts and it only takes 5 seconds to join a Server with the Track on it.

It seems like Stretched parts are fine (ex. 2000x15x20), but if you get a Large part like 2000x900x1300 it causes long loading times.

[quote] Are you using an XML-format place file or a binary format place file?

The XML-format place file takes a lot longer ot read and load, so that may be why. [/quote]

We tried both. All we could figure out was that the XML version was insanely larger in file size(as it should be).

should i be making baseplate thinner than default? or remove the basplate and using several smaller base pieces instead of one big baseplate?

I’m hoping that when they eventually release the 64-bit build for Studio there won’t be as much issues with large-scale objects as it’s able to handle more memory.

I don’t think a 64bit would help much, even if it did you’d still have 32bit clients playing your game.

Repro or it did not happen.

Related?

This is sort of related and has a repro

Related?[/quote]

Yes! Had this issue a few years ago myself. As for a repro, I can make one at some point today or tomorrow. I’ll upload a 10kx10k terrain and the version that uses more parts will load quicker than the version with less parts.

It’s lighting / dynamic shadows. Turn it off and try again. No lag.

Have you measured this? Do you have a repro? If so, where is it?

I’m tired of baseless speculations. Lighting/shadows can not freeze the system for 30 seconds unless you take one huge part and duplicate it 10k times to the same place.

CSG issue is unrelated if the scale there is indeed 10k. Unless the OP meant that his parts occupy 10k^3 volume.

The Apocalypse Rising issue could be related, yes. This is why I need a repro! Guesses about performance are usually wrong, especially for complicated systems like ROBLOX.

It’s possible that you’re hitting the same issue as AR. Or maybe you’re hitting a separate issue that is actually easy to fix (AR problem is not). Or maybe there is an easy workaround.

[quote] I’m tired of baseless speculations. [/quote]Please don’t begin acting like this. I find all too often that there are many genuine bugs that we can’t explain or reproduce and due to that it never gets resolved. I appreciate how difficult it can be to find a bug yourself, and how time consuming it is to repeatably ask somebody for that reproduction, but be more positive about it. You’re bettering everybody’s user experience if you listen and resolve a major bug.

There are some issues that can’t be reproduced, and the staff understand that we can’t reproduce them but are still very understanding and eager to figure out what the cause is and squash the bug as Khanovich did with the key combination bug (even though he ultimately couldn’t find out what was causing it), but there have been people that have posted “umg I can’t union this” and don’t even post a screenshot / repro file, and it’s really annoying when they somehow expect that ROBLOX can solve all of their issues without even seeing the issue in the first place. That is what zeuxcg is referring to. We have people on this thread claiming that “Oh x is causing it” without any hard evidence, and to a ROBLOX employee that’s the same as a non-developer on ROBLOX trying to report a bug to us and saying “Oh it lags. It’s because the guns I bet!”

If you can’t explain the bug - don’t try to explain the bug! That’s what we’re here for - we’ll try to gather as much info as possible using a combination of places that you have issues with, information from various stat panels we have, etc., etc.

It’s perfectly fine to say “some of my users report this problem. I have no idea what this can be. HELP!”.

In other words - more evidence, more examples, less scapulimancy. And we’ll all be better off.