Hmm… I would mention that I recall the physics data for CSG parts are still required to load the moment the player joins the game and are not streamed like the mesh data are.
Forcing players to download all that extra data even though 99%~ of my CSG unions are found in my gun models with no cancollide on seems to be a rather waste of data and adds on to unnecessary loading join times.
Sorry to bump this up, was there any update on this? I saw Khanovich reply but was un-sure. There have been a lot of threads asking for an option to disable CSG physics, it feels like this has been pushed aside and forgotten about sadly. [size=1] I also really need box physics right now 
[/size]
[quote] CanCollide=false
Giving arbitrary box collisions for arbitrary objects was a bad idea to begin with. Why should it default into box physics? You can still customize your CSG object collisions just as much as you could before if you set “CanCollide=false” and weld a custom object to it. [/quote]
But what about .Touched and .TouchEnded and other similar events?
Even with CanCollide turned off, we’ll still need the heavy work of calculating whether or not two baseparts collides.
(I must admit, I have yet to get a working demo place, though when I did crash into other players with uncancollided CSG parts on, it lagged, as if I was climbing a model of 1000 tiny parts or more, on the size of a bush or coffee machine in ROBLOX)
I even thought of making a thread for this sole reason, though I’ll just put it here:
[quote=“As8D”]Hi there!
I have as of recently noticed that even while having an UnionOperation’s CanCollide property set to false will still produce an intensive work for the physics part of ROBLOX - or something I don’t know - since I only experienced that when colliding two or more players’ characters together, while having unanchored unionoperations would give some nasty results. That, and trying to collide with other objects with dynamically moving unionoperations.
[size=5]What is my problem[/size]
Currently, I have a game where characters are given outfit composed by CSG unions and parts. These are neither cancollided nor anchored, but are welded to the respective body limbs.
[size=5]Thesis about what’s going on[/size]
Even with CanCollide off, the clients uses a long time to process the movement and physics interactions with their characters and the world (or other characters). With only 8 UnionOperations, where a couple of 2-4 Parts are included, the result is significant, and might end up catastrophic for what I’m doing.
Discussing on the Unofficial RBXDev Skype Lounge, it was noted that the .Touched event of UnionOperations does not care about whether or not CanCollide is ticked off, which might result in extensive processing power to calculate whether or not two parts have collided.
[size=5]What I suggest[/size]
The reason I put this thread in [strike]Client Features[/strike] [sup](Eh, now it’s a reply to a thread)[/sup], is that something needs to be done in order to let us have smooth gameplay while allowing advanced shapes in dynamic, if those are not meant to be used in extensive calculations.
My proposal hereby is to let us toggle whether or not the .Touched event and other similar functionality using the collisionbox or visual respresentation of the UnionOperation to work properly.
Simply put; Add a toggle in the properties of an UnionOperation, .SimpleHitbox (or another name), which is per default toggled off, and will greatly reduce the processing power on that particular object if toggled on. B) [/quote]
Edit: here’s a… not sure if it’s a demo place. The actual slowness caused by CSG unions colliding happened inside a closed-testing place. The content in this demo place should be much of the same as from the closed testing place, without using too much from it.
http://www.roblox.com/CSG-physics-place?id=191059107
I’m not sure Khanovich understands the severity of the problem. I assume at this point the issue is that he just hasn’t seen any issue so far and thinks the people complaining are just the super optimizers because I’m also assuming he’s professional enough to not put something like this off because he spent so much time working on the fancy CSG physics. AS8D and Resync, maybe he’d change his mind if you linked your stuff (AS8D and his armor, and you with whatever you’re having issues with) so that he knew it was a real problem. I’m still working on the programming of my place so I don’t have all of the fancy building done that would cause slower raycasting, but I’ll certainly post that when I’m done.
“I’m still working on the programming of my place so I don’t have all of the fancy building done that would cause slower raycasting, but I’ll certainly post that when I’m done.”
Raycasting would not be significantly affected by having more complex geometry anyways, the cost would be a higher cost inserting into the spacial hash when the complex objects were moving if anything, not a cost on the raycast end.
[quote] “I’m still working on the programming of my place so I don’t have all of the fancy building done that would cause slower raycasting, but I’ll certainly post that when I’m done.”
Raycasting would not be significantly affected by having more complex geometry anyways, the cost would be a higher cost inserting into the spacial hash when the complex objects were moving if anything, not a cost on the raycast end. [/quote]
Oh, I should have clarified. Not bullet raycasting. I have an interaction system (E button in Skyrim) that updates on RenderStepped, detects what your mouse is over, and looks through a table of names to see if there’s an action available for the selected object. The third isn’t really an issue, but I assume mouse.Target uses raycasting and raycasting on RenderStepped through lots of complicated CSG geometry would not be fun.
[quote] “I’m still working on the programming of my place so I don’t have all of the fancy building done that would cause slower raycasting, but I’ll certainly post that when I’m done.”
Raycasting would not be significantly affected by having more complex geometry anyways, the cost would be a higher cost inserting into the spacial hash when the complex objects were moving if anything, not a cost on the raycast end. [/quote]
Oh, I should have clarified. Not bullet raycasting. I have an interaction system (E button in Skyrim) that updates on RenderStepped, detects what your mouse is over, and looks through a table of names to see if there’s an action available for the selected object. The third isn’t really an issue, but I assume mouse.Target uses raycasting and raycasting on RenderStepped through lots of complicated CSG geometry would not be fun.[/quote]
Raycasting is faster than you think.
It’s also slower than you think.
game:service("RunService").RenderStepped:connect(function()
print(game.Players.LocalPlayer:GetMouse().Target)
end)While over the BasePlate:
While over a union of mine:
That’s a 20x decrease in performance. I’m running a really good rig too, so I’d hate to imagine what people with lower specs + the other scripts running in the background would experience.
Yeah, raycasting is pretty cheap in the scheme of things. A full raycast renderer will grind everything to a halt, but even a few dozen raycasts per frame isn’t going to harm anything.
A 20x drop in performance on a really good machine is probably worse on lower-end machines, especially with all of the other local scripts running.
Humor me. Try your test again, but simply assign the target to a local variable instead of printing it. My own tests are showing interesting results.
Printing to the output slows down scripts big time as it it as to get the tostring function, call it on each output, and then output them followed by a “\t” and then at the end of a string a “\n”