MD3-based collision support via ZScript

Ask about ACS, DECORATE, ZScript, or any other scripting questions here!

Moderator: GZDoom Developers

Forum rules
Before asking on how to use a ZDoom feature, read the ZDoom wiki first. If you still don't understand how to use a feature, then ask here.

Please bear in mind that the people helping you do not automatically know how much you know. You may be asked to upload your project file to look at. Don't be afraid to ask questions about what things mean, but also please be patient with the people trying to help you. (And helpers, please be patient with the person you're trying to help!)
User avatar
Apeirogon
Posts: 1605
Joined: Mon Jun 12, 2017 12:57 am

Re: MD3-based collision support via ZScript

Post by Apeirogon »

User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine
Contact:

Re: MD3-based collision support via ZScript

Post by 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 :p
User avatar
ketmar
Posts: 160
Joined: Sat Oct 01, 2016 6:26 am
Contact:

Re: MD3-based collision support via ZScript

Post by ketmar »

and i am still suggesting precalculated beveled BSP solution.
User avatar
Darkcrafter
Posts: 562
Joined: Sat Sep 23, 2017 8:42 am
Operating System Version (Optional): Windows 10
Graphics Processor: nVidia with Vulkan support

Re: MD3-based collision support via ZScript

Post by 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.
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine
Contact:

Re: MD3-based collision support via ZScript

Post by 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.
User avatar
Darkcrafter
Posts: 562
Joined: Sat Sep 23, 2017 8:42 am
Operating System Version (Optional): Windows 10
Graphics Processor: nVidia with Vulkan support

Re: MD3-based collision support via ZScript

Post by 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.
User avatar
ketmar
Posts: 160
Joined: Sat Oct 01, 2016 6:26 am
Contact:

Re: MD3-based collision support via ZScript

Post by 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.
User avatar
Darkcrafter
Posts: 562
Joined: Sat Sep 23, 2017 8:42 am
Operating System Version (Optional): Windows 10
Graphics Processor: nVidia with Vulkan support

Re: MD3-based collision support via ZScript

Post by 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?
User avatar
ketmar
Posts: 160
Joined: Sat Oct 01, 2016 6:26 am
Contact:

Re: MD3-based collision support via ZScript

Post by 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.
User avatar
Darkcrafter
Posts: 562
Joined: Sat Sep 23, 2017 8:42 am
Operating System Version (Optional): Windows 10
Graphics Processor: nVidia with Vulkan support

Re: MD3-based collision support via ZScript

Post by 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.
Attachments
Screenshot_Doom_20190508_000727.jpg
User avatar
ketmar
Posts: 160
Joined: Sat Oct 01, 2016 6:26 am
Contact:

Re: MD3-based collision support via ZScript

Post by 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.
User avatar
TDRR
Posts: 815
Joined: Sun Mar 11, 2018 4:15 pm
Operating System Version (Optional): Manjaro/Win 8.1
Graphics Processor: Intel (Modern GZDoom)
Location: Venezuela

Re: MD3-based collision support via ZScript

Post by TDRR »

What if we made a plugin for GZDB that adds invisible bridge things to the selected models?
User avatar
Darkcrafter
Posts: 562
Joined: Sat Sep 23, 2017 8:42 am
Operating System Version (Optional): Windows 10
Graphics Processor: nVidia with Vulkan support

Re: MD3-based collision support via ZScript

Post by Darkcrafter »

ketmar wrote: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!
TDRR wrote: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:
Attachments
CollisionMess.jpg
User avatar
ketmar
Posts: 160
Joined: Sat Oct 01, 2016 6:26 am
Contact:

Re: MD3-based collision support via ZScript

Post by 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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: MD3-based collision support via ZScript

Post by Graf Zahl »

ketmar wrote: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.
Post Reply

Return to “Scripting”