3D model collision

Moderator: GZDoom Developers

Post Reply
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

3D model collision

Post by Darkcrafter »

I would really like to see GZDoom to support collision for 3D models. I already found a working way to do this now: I place custom decorate based actors around 3D models so it really allows projectiles and other actors to collide, the only thing I don't know how to implelement is to make those collision actors to block monsters view and allow for bullets to collide. But it's so tricky to locate them accurately and it consumes a lot of time and their height still depends on a sector's floor value. How I propose to do that? I'm not a coder unfortunately, but I found this: https://github.com/davidstutz/mesh-voxelization

Even if the thing I mentioned above isn't possible or you guys don't want to do it, can we create special collision actors cloud and assign it to a model in modeldef? Would it be also possible to make this collision cloud scalabe, so bounding boxes will scale among with visual 3D model's part. To scale it among the model the model and collision cloud must have the same origin point? Maybe we could have a special lite software to do exclusively this?

The last time I found myself more interested in modeling such geometry that is not practically possible to do with tools GZDoom has to offer but I can model these things more easily with software that is designed to do that.

Is there also any way to change the rules of collision for such actors so even if there are sharp box corners that force an actor to stuck so it could kind of interpolate it out a bit?

Here is my decorate code:
actor Collision_32x32 24200
{
Height 32
Radius 32
+NOGRAVITY
+SOLID
States
{
Spawn:
SP1R A -1

Loop
}
}

And I have a big variety of such actors with different bounding box dimensions.

Here is what it looks like in the editor: https://imgur.com/a/aM8esW8
User avatar
Cherno
Posts: 1309
Joined: Tue Dec 06, 2016 11:25 am

Re: 3D model collision

Post by Cherno »

A voxel-hit-bostyle approach might seem like a good solution at first glance but I dont't think it's viable in pratice. The can be only very limited greedy meshing which means the amount of hitboxes per actor will still affect overall performance tremendously. What I have done for things like rectangular mesh-based actors is to manually add hitboxes exactly where they are needed, ensuring that I only use as little as neccessary.
User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: 3D model collision

Post by Rachael »

I think this has been brought up before, and the answer was no. Mostly because of the insane amount of processing power this would require.
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: 3D model collision

Post by Graf Zahl »

Mostly because this does not integrate at all with how Doom's movement code works. And surely you also need a simplified collision model to not make the computer explode.
User avatar
Nash
 
 
Posts: 17434
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia
Contact:

Re: 3D model collision

Post by Nash »

Even modern game engines like Unreal Engine 4 don't do full mesh collision - you have to construct a separate, (very) low poly collision mesh. Assuming someone implements the work needed to make this work (which has already been explained - not trivial at all because Doom's movement code is too primitive), it would most likely not work automatically and the content author has to do the collision meshes themselves.

Given the current limitations of the [GZ]Doom engine, the best option you have today (one that doesn't explode the processing cost from too many actors, and works the nicest within the engine's limitations) is to construct invisible 3D floors to act as your "collision mesh".
User avatar
Enjay
 
 
Posts: 26517
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland
Contact:

Re: 3D model collision

Post by Enjay »

Yes, for static items, like rocks or parked vehicles, that's what I do: use invisible map geometry (either 3D floors or sectors hidden using transfer heights) and invisible bridge things to provide the collision for the model.

It can be fiddly and time consuming to set up, but it works. At least with GZDB being able to show the model mesh in the editor, you can see precisely where the model will appear and you can draw your geometry exactly where it needs to be.
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: 3D model collision

Post by Darkcrafter »

Rachael wrote:I think this has been brought up before, and the answer was no. Mostly because of the insane amount of processing power this would require.
Yes, it's been there around zscript board, but now it's here officialy.
Nash wrote:Even modern game engines like Unreal Engine 4 don't do full mesh collision - you have to construct a separate, (very) low poly collision mesh. Assuming someone implements the work needed to make this work (which has already been explained - not trivial at all because Doom's movement code is too primitive), it would most likely not work automatically and the content author has to do the collision meshes themselves.

Given the current limitations of the [GZ]Doom engine, the best option you have today (one that doesn't explode the processing cost from too many actors, and works the nicest within the engine's limitations) is to construct invisible 3D floors to act as your "collision mesh".
The process of making those meshes is not a thing an artist would afraid of, but this movement code doom has. It really can be hard for an average hardware, but I hope this will be the problem of past soon, as there is finally competition on the cpu market again. By the way it's not about UE4 but seems like Unity supports not just low poly collision meshes, but very hi-res ones. Another problem is that the collision detection alghorithm sometimes fails, for instance it might close holes that are supposed to be open like caves: https://youtu.be/46hSbkTuHmc?t=208

I'm gonna create a special map with thousands of such collision boxes and see how it affects the performance on a 1st gen ryzen pc from 2017 and amd athlon from 2006 and make a report on it, but now with 2160 thinkers, the think time is just 0.94ms (ryzen). Maybe having that much of actors is not such a big issue for a modern system?

The more I map the more it seems to me that there is no such thing like a "best option". There are multiple scenarios that require different approaches, for an instance there is a lot of hassle with configuring them and if there is a sloped terrain one have to deal with drawing complicated linedef patterns whereas a simple decorate based actor that hovers above it in a desired position solves the problem effectively, there is no need to redraw the map geometry that is already so complex. Configuring a 3d floor to become sloped is also another problem, what if your 3d model is curvy and it would a huge pain in somewhere to create all these sectors to approximately describe a surface, then you can't move, scale and rotate your geometry without breaking it.
SanyaWaffles
Posts: 800
Joined: Thu Apr 25, 2013 12:21 pm
Preferred Pronouns: They/Them
Operating System Version (Optional): Windows 11 for the Motorola Powerstack II
Graphics Processor: nVidia with Vulkan support
Location: The Corn Fields
Contact:

Re: 3D model collision

Post by SanyaWaffles »

I had this problem with some props in my project. I decided to use 3D floors to roughly approximate a better collision bounds. I wanted something that was shootable but not "destroyable" and something with
a more cylindrical based hitbox.

It was the cleanest option for me at the time.

You'd be right on there being "no best option". I think using an engine like GZDoom there's going to be certain limitations we're gonna have to be creative to work around. However this can be fun in and of itself - every engine is gonna have limitations you gotta be creative with.
Gez
 
 
Posts: 17833
Joined: Fri Jul 06, 2007 3:22 pm

Re: 3D model collision

Post by Gez »

I believe a while ago someone hacked in a ZScript-based 3D collision box for models by overriding CanCollideWith. It's not really the kind of things you can use often if you care about performances, though.
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: 3D model collision

Post by Darkcrafter »

Turns out it's possible with GZDoom, too some degree, I had this pk3 file somewhere it has a 3d modeled house and bridge, it worked fast but collision doesn't work properly where two different meshes meet and intersect, spawning this model actor is not trivial at all, e.g it can't be done strictly by coding an actor in decorate and in modeldef.
Post Reply

Return to “Closed Feature Suggestions [GZDoom]”