ZDoom

Nash told me I should make a thread
Some time ago, in the beginning of ZScript, I said that once we get user-readable lumps I'm going to implement walkable models. Apparently, now's the time

Current link: https://www.mediafire.com/file/ycggvsx6 ... 2.pk3/file

Video:

(the video is a bit old: it's not as buggy now)

As of now, as far as I know, it should not noclip or apply stupid velocity values, unless you try to walk between map geometry and a model (this is not implemented yet).

Things left to implement:

• Walking between map model and non-model (essentially this algorithm: https://i.imgur.com/sJRrFgS.png)
• Stepping up with MaxStepHeight
• Optimization of lookup (AABB tree or just two-level 3D AABB structure, 64x64x64 boxes containing inner triangles) (using blockmap greatly reduced the list of triangles to check)
• Moving along with actor attached to the model (i.e.: elevators, platforms..)
• Optionally: NETMODEL lump to make sure all clients share the same version to avoid desyncs
• ...maybe fix slopes? It still slides.

What it actually does: basically, it works on the velocity level, as any proper collision checking should.
Before every Tick(), it checks if actor's movement along it's velocity is going to hit a model, and if it does, it checks for all triangles that were intersected, finds the best triangle (the one that will lowest remaining intersections after inverted velocity is applied), and does this: (which basically slides along triangle's plane, using 3 lines instead of 50 from Doom wall sliding code.)
Then if actor is blocked by anything below it, it will mark it as standing on another actor to fix up bobbing and stuff.

Once this is more complete, I'm also planning to make a compatible hitscan and A_Chase.
Then it will be possible to have some actor like StaticDecoration which will have model name and orientation as properties as opposed to having to specify it in the code.

Well...accroding to how it behaves...it should also work with voxels, Am I right?

Definitely interesting but how is the Performance if you are using a lot of models?

Currently it's not very good even while spamming plasma over a bridge, hence optimization listed in unimplemented.
Regarding voxels: no it won't support voxels. Voxels require completely different handling.

ZZYZX: Wait, why? I understand that voxels are converted do models on runtime. So this wont work with voxels like voxel, but it should work with modelized voxel...

Important correction: voxels are converted to models at runtime by GZDoom (and I have my own loading code) and even then it creates a model with thousands of triangles which is not really suitable for collision.
Voxel collision should be implemented completely separately as AABB or sphere-based, since we know that voxel dots are, well, dots, instead of doing an overkill and using an arbitrary shape collision algorithm to work with them.

Unrelated update: I just put a blockmap in it (list of triangles for every ~64x64x64 block, but max blocks per model is 8x8x8 to reduce count of objects that float in the memory).
It seems to have made it run way faster, especially with large actor counts.

Just tested the blockmap version, firing plasmas into the bridge doesn't cause slowdowns anymore.

However I found another case for MASSIVE slowdown: go to the center bridge, crouch a little so that you can pass through the opening of the tunnel, then stand up while you're still at the edge of the tunnel (your body half under the tunnel and the other half outside of the tunnel)...

I have this fixed locally. Uploaded it.

I just messed around with this and it is amazing. I don't understand how you did this in ZScript despite this being no'd in feature requests for being a pain to implement in the GZDoom source.

Also what does:

ZZYZX wrote:Walking between map model and non-model (essentially this algorithm: https://i.imgur.com/sJRrFgS.png)

mean?
You're amazing keeps doing what you're doing

Means if currently you try to walk between two surfaces with acute angle between them, you will be bumped away in the best case, and stuck between triangles in the worst case.

Oh. That's seems bad, but I'm sure you'll figure it out

But how does quake collision work?

Quake never did any collisions with MD2/MD3 models, only with meshes. and mesh is a thing that has pre-built BSP tree, which is used to do box tracing (with some trickery inside). that is, pre-built BSP tree not only makes things alot faster, it also makes things alot more reliable too. but models doesn't have it.

p.s.: i meant "exact collision" -- AABB checks are there, of course.

doomed_stranger wrote:Quake never did any collisions with MD2/MD3 models, only with meshes.

And that's how it should be done if implemented. Stuff like this may be cool but when used in actual production will quickly fall apart. It's a nice proof of concept but done in the completely wrong place with completely wrong data sets.

yeah. it is possible to build BSP tree for a model, and then use it to do coldet, but… as Graf said, it will be in a wrong place with a wrong data. this is something that should be done in the core engine code, with proper data structures and processing. but then you'd prolly better switch to Quake engine, 'cause mixing 2d and 3d in (GZ)Doom engine will turn it into even bigger mess than it is now. just look at 3d floors — they still have alot of quirks. 'cause they're basically a dirty hack. and full 3d will be even worser.

sure, it is possible to rewrite the engine to do many things properly… but then you will inevitably lost compatibility with alot of mods. compatibility is one of the major reasons why GZDoom is so hard to maintain and to improve.