MD3-based collision support via ZScript

[ketmar]

yeah, gzdoom cannot just replace it, because some obscure mod or map will inevitably break. lucky me, i don't care: k8vavoom is already too far away from vanilla, and i am not going to support every mod or map out here. ;-)

for others: as Graf said, don't expect it to be in gzdoom engine. introducing this "small" (no, it is not small at all) feature will break alot of things you may not even know about. and then some other people will come complaining that their lovely mod/map is not working anymore.

and no, having two separate coldet implementations won't work too. gzdoom still have occasional glitches with portals, and portals are much less intrusive. adding another independent coldet mechanics will cause chaos all around. plus, now devs will have to support two completely different code bases for the same thing, and this is like x6 harder (no, not x2, at least x6).

[ZZYZX]

this is fun PoC, but not really more than that. the only way to get this working is implement triangle soup support in the engine. which won't happen, i think.

You probably need to understand that this was mainly so that I can make stuff like 3d pipes hanging from the ceiling and having collision automatically. Or for me to be able to model stalactites/stalagmites/small lava craters in a cave and have a nice texture on them. It was not so that whole level can be constructed of 3D models.
So yea if it didn't have weird logic issues, I would use it in mapping (and would suggest using it to people who are also using 3D objects as an addition to a regular map).

btw: IIRC I'm treating triangles as something that has 5 planes, not sure what 10 are for. Front, back, and 3 connections between the dots. And if there is another triangle (i.e. if the triangle edge does not hang in the air) the edge plane is aligned with the triangle one. Aaaaand... sliding does work? Or you are saying that to fix this small issue I have to rewrite sliding from scratch?

[Nash]

Currently the most practical way of getting collision on "static" meshes in GZDoom is by enclosing them with invisible 3D floors. Anything else is just too cumbersome to setup and more importantly would scale poorly in terms of performance.

[ketmar]

@ZZYZX: and i am not talking about turning the whole game into triangle soup too. what i am talking about is fast and robust (both things matters) collision system, that works seamlessly with doom quirky physics and movement. impossible task. besides that, alias models are badly suited to work as collision meshes, but this is another story.

>I'm treating triangles as something that has 5 planes, not sure what 10 are for.
for robust "swept AABB vs triangle" collision check. to find real collision plane and normal, you have to do raycast instead of "AABB cast". and to do raycast, you need to shift planes, effectively doing minkowski sum of triangle and AABB. and to make that work, you need your inflated brush to include both AABB and triangle points. and to do that, in turn, you need to cap your triangle with axial planes on each vertex. after such capping you can safely perform raycast against a triangle, and your AABB will never miss it, and will never hit an empty space. in exchange you're getting stable, robust, and error-free collision system, and your sliding code becomes a trivial thing, operating on planes returned from sweep test.

(p.s.: this is that "beveling" i kept talking about. for AABB, it is enough to cap your brush; for spheres, you need to "bevel" them. as capping can be seen as a special case of beveling, i kept calling it all "beveling". ;-)

>Currently the most practical way of getting collision on "static" meshes in
>GZDoom is by enclosing them with invisible 3D floors. Anything else is just too
>cumbersome to setup and more importantly would scale poorly in terms of
>performance.
that is what i going to say too.

[Graf Zahl]

this is fun PoC, but not really more than that. the only way to get this working is implement triangle soup support in the engine. which won't happen, i think.

You probably need to understand that this was mainly so that I can make stuff like 3d pipes hanging from the ceiling and having collision automatically. Or for me to be able to model stalactites/stalagmites/small lava craters in a cave and have a nice texture on them. It was not so that whole level can be constructed of 3D models.
So yea if it didn't have weird logic issues, I would use it in mapping (and would suggest using it to people who are also using 3D objects as an addition to a regular map).

Even then it would have been better to do it as a C++ extension in the engine and not as a scripted mod so that it could have been turned into a usable feature for everybody.

[ketmar]

still, physics problems are imminent. doom does its movement in two separate steps: first strictly XY, then vertical. this is a freakin' PITA for true 3d collisions, and a source of major problems in my current attempts to replace coldet code. you cannot just add gravity to your velocity vector and call `P_SlideMove()` anymore, you have to do it in two separate steps. yet you can't just omit floor and ceiling checks, because of slopes (and 3d floors). also, Doomguy is usually standing inside a floor, not "on" it, which doesn't help also (and it cannot be changed, as alot of code does checks like "mobj->Origin.z == floor.z").

now just imagine that you have to marry "microteleportation"-based original coldet, and CCD... my "x6" estimation was prolly too optimistic. ;-)

p.s.: "first strictly XY, then vertical" -- now, this is a lie too. it is even more complicated than that.

[Graf Zahl]

still, physics problems are imminent. doom does its movement in two separate steps: first strictly XY, then vertical. this is a freakin' PITA for true 3d collisions, and a source of major problems in my current attempts to replace coldet code.

This is the biggest fuckup in the entire Doom movement code and the source of endless problems with movement precision.
Another is that the entire movement code is essentially 2D with the z-component as a sloppily handled afterthought, not an integral dimension.

In fact, a lot of this looks like it has been ripped right out of a 2D engine and quickly hacked to work for Doom.

[ketmar]

yeah. i alredy tried several solutions to this (as i REALLY want to unify the code), but i think that in the end i'll leave 2d `traceBox()` alone, and will do 3d (vertical movement, i mean) as a separate step, and then will try to somehow blend them together.