ZDoom

by **TDRR** » Fri Jul 12, 2019 11:35 am

Apeirogon wrote:Yeah, I once try add to gzdoom, on zscript side, some PhysX stuff, but I almost always rested on restrictions of source code.
It can be changed, but it break something else in the game/takes too much time to rewrite it. So except some most basic stuff, like pushing objects, pendulums and momentum, you pretty much or would need to change source code or write walls of code from crutches and hacks to do something.
But thats only for mechanics. Continuum physics stuff (heat, pressure, flow, gay-lussac/klapeiron/avogadro laws) dont have such restrictions, since it work on principles which dont simulate in gzdoom, and games in whole. Im pretty sure I see some patch for hideous destructor which use temperature of environment to do thing with player and players weapon.

But from other hand, who need continuum mechanics in games?

It's true that i'm using a few hacks, but i wouldn't consider them "walls of code", these hacks just rely on very, very simple stuff:
I have already said how i'm rotating actor collision in the OP so no need to mention it again.
To know when an actor should tumble, a few things are checked: First, if it has been in mid-air and now is resting on the floor, and if it's X/Y movement is big enough to cause it to tumble over or even keep rotating.

I would love to make objects roll down slopes but apparently it's impossible to get if the floor is sloped from ACS. Maybe will save it for the ZScript version.

Kinsie wrote:While "real" physics is a pretty difficult ask, there are probably some fun things that can be implemented, like MBF's thing where, and I quote the readme, "Non-sentient objects fall down under their own weight when their balance is upset and they are more than halfway off of a ledge"

That one would be really cool to add, and possibly not hard but mostly just laggy. In DECORATE you could do it by firing 4 missiles at the ground, and these return nothing when they are at the same height as their parent, or return an inventory item if they are lower than their parent. Probably better left for ZScript as it could be less laggy.

by **Apeirogon** » Fri Jul 12, 2019 11:17 am

Yeah, I once try add to gzdoom, on zscript side, some PhysX stuff, but I almost always rested on restrictions of source code.
It can be changed, but it break something else in the game/takes too much time to rewrite it. So except some most basic stuff, like pushing objects, pendulums and momentum, you pretty much or would need to change source code or write walls of code from crutches and hacks to do something.
But thats only for mechanics. Continuum physics stuff (heat, pressure, flow, gay-lussac/klapeiron/avogadro laws) dont have such restrictions, since it work on principles which dont simulate in gzdoom, and games in whole. Im pretty sure I see some patch for hideous destructor which use temperature of environment to do thing with player and players weapon.

But from other hand, who need continuum mechanics in games?

by **InsanityBringer** » Fri Jul 12, 2019 9:35 am

A lot of the MBF physics additions felt really weird, but things falling off of ledges was fairly cool, and I wouldn't mind it as an actor option as mentioned.

... though I also imagine implementing that would be a pretty big hack to implement, heh. Maybe a similar system can be scripted..

by **Kinsie** » Fri Jul 12, 2019 6:45 am

Oh, I can easily see why ZDoom removed it, but as a mod-specific, per-actor addition some fun set-pieces could be arranged.

by **Graf Zahl** » Fri Jul 12, 2019 3:41 am

You mean that thing that totally breaks Doom physics? There's a good reason ZDoom removed support for it very early in its history.

by **Kinsie** » Fri Jul 12, 2019 3:22 am

While "real" physics is a pretty difficult ask, there are probably some fun things that can be implemented, like MBF's thing where, and I quote the readme, "Non-sentient objects fall down under their own weight when their balance is upset and they are more than halfway off of a ledge"

by **TDRR** » Thu Jul 11, 2019 9:59 pm

Matt wrote: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.

TDRR wrote: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!

by **NeuralStunner** » Thu Jul 11, 2019 5:09 pm

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.

by **Matt** » Thu Jul 11, 2019 4:50 pm

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

TDRR wrote: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.

by **TDRR** » Thu Jul 11, 2019 2:35 pm

Nash wrote: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.

by **Nash** » Thu Jul 11, 2019 1:55 pm

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.

by **TDRR** » Thu Jul 11, 2019 1:13 pm

Matt wrote: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!

by **Matt** » Thu Jul 11, 2019 1:00 pm

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

by **TDRR** » Thu Jul 11, 2019 11:24 am

Matt wrote: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.

Matt wrote: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)

Matt wrote:(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.

Martin Greenshaw wrote:This could be partly manageable in zscript.
Decorate and ACS? Good luck.

Challenge accepted

by **Matt** » Thu Jul 11, 2019 10:27 am

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.)

ZDoom

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

Post a reply

Expand view Topic review: Physics engine for G/ZDoom, and the "proper" ways to do it?

Re: Physics engine for G/ZDoom, and the "proper" ways to do

Re: Physics engine for G/ZDoom, and the "proper" ways to do

Re: Physics engine for G/ZDoom, and the "proper" ways to do

Re: Physics engine for G/ZDoom, and the "proper" ways to do

Re: Physics engine for G/ZDoom, and the "proper" ways to do

Re: Physics engine for G/ZDoom, and the "proper" ways to do

Re: Physics engine for G/ZDoom, and the "proper" ways to do

Re: Physics engine for G/ZDoom, and the "proper" ways to do

Re: Physics engine for G/ZDoom, and the "proper" ways to do

Re: Physics engine for G/ZDoom, and the "proper" ways to do

Re: Physics engine for G/ZDoom, and the "proper" ways to do

Re: Physics engine for G/ZDoom, and the "proper" ways to do

Re: Physics engine for G/ZDoom, and the "proper" ways to do

Re: Physics engine for G/ZDoom, and the "proper" ways to do

Re: Physics engine for G/ZDoom, and the "proper" ways to do

Post a reply

Expand view Topic review: Physics engine for G/ZDoom, and the "proper" ways to do it?

Login • Register