CSGs have been rendered nearly useless recently as half of the calculations are incorrect, and if you undo an incorrect calculation, you will most likely have your union made invisible.
We wanted a smaller filesize but this isn’t worth it. Can’t the “undo data” from the union be removed (NOT from studio) in order to reduce the filesize? I really want to use CSG in my games but it’s beyond unusable.
What exactly is the benefit to making it impossible to keep CSG data?
I’ve also found that often undoing will make a union go invisible. 50% of the time.
Edit: wow I didn’t realize I typed that much. Sorry for the word wall in advance.
All three portions of CSG operations are replicated to the client for their own reasons. I’ll also go into depth as to what each of them are for those who aren’t knowledgeable about the three types.
ChildData - This contains the undo history of the union. The reason it is replicated to the client, according to Adamintygum, is because in the future we may be able to compute PartOperations from the client while the game is running. This is also used to determine the union’s AssetId when it is uploaded to the site.
PhysicsData - This contains the data necessary to calculate how players should walk over/collide with the union, how other parts should collide with the union, and info for raycasting. This obviously has to be replicated to the client since the client is what controls character/part collisions and sometimes does raycasting.
MeshData - The other two aren’t exactly necessary some of the time, but this is necessary all of the time. This stores what the union looks like. The client needs to be able to render the union, so this obviously has to be replicated as well.
I believe Khanovich is the only person working on CSG now because Adamintygum no longer has his OBC nor admin badge, leading me to believe that he isn’t with us any longer. So with only one person working on CSG now, I don’t think CSG will be progressing at a fast pace anymore. Action will likely never take place on your/our pleas.
Regardless of whether it will ever change though, CSG certainly isn’t perfect. ChildData isn’t really even something we need in most cases. I don’t know how they attempted to compress it that would cause it to give broken unions when you tried to take apart a union, but I highly agree that I would prefer full functionality over small file sizes. Functionality should not be broken in attempt to compress the file size. Had we all known that taking apart unions would be destroyed for anything greater than a complex-ish, tier-5 union, I’d imagine a lot less people would have been pushing for smaller file sizes. The only reason I, and I’m sure generally everyone else, pushed for lower file sizes was because I never imagined taking apart unions would be broken in the process.
One thing to note though is the reason why ChildData is replicated to the client in the first place. Not all unions need to be modified through the client. Instead of just replicating the ChildData of every single union in the game, I’d imagine an optimal solution would be to only replicate the ChildData when the client tried to modify a union. It would be streamed in and then the operation would be completed when the ChildData was done downloading to the client. If a developer wished to preload in that ChildData they would, optimally, be able to just call :Union(part) with no other parts (assuming that’s what it’s called). The two birds with one stone of that being that until client union modification is possible, ChildData will not be replicated, and the second being that ChildData will only be replicated if needed. Then we can all shut up about compiling unions finally because the clients don’t have do download all of that data.
MeshData and PhysicsData are a touchy point. The whole reason unions are so dodgy right now is because of the PhysicsData – not because of the PhysicsData itself but because everything else has to be compatible with the PhysicsData. I can’t find the thread, but when I was blabbering on about why ROBLOX should have used an existing file format for CSG instead of making their own so there wouldn’t be all of these errors, one of the admins told me something along the lines that the reason MeshData doesn’t use a tried and tested format that already exists is because it has to work with PhysicsData. The reason we don’t have physics for meshes is because it’s pretty much impossible to effectively calculate physics for .obj,.mesh,etc files – MeshData has to work with it, so they had to create their own file format that worked with it. Brain may have misremembered some of those details, but pretty sure that’s the gist of it.
Not all unions need PhysicsData, and it’d certainly cut back on file size without it for those types of unions, but despite quite a number of people wishing to have the ability to disable CSG physics for things that would never need physics, Khanovich, in his infinite wisdom, has decided that isn’t an important enough reason for CSG physics to be toggleable, despite promising that would be a thing before it was implemented.
But yeah – those are pretty much all of the reasons CSG is having issues.
Really nice post, thanks.
PhysicsData is something I wasn’t aware of. The part where the childdata determines the assetid…eh…wouldn’t it be simpler to just assign a new id? Similar to when we upload assets. Un-unioning is a bit of a useless feature. I’d only use it in a scenario when I could also push CTRL-Z (except that makes them go invisible)
Hopefully this gets fixed soon! I actually managed to get a nice CSG dome house built last night, so not all hope is lost.
ChildData is used to determine uniqueness, not the actual assetID number. The idea is that unions with the same children should have the same ID.
ChildData is used to determine uniqueness, not the actual assetID number. The idea is that unions with the same children should have the same ID.[/quote]
Worded differently, it’s so that if you have 50 trashcan unions, instead of a different CSG asset for each, since they all have the same ChildData, they all get the same ID and you only load one CSG asset – similar to meshes.
“Khanovich, in his infinite wisdom, has decided that isn’t an important enough reason for CSG physics to be toggleable”
Keep in mind that he isn’t necessarily the one who made that decision. The general sentiment of the Roblox developers is to have a “physically accurate” world: See the long time resistance to having officially supported mechanisms for local parts, and lack of clear local sound mechanisms, etc.
[quote] “Khanovich, in his infinite wisdom, has decided that isn’t an important enough reason for CSG physics to be toggleable”
Keep in mind that he isn’t necessarily the one who made that decision. The general sentiment of the Roblox developers is to have a “physically accurate” world: See the long time resistance to having officially supported mechanisms for local parts, and lack of clear local sound mechanisms, etc. [/quote]
Not on that specific thread, but I recall threads in the past where he was strictly against toggleable physics – against it to the point that someone who wanted to provide that option but couldn’t due to management wouldn’t reach. And regardless of how physically accurate they want the virtual world to be, performance always trumps that.
Back when I made a gun that consisted of 100 parts (before unions), if people walked into each other, both of their computers would die. All of the parts were noncollidable. That’s a 100 parts with simple collisions. If I make a suit of space armor consisting of 20 parts (4 per limb – hardly anything) and the player has three weapons worn on their character, 3 parts each (again, hardly anything): a sword, a primary assault rifle, and a pistol, and then decides to walk into one other player BAM instant 10 fps as ROBLOX continually calculates the collisions (which are much harder to calculate than normal parts) between all of those unions due to humanoids.
Because ROBLOX games tend to involve walking around the world, humanoid .Touched detections means that every union, regardless of if it is collidable or not, will calculate collisions when the player walks into it. Toggleable box physics please~