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.

[Deybar_TECH]

Hi, I'm interested in using this model detector in my project since I want to use 3D models and textures
realistic from (Google Earth) and I don't want to try to transfer/convert the model geometry to
(Universal Doom Map Format/UDMF) in some map editor.

the credits will be for (ZZYZX).

[TDRR]

Hi, I'm interested in using this model detector in my project since I want to use 3D models and textures
realistic from (Google Earth) and I don't want to try to transfer/convert the model geometry to
(Universal Doom Map Format/UDMF) in some map editor.

the credits will be for (ZZYZX).

Just to let you know, that would cause large slowdown with many models. (More than 10 i imagine already slows down a lot
EDIT: Maybe not that low amount of models, but since you are doing a flight simulator i think you are going to place many of them and anyways the way the collision works is not really appropiate for a flight simulator. Your plane would slide along the walls of a model or just flat out get stuck in it if the model you are going to use has lots of complex geometry.

Use MODELDEF, a DECORATE actor and use 3D floors to make fake collision with it.

[TDRR]

So, anyone has any idea why this model doesn't have collision?
https://www.mediafire.com/file/6ipdq47g ... n.pk3/file

It's an import of the garden in the observatory of Super Mario Galaxy 1. I repeated the exact same process i did for a SM64 map import and it worked very well, but this simply has no collision at all.

Some of the textures are wrong but it's as good as i could get them from memory and it's been a long time since i last played SMG1.

[Deybar_TECH]

well I think I didn't think much about the slowdown.
but really my game needs a good aesthetic, use real-life models. like the ones it offers (google earth). and I think that until (* zdoom) doesn't improve its collision system, I won't be able to take advantage of that feature as it should.

So, anyone has any idea why this model doesn't have collision?

experimenting with this code I found that the model needs to have the properties (height & radius) surrounding the entire model in addition to retaining its (scale: 1.0). and the 3D model in (modeldef) has to cope with the scale in the code (zscript) and you don't have to use flags like: (NOINTERACTION, THRUACTORS) for the collision to really work.

te respondo en idioma ingles para que los demás puedan entender.

[TDRR]

well I think I didn't think much about the slowdown.
but really my game needs a good aesthetic, use real-life models. like the ones it offers (google earth). and I think that until (* zdoom) doesn't improve its collision system, I won't be able to take advantage of that feature as it should.

So, anyone has any idea why this model doesn't have collision?

experimenting with this code I found that the model needs to have the properties (height & radius) surrounding the entire model in addition to retaining its (scale: 1.0). and the 3D model in (modeldef) has to cope with the scale in the code (zscript) and you don't have to use flags like: (NOINTERACTION, THRUACTORS) for the collision to really work.

te respondo en idioma ingles para que los demás puedan entender.

I already tried this and it didn't work. I even tried to set Radius and Height to 32767 which didn't work either. I'm stumped, another SM64 model import works just fine (But with messed up textures) yet it has full collision.