“It’s still technically possible to do this, but I said that to illustrate a point. I didn’t suggest that they should actually do this.”
It actually isn’t because quite a few of the meshes “cheat”, and aren’t actually made up of fully “water-tight” surfaces. You’ll see that if you run some of them through a mesh → parts converter.
When the CSG physics came out it pretty much broke the game that I’ve been working on for 100+ hours over the past two or three months.
Previously, the boxy collisions were fine. My CSG tanks (with quite a few unions) worked great online and when I did testing online with like 20 people there was no weird behavior.
Yesterday I did online testing with a lot of people for the first time since the new collisions came out. Even with as few as five players, the models begin to behave weird (ie: move smoothly but rotate as if there was lag). I don’t know if the problem is caused by the new collisions or just a faulty Roblox update. (The unions are all non-collidable by the way.) It sucks that a game that I’ve spent so much time on cannot be finished.
Edit: It’s not the unions’ fault that I’m having problems even though they do make the game run slower.
Another example is the raycasting. You can’t disable that by turning CanCollide off. I have a game that checks if you’re mousing over an interact-able object on Stepped with mouse.Target, and it’s going to have to do complex calculations if there’s lots of unions around that people are mousing over – same with firing a weapon.
I would also like this feature. Most of the stuff I’ve made in CSG is just for decoration and doesn’t need realistic physical colliding, that will just slow my game down. And making the part CanCollide = false and welding a fake handle part is almost as bad as not using CSG.
Sorry to bump this thread
Would disabling CSG physics also speed up overall game play? I mean it must be more intense to get the physics data of each little tiny bit instead of using a plain box physics (which is more easier anyway)
Currently thinking about using CSG but really don’t want the physics stuck on 
[quote] Sorry to bump this thread
Would disabling CSG physics also speed up overall game play? I mean it must be more intense to get the physics data of each little tiny bit instead of using a plain box physics (which is more easier anyway)
Currently thinking about using CSG but really don’t want the physics stuck on [/quote]
The more complex a collision hull is, the longer it takes to perform collision checks on it. Those collision checks are performed on every part even if CanCollide is off.
What’s worse is that these collision checks are even performed between different CSG parts, so you’re checking complex hull against complex hull. This might be doable for a few parts, but as soon as you start going towards a few dozen parts, then you’re bound to notice the physics engine slowing down.
Primitive collision hulls such as boxes and spheres are extremely easy to calculate and are thus very fast. ‘Polygon’ hulls like that of CSG are very slow.
The original reason many of us used CSG to begin with was to reduce the load on the physics engine. As it stands, though, CSG parts actually increase that load dramatically. It’s unfortunate that such a great feature has to be ruined because a basic feature is being stubbornly refused.
Which is why I wish CSG’s could be saved as ID’s, and allow those same ID’s to be used in specialmeshes
So that we can just plop in a specialmesh into a normal box block, scale it to whatever we like, and we eliminate the slow physics performance while being able to make our games look pretty
I don’t know anyone using CSG for actual terrain/ legitimately trusted collidable surfaces like vehicles, houses, or whatever. (Unless it’s just a dumpster or a static rock)
It’s just as much work using parts, and with parts you kind of expect them to work as you’d like.
And as Volc stated, we wanted CSG to reduce part count on things like guns and small detail so that it wouldn’t be rendering physics on every collision
Except we didn’t get that, and we’re back at square 1, with compatibility issues added on top (why u no formfactor!!!)
Can’t you add those CSG parts to the Mouse.TargetFilter model locally?
Can’t you add those CSG parts to the Mouse.TargetFilter model locally?[/quote]
So I have to manually add all of the unions in my game to a single model? TargetFilter isn’t a table – it’s an instance, so that means I would have to ditch organization and add them all to a single model/folder in order for them all to be used in TargetFilter. There’s no reason I should have to completely unorganize my game just so I don’t have to deal with complex geometry calculations.
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.