3D model collision

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is OFF
Smilies are ON

Topic review
   

Expand view Topic review: 3D model collision

Re: 3D model collision

by Darkcrafter » Wed Oct 16, 2019 1:19 pm

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.

Re: 3D model collision

by Gez » Wed Oct 16, 2019 2:29 am

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.

Re: 3D model collision

by SanyaWaffles » Wed Oct 16, 2019 12:53 am

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.

Re: 3D model collision

by Darkcrafter » Sun Oct 13, 2019 3:07 pm

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.

Re: 3D model collision

by Enjay » Sun Oct 13, 2019 1:35 am

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.

Re: 3D model collision

by Nash » Sun Oct 13, 2019 1:23 am

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".

Re: 3D model collision

by Graf Zahl » Sat Oct 12, 2019 11:54 pm

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.

Re: 3D model collision

by Rachael » Sat Oct 12, 2019 6:24 pm

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.

Re: 3D model collision

by Cherno » Sat Oct 12, 2019 4:09 pm

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.

3D model collision

by Darkcrafter » Sat Oct 12, 2019 3:06 pm

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

Top