Parenting but with physics

s&box suggestions & feedback
#1

If you were part of any of the building communities (ACF, NavalPlay, Flood, Airwars) then you probably know already what I’m talking about.
Using the parenting tool would result to the prop losing all of its physics, this was inevitable due to the unusual convex shapes that would result if we tried merging the hitboxes, which even some of the best physics simulators have a hard time with.
All we could do is weld and nocollide, which on a larger scale leads to server lag.
These limitations forced us to be creative, like Airwars not actually having any actual physics but instead simulating everything granting us an infinite battlefield as well. Another invention being one of my own: OptiWeld, which would automatically find the closest props to weld and no collide reducing greatly the amount of constraints if it were to be done by hand.
Other workarounds are making a giant invisible prop in the middle that everything connects to, which was the best option for performance but wasn’t realistic as cutting a ship in half would lead to both pieces still attached.

What I wanted to know is if it was possible keeping physics with parenting, they could be a part of a single entity that ignores collision with nearby collision boxes like ragdolls do while avoiding the problem of creating one giant messy hitbox.

Procedural geometry
#2

I always thought that “weld” was more of a “nail” since welding would be more akin to fusing 2 props, which it did not.

Having a parent-like weld is one of the best things a builder could ask for, it’s a shame that after so long it’s still not a thing, even in other games, I hope source 2 can offer something like it but I am not too hopeful :pensive:

#3

During many development updates, Facepunch showed changes made in modeldoc automatically updating in-game, if this extends to mesh and collision changes, and if these changes are also streamed to other players, there would be no need to parent stuff anymore. You would simply design your car’s/spaceship’s/raft’s model and stream it in, no need for multiple props.

What mostly causes the difference in performance penalty between a weld and a parent is literally all the physics and collision calculations that are skipped when parenting.

If your aim is to have separately calculated durability (in ACF case) or objects that are not homogeneous (objects that do not have the same density everywhere), the simplest way would be to weld them, which is expected to be less performance taxing in the new physics engine

1 Like
#4

“Parenting with physics” doesn’t make sense, it’s an incorrect term.

What you want is probably physics objects merging, which is already doable in Garry’s Mod but with some hacks and sometimes it leads to crashes as far as I know (procedural physics objects in general that is).

I agree on the point that it would be nice to have a nice API for merging physics objects together, preserving their constraints and shit, like connecting heads of two ragdolls together, making them share the same merged physics object for both entities and ragdoll systems.

I don’t know if it’s possible in Source 2 to use the same physics object for several entities though, that’s where we need a comment from Facepunch.

1 Like
#5

Yes, it would be great, I’m not sure how it would work with ragdolls but wouldn’t it be relatively trivial to merge 2 props together?
You can already have a concave collision using multiple hulls for a single model, and there’s not a hard limit on how many hulls a bone can have, so surely there must be a way to treat 2 props as one.

Of course, I say this with 0 programming experience.

#6

4ov60y
4ov60y500×517 78.8 KB

1 Like
#7

Yeah you are correct, if Havok/Rubikon didn’t support concave physics, that wouldn’t be doable, but since we already saw bottles in boxes in both Garry’s Mod and HL:A, we know for sure that each side of the box is a separate convex part of a multi-convex physics object.

What we need to know though, is how easy it would be to merge these convexes together into a single multi-convex physics object and use it for both entities.

Another problem to solve would be merging physics objects of different types (not all of them are convex/multiconvex geometry), like multiconvex + OBB, sphere + cylinder, etc. We’d need a way to convert them all to multiconvex, but it’d lead to some precision and performance loss compared to physics primitives like spheres or something.

In any case, it’s for sure worth it and needs thinking about.

UPD: And yeah, as Rafael reminded, we’d need to somehow preserve physics properties like mass, material, friction, inertia and all that shit for separate parts of a single physics object, and it’s a good question if we can do that or not.

2 Likes
#8

I don’t think it’s worth worrying about. It must be remembered that this is not Gmod 2 and there should not be such shortcomings as in Gmod.

#9

Source 2 is still Source, so some things are still to be worried about.

1 Like
#10

It does not matter. The above can be done in Source 1 as well.

#11

If this can be done, why the Weld tool from Sandbox gamemode glues props instead of actually welding them?

Can be done with some hacks with limitations and can be done properly are two a bit different things.

Physics properties of both objects aren’t preserved when you create a new one from them, there’s no way to dead-weld a brick to a tire and make it sound like a brick or a tire depending on where you hit the resulting object.

1 Like
#12

Yeah, there’s not much point to having it as a default tool if it’s hacky, doesn’t work properly, is prone to crashing and lags the game.

The best possible option is a simple and elegant solution, and if it’s not that then I’d rather have the old weld.