Hey guys. I’ve made a lot of progress on this VR mod, and I’m about to start working on this part I’ve neglected for a while, and that’s the collision.
I’ve wanted to use pill collision for a long time which basically means instead of the standard mins maxs values, you’d have a 8-16 sided cylinder, with two 16 sided UV spheres on either end. The pill should also be able to collide properly with surfaces after experiencing any arbitrary rotation.
I get confused when I start reading the deeper collision code, and am not entirely sure what’s going on? Anyone willing to help push me in the right direction?
Holy crap! That would be a ton of work. I think it’s doable, but it feels to me like I would be basically writing a physics engine, which would probably be totally unnecessary.
There’s gotta be a way to just make the player physics a compound cylinder + two spheres without changing the code too much. Q3Rally did something similar, but with vehicle meshes. Does anyone know about that?
Non-rotating capsule collision (cylinder + two spheres) is mostly working in Spearmint. Set g_playerCapsule 1 before player spawns.
Unfortunately, players sometimes get stuck to each other. Presumably due to bugs in cm_trace.c. Start q3ctf1 and add 60 bots on blue team and wait at blue jumppad.
Players landing on players often don’t get groundEntityNum set.
Running into a crouching player makes runner move up. Probably trying to step up on the player due to shorter height at sphere edges.
Pre-2013 history squash: cm_trace.c capsules fixes
Current code: Spearmint engine + mint-arena mod code
Note: GPLv3+ with additional Zenimax license clauses. The capsule fixes are my code though and I don’t have an issue with them being used as GPLv2+. Capsule engine improvements may be ported to ioq3 if I ever actually finish fixing them.
There is potential bot issues with changing the bounding box due to AAS just using player origin with a world has been expanded based on player’s AABB bounding box size. Worse case scenario, bots have to use AABB for collision with the world.
Awesome. I might start writing my own thing from scratch though, since I have to make sure the pill can be rotated arbitrarily and collide with, for instance, a ledge, at an angle like 30 or 78 degrees.
The reason is I’m trying to have objects be able to collide with a wall and move along a wall like this:
It’s similar to how Sonic moves in this very faithful sonic 3D remake:
Do you think it’s possible to get a mesh to collide at whatever rotation, and B, be able to move along a wall as if it were the floor? If not, what steps do you think I might need to take to make that happen?
Yeah, I think pretty much anything can be done if you spend enough time on it.
Add start origin angles and maybe end origin angles to trap_Trace() so engine knows angles of the moving object.
Get angles of entities collided with in SV_ClipMoveToEntities() / CG_ClipMoveToEntities() – which is already done for BSP submodels (doors and moving platforms).
Handle the collision physics in cm_trace.c using the existing BSP submodel/leaf collision. The hardest part is figuring out how to setup a BSP submodel shaped like an approximated pill. I would make a test map with a func_static shaped like the collision pill and then make player collision use BSP submodel index 1 instead of BOX_MODEL_HANDLE. Then try printing the information for the pill so it can be set up in code so you don’t have to include the collision mesh into every map. Or just rewrite/fix the capsule code in cm_trace.c.
Make Pmove() handle per-player directional gravity.
I think the biggest flaw of this is that rotating an approximated sized cylinder would prevent players from turning it they are against the wall or another player. Though that can probably be solved by not rotating the YAW of the collision pill.
So I think I’m going to use Bullet 3D for it. I’m wondering if it makes sense to replace the box tracing and world collision code with a proper physics engine that handles all player vs world collisions. Is that even feasible to do, while being networked, do you think? Would it make more sense to try to figure out how to do it by modding Q3A’s existing code?
I’ve made progress in the VR Q3A mod, and having 6dof would be more than icing on the cake. It would be like having an extra cake entirely.
NOTE: although both engines are still idtech3 based, they do not have much to do with Q3 anymore (they are based upon Xreal).
Moreover, both are in a very early stage (or dead?), and as far as Qio is concerned the game code, ui etc. is missing.
But hey, maybe it helps you to add a physics engine!
