So, the new CSG physics are cool and all, but they’re not always ideal. I’d like an option to switch back to the not-so-fancy box physics, especially for performance reasons when there’s a lot of CSG parts.
This was one of the things we were told WOULD be released when CSG physics came out, I can reassure a lot of us want it, and would appreciate it if you would put it together for us.
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] 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]
Because that increases the mass of the object, and anything that breaks joints (even by accident) will mess it up. It’s not a bad idea to use box collisions. I really don’t see why you must force fancy collisions on and give some silly work-around as a solution to the problems it causes.
This was a concern from the beginning and we’ve been told that this would be released along with CSG physics.
EDIT: If arbitrary collisions are such a bad idea, then why do cylinders still behave like a ball? That issue has been addressed a few times on here and yet no one seems to do anything about it.
That is kind of like asking “why do wedges have to collide like wedges”. I think we’re still keeping with the same philosophy as before when referring to objects colliding what they look like, and you as a user having the ability to customize it.
If you were to have any custom collision shapes then you would still have to deal with the break-joints problem regardless.
Cylinders can be fixed and will be once we stabilize some CSG physics things, I was no around when Cylinders were first implemented and cannot speak for that decision.
Then, while you’re at it, you can also make FileMeshes use a polygon collision hull - because hey, arbitrary collisions are a bad idea, right?
EDIT:
I don’t want a custom collision shape. I want a box. Boxes were around for a while and all was good.
In some situations, you need box physics. We was told there would be an option to turn/revert it back, why wasn’t it not implanted? 
Full support
[quote] In some situations, you need box physics. We was told there would be an option to turn/revert it back, why wasn’t it never implanted?
Full support [/quote]
When did they ever say that…? As far as I remember, they always told people to make things CanCollide false and weld a box to it if they wanted “box collisions”.
[strike]Could you point towards the thread where they said this?[/strike]
Edit:
This is as far as I can see them “promising” the feature, but it’s not even a promise.
I’m not sure at the moment if you will be able to turn the objects back into a simple physics primitive like a box, because it’s not how Roblox usually does it. I think for performance/usability reasons we will want to expose a toggle, but we will need some concrete test cases to know for sure.
They can’t do physics for meshes because the .mesh files aren’t set up for that like union data is.
“Just make it non-collidable and slap an invisible collision box over it”
Although this isn’t too much of an issue with anchored parts, if you’re working with unanchored parts, the more the not-so-merrier when you have to weld all of those together and then have to do extra physics calculations for those collision boxes because they’re unanchored.
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.
[quote] “Just make it non-collidable and slap an invisible collision box over it”
Although this isn’t too much of an issue with anchored parts, if you’re working with unanchored parts, the more the not-so-merrier when you have to weld all of those together and then have to do extra physics calculations for those collision boxes because they’re unanchored. [/quote]
That’s exactly what I’m getting at here.
The thing is, we can have a box part look like a wedge with the use of a SpecialMesh, there are cases, like for example with a tiny but really detailed part, where advanced collision physics just aren’t needed. I do believe that for certain there should be a built in property for this as there are countless cases where they just aren’t needed. The fact of the matter is, no matter how many times a couple of us say it, you’re not going to listen. So I am going to put this out there, if we can compile a thread of people who would like this option and can give a suitable reason why, if it’s substantial enough, will you consider it?
You did a lot of work to push CSG physics, and we’re really grateful for that, it’s just that at the same time, we’d still like to keep box physics in place since they’re extremely useful in certain cases.
“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.
1 Like