Physics engine for G/ZDoom, and the "proper" ways to do it?

[TDRR]

So i have been working on a physics engine for G/ZDoom, but i'm not doing it as fast as i would do anything else, because i'm not sure what would be the best way to do something.

For instance, object rotation. I'm using models, but what about the physical raidus and height? Is there any way of rotating it or do i have to keep doing it the way i'm doing it?
The way i'm doing it right now, is i'm spawning smaller collision boxes to simulate rotating the object. Then those boxes check if they are hitting anything and if they do, stop moving. Obviously i will add more precise collision but for now i'm just testing what can i do without too much problem.

Also, what do you think a simple physics engine would need to have? What does it need the most in your opinion?
Do you think a physics engine for ZDoom should be done? Would it be useful or not?

[Matt]

Define "physics engine".

[TDRR]

Define "physics engine".

Like the Source engine physics. Stuff like a flat table falls down from some considerable height and upon touching the floor it could tumble if there's enough velocity to do so (any movement on the x and y axis is good enough) or you push a barrel and it rolls like you would expect a barrel to, or put it on a hill and watch it go down it. You make a domino tumble into a wall and once it touches it, it could slide down the rest of the wall or stay slightly tilted if the angle isn't too low.

Basically, just more realistic physics simulation than what ZDoom offers by default.

[Graf Zahl]

For stuff like that you better target an engine made with real physics in mind. Doing this on the scripting side is virtually impossible, you'd have to alter some engine internals quite significantly for it.

[TDRR]

For stuff like that you better target an engine made with real physics in mind. Doing this on the scripting side is virtually impossible, you'd have to alter some engine internals quite significantly for it.

I know this is absolutely brutal to do without source modifications, i just want to see how far i can get and release that. Probably my adventure will be cut fairly short and i won't get to too much but i enjoy doing this.

I'm not really wanting hyper-realistic phyisics but just simple stuff like objects somewhat accurately colliding with each other (which i have managed but it's still not 100% finished, still got optimizations to do) simple tumbling mechanics and perhaps even barrels rolling off hills but i'm not sure if i can do that one.

I also know about other engines but GZDoom is just so easy to use compared to literally anything else i have seen around (And about the only thing that runs good on this PC) so i want to make it better. (Or at least as much as my rather limited experience with DECORATE, ACS and some ZScript allows me to)

[Guest]

This could be partly manageable in zscript.
Decorate and ACS? Good luck.

[Matt]

not really wanting hyper-realistic phyisics but just simple stuff

Hence... "define".

If you wanted a controlled limited environment where nothing noticeably changed shape or vertical alignment, dealing pretty much only in momentary collisions, I think ZS would be enough for something like a pool table.

An asteroid shooter that had gravity and orbit and material hardness and whatnot would be a good deal harder (slightly harder in 2D, a lot harder in 3D) but it would still be mostly workable.

Swords and shields clashing and pressing against each other....... that could take a while.

(Extra challenge: 9-pin bowling game where the pins fall and potentially knock down other pins like in real life.)

[TDRR]

Swords and shields clashing and pressing against each other....... that could take a while.

Actually, that's super easy to do compared to literally everything else. Using angle-relative spawn functions to spawn smaller collision boxes and updating their position every... 2 tics maybe? And taking advantage of the +MISSILE flag to check if they are touching anything else. If so, they tell their master object (In this case it would be a sword) that they are indeed touching something and stop moving until the other object goes away.

This one i actually did it using DECORATE only so i imagine it would be even easier with ZScript.

If you wanted a controlled limited environment where nothing noticeably changed shape or vertical alignment, dealing pretty much only in momentary collisions, I think ZS would be enough for something like a pool table.

The goal is to have this new "physics engine" work in most conditions, all the modder using the physics engine must do is adjust some things on their props so they get affected by this physics engine (But that's only if they are using models, sprites are definitely harder to get working with this)

(Extra challenge: 9-pin bowling game where the pins fall and potentially knock down other pins like in real life.)

That one would actually be pretty interesting, maybe it could be done with what i already got.

This could be partly manageable in zscript.
Decorate and ACS? Good luck.

Challenge accepted

[Matt]

Actually, that's super easy to do compared to literally everything else. Using angle-relative spawn functions to spawn smaller collision boxes and updating their position every... 2 tics maybe? And taking advantage of the +MISSILE flag to check if they are touching anything else. If so, they tell their master object (In this case it would be a sword) that they are indeed touching something and stop moving until the other object goes away.

The Icon of Sin lurking in the implementation details has been spawning more devils than the number of minutes either of us has thought about this problem.

Consider:

- Immediately before the pushing, the swords are moving into each other at full speed. For a 56-unit player that's gonna be like 20 units. A typical RL sword blade is about 1 unit wide. Need continuous collision check for the plane of movement for each sword, then evaulate where they will meet in the middle.

- Swords are scraping and sliding and bouncing off each other. Need to get angle of impact and force, and possibly how each sword is being held.

- Leverage in displacing opponent's sword, and calculating the new angle of each sword in that case.

- Damage if the blade touches the opponent.

- Back to the original scenario: two opponents pushing each other with sustained contact. Calculate amount of force and resistance on each, once (or at most maybe 10 times) per tick, without:
* getting stuck inside each other
* uncontrollably jiggling comically
* suddenly launching one or both actors at extreme velocity and/or setting them on fire
* arbitrarily making one of them absolutely immobile
* the moving platform underneath them falling away while they remain in midair

[TDRR]

The Icon of Sin lurking in the implementation details has been spawning more devils than the number of minutes either of us has thought about this problem.

Consider:

- Immediately before the pushing, the swords are moving into each other at full speed. For a 56-unit player that's gonna be like 20 units. A typical RL sword blade is about 1 unit wide. Need continuous collision check for the plane of movement for each sword, then evaulate where they will meet in the middle.

- Swords are scraping and sliding and bouncing off each other. Need to get angle of impact and force, and possibly how each sword is being held.

- Leverage in displacing opponent's sword, and calculating the new angle of each sword in that case.

- Damage if the blade touches the opponent.

- Back to the original scenario: two opponents pushing each other with sustained contact. Calculate amount of force and resistance on each, once (or at most maybe 10 times) per tick, without:
* getting stuck inside each other
* uncontrollably jiggling comically
* suddenly launching one or both actors at extreme velocity and/or setting them on fire
* arbitrarily making one of them absolutely immobile
* the moving platform underneath them falling away while they remain in midair

Most of that is waaaay out of the scope (And overall possibilities) of this engine. Not sure where are you going with all that sword stuff but this is only meant to be used with props laying around the map. Not weapons, monsters or anything like that, just decorative objects except you can now interact with them in a more dynamical way.

Under normal conditions, two props probably will never be pushing into each other unless it's multiplayer and two guys are bashing two bricks together or something like that. Even then, the worst that happens is both props go though each other, and that's only with high speeds and constant pushing. If the object they were standing on somehow dissapears or just moves away, both props fall normally as they are still subject to gravity. Obviously i won't change the vertical velocity of the objects if they are colliding with something else horizontally, because that would just be extremely buggy.

I would love to see stuff uncontrollably jiggling, that sadly never happens with this engine no matter what you do, but it would be so funny when that happens out of nowhere!

[Nash]

You better like maths and quaternions then, because it's going to be a long ride. :^)

As Graf said, this is the completely wrong engine for it, and a scripted solution will not scale well, or even be useful in a practical situation. I mean, look at the ZScript-based MD3 collision thing that was posted here a long time ago... technically very impressive, but not only slow, but absolutely impractical to implement in a serious project.

[TDRR]

You better like maths and quaternions then, because it's going to be a long ride. :^)

As Graf said, this is the completely wrong engine for it, and a scripted solution will not scale well, or even be useful in a practical situation. I mean, look at the ZScript-based MD3 collision thing that was posted here a long time ago... technically very impressive, but not only slow, but absolutely impractical to implement in a serious project.

I have done most of what i wanted to achieve without complex maths and quaternions, but it's true that it's hard to put into a project (Well not hard, just very tedious), so i guess it's mostly for my own projects. Still it's going to be released under the same old MIT license and if anyone has the patience to add it into their project then that's fine by me.

Anyways it's not exactly a massive game changer or anything of the sort, it's just a somewhat small improvement. No ragdolls or anything like that, but rotating props, proper collision for those and basic tumbling but that's about it.

[Matt]

The sword problem was intended to be an example of the opposite extreme end from the pool table problem.

I would love to see stuff uncontrollably jiggling, that sadly never happens with this engine no matter what you do, but it would be so funny when that happens out of nowhere!

That specific one was based on my experience trying to see if I could simulate a "real" weapon business end in HD that would have its own momentum independent of the player - it worked in principle, albeit with some hacks to keep the thing from flying away from the player, but it ended up rapidly orbiting the point where it was supposed to be rather than coming to a stop. I mean, technically it kinda would be vibrating like that IRL on a micro or atomic level, but definitely not to that observable, game-breaking degree.

Back on topic, I think the biggest problem (in either sense of that word) would be tumbling, since every actor in the Doom engine is always an orthogonal square pillar that has some numbers attached to it that we pretend are its "pitch" and "angle" (and, some might still argue, "height" and "Z position"). It could be made to do the math, then move the actor, set the Z value and show a sprite or model at a rotation that would reflect more or less what happened to the simulated object, but absent trying to model a new collision system in ZS the actual collision would still be based on checking coordinates within and adjacent to that square pillar rather than e.g. kicking out the leg versus pushing along the top of a table.

[NeuralStunner]

I seem to recall someone figuring out polygonal collision, but I don't think it was very good performance-wise. Of course, physics engines use simplified collision meshes for these things... You'd probably want to wait on a better model implementation for all that.

[TDRR]

Back on topic, I think the biggest problem (in either sense of that word) would be tumbling, since every actor in the Doom engine is always an orthogonal square pillar that has some numbers attached to it that we pretend are its "pitch" and "angle" (and, some might still argue, "height" and "Z position"). It could be made to do the math, then move the actor, set the Z value and show a sprite or model at a rotation that would reflect more or less what happened to the simulated object, but absent trying to model a new collision system in ZS the actual collision would still be based on checking coordinates within and adjacent to that square pillar rather than e.g. kicking out the leg versus pushing along the top of a table.

That's not really a problem at all with how i'm doing things, which i already mentioned in the OP.

Is there any way of rotating it or do i have to keep doing it the way i'm doing it?
The way i'm doing it right now, is i'm spawning smaller collision boxes to simulate rotating the object. Then those boxes check if they are hitting anything and if they do, stop moving.

I guess they aren't perfect, but it's much better than no rotation at all. You can even duck under a slanted prop!