MD3-based collision support via ZScript

[Apeirogon]

I hope zzxyz dont mind
https://drive.google.com/file/d/18jZDTU ... KKCGg/view

[ZZYZX]

I reuploaded and changed the link in the first post, btw.

Also: code is not usable in normal projects. And this is not due to speed. This is due to logic/maths issues that are still not resolved. The project waits for someone who actually knows shit

[ketmar]

and i am still suggesting precalculated beveled BSP solution.

[Darkcrafter]

Well, I made it work with a stone 3d model. It didn't work well though. My idea is placing many little things around a 3d model surface with -noclip and -nogravity flags so player could walk on the top of it. That would allow creating more sophisticated geometry in 3d editors and use it in game having more fun out if it. I don't know if it's possible to assign a separate array of such boxes with MD3 so that would work without any need for a map editor to do this, so that layer would even be scaled along with "scale" parameter in doom builder. There is a danger that with different scales, different density and different bounding boxes sizes could be required. I believe this approach will work for some geometry like rocks, stones and some other things. For the algorithm I would go with remeshing. It's not perfect so we would additinaly require a special collision editor for this where we could place boxes of different sizes and dimensions manually.

[ZZYZX]

The problem with many small things is the slowdown that it will inevitably cause, and also absence of support for non-orthogonal geometry (sloped triangles, in any direction, or spheres).
Also the collision model will have to be entirely convex to allow guessing "inner spaces" to fill. But in theory, this can work.

[Darkcrafter]

This thing can be useful: https://www.geeks3d.com/20160531/mesh-voxelization/ but here is the question arises: how should its output be converted into decorate based actors that should be spread around the map, also how can it be trasformed according to such things properties like scale, pitch, angle and roll, I think this is possible by exporting all of a map "things" into a separate temporary mesh file and be processed by this alghorithm for each thing separately, nothing bad will happen if multiple of such collision actors intersect. But yeah it's a road to slowdown. But I think modern CPUs with multiple threads will cope nicely with that.

[ketmar]

(sighs) please, people… this is totally crazy. to get reliable AABB coldet on triangle soup (so you'll be able to implement sliding properly) you need around ten planes per triangle (effectively turning each triangle into convex brush). this is alot of data to process, you cannot do it with reasonable speed without good spatial subdivision. and you cannot do smooth "sliding" transition without engine support (because now you need to implement slidemove in honest three dimensions).

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.

[Darkcrafter]

I'm getting really curious on what kind of algorithms did Battlefield 2 use, as I got into game files meshes come with a 3d model and a special separate collision mesh file. Collision worked really cool in stalker shadow of chernobyl too but I'm not aware what's there. Any thoughts?

[ketmar]

sure. everybody is using minkowski sum to convert the problem from body-vs-body to body-vs-ray. there is no other algorithm that can give acceptable real-time results for swept volumes.

p.s.: except doom. doom code is a mess.

[Darkcrafter]

I really don't understand your sarcasm here, consider I'm a big noob and know what file is. I haven't heard anything about Mr.Minkowski either. Trying to repeat: does anybody know what was used in BF2 and Stalker shadow of chernobyl for collision on 3d models?

I really want this geometry to be walkable and solid without that much effor I put into it while gently placing special invisible "collision actors" around their md3 surface.

[ketmar]

it is not a sarcasm, it is a general description of majority of coldet algorithms out there. you asked something from the field where you should have strong math background, otherwise you won't understand the answer. if you don't know what minkowski sum is, you won't understand more complex algorithm descriptions, because most of them are either building, or approximating minkowski sum (even SAT to some extent).

p.s.: most of the games does it like this: `if (traceShape(&tracestruct)) { wow! it collides! }` now THIS is sarcasm.

[TDRR]

What if we made a plugin for GZDB that adds invisible bridge things to the selected models?

[Darkcrafter]

it is not a sarcasm, it is a general description of majority of coldet algorithms out there. you asked something from the field where you should have strong math background, otherwise you won't understand the answer. if you don't know what minkowski sum is, you won't understand more complex algorithm descriptions, because most of them are either building, or approximating minkowski sum (even SAT to some extent).

p.s.: most of the games does it like this: `if (traceShape(&tracestruct)) { wow! it collides! }` now THIS is sarcasm.

Now I understood that I need to have a good math background, thanks!

What if we made a plugin for GZDB that adds invisible bridge things to the selected models?

Either I don't know what this is exactly or there is no use of that. An MD3 model actor already has a bounding box collission but it's not scalable and can't be rotated according to things parameters like pitch, roll, scale and angle. Did you know that these bounding boxes don't rotate according to angle at which a thing is set on, they always stay static, the only thing they have is height and radius (yes they are actualy 3d cubes). So for computer to automatically decide on where player or another actor like rocket can collide to walk or explode is to use a special collision detection algorithm that we're all currently looking for. So far at least my approach works semi decently now. I have managed to create a special set of such irrenderable collision actors with different height and radius and just spread them around the surface that my md3 models "have".

Here is an example of such decorate based actor:

actor Collision_32x32 24200
{
Height 32
Radius 32
+NOGRAVITY
+SOLID
States
{
Spawn:
SP1R A -1

Loop
}
}

This is what it looks like in GZDoom Builder BugFix:

[ketmar]

as i said several times here, you can't have what you want without rewriting the whole doom collision detection code. that code is deeply flawed, totally unextendable, and almost unmaintainable. in Q3 Carmack did excellent job on collision detection, but doom is just an ugly hack over another ugly hack.

you can write something to approximate your models with 3d floors, but then, why don't create it with 3d floors in the first place?

[power mode on] i know what i am talking about, as i am the author of the sourceport, where i am working on completely replacing doom coldet code with Q3-like coldet code.

[Graf Zahl]

as i said several times here, you can't have what you want without rewriting the whole doom collision detection code. that code is deeply flawed, totally unextendable, and almost unmaintainable.

I already said that when this thing started. With the code as it is, this is never going to work, and unfortunately it imposes several limitations on what the game can do.

i know what i am talking about, as i am the author of the sourceport, where i am working on completely replacing doom coldet code with Q3-like coldet code.

That may be the only way to fix the design flaws in Doom's play code. However, it's not just the collision detection but lots of other code working with the same logic or depending on how the collision detection works. Ultimately you'll have top rip out a huge bunch of code out of the core files and replace it, and I can almost guarantee that the game won't feel the same afterward anymore, there's simply too much depending on its weird physics. That is the main reason why I never invested any thought in this, on purely technical terms it'd certainly fix lots of things but since it fundamentally changes how the game handles I'm not sure it'll be accepted by the players.