MD3-based collision support via ZScript

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!)

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: MD3-based collision support via ZScript

Re: MD3-based collision support via ZScript

by Darkcrafter » Wed Jun 29, 2022 5:22 pm

I think this script will charm for fake terrain the most. Some layered 3D geometry without spamming the basic level geometry is also geating possible then, if only that script would automatically engage via modeldef definition or some flag in a map editor, so we could simply decorate the maps with fancy modeled stuff without need to definie it all through defining a new class. It's not perfect yet there is some use for it definitely. Fake terrain without spoiling the basic level geometry. Would go well with hell maps to reduce ugly boxy shaped stones and rocks. Good job.

Re: MD3-based collision support via ZScript

by ramon.dexter » Mon May 16, 2022 7:17 am

This would be a lovable feature, if it was built inside gzdoom. After all, we have model support, so we should have some kind of collision, instead of the basic boxes...

Re: MD3-based collision support via ZScript

by ZZYZX » Fri May 13, 2022 6:27 pm

Found a way to fix the issue that I had with narrow angles with infinite bumping and/or noclipping into polygons that face each other.

New download: https://www.mediafire.com/file/ycggvsx6 ... 2.pk3/file

The fix idea was actually provided by this guy, I only did the implementation :p

Re: MD3-based collision support via ZScript

by The_Abysswalker » Mon Dec 06, 2021 11:09 am

Any way to adapt this to .obj format?

Re: MD3-based collision support via ZScript

by Darkcrafter » Fri Apr 17, 2020 6:35 am

Make sure your 3D model for collision is 100% manifold! If it's not then you only can draw a new one that would be a coarse approximation of your model or use meshlab: remeshing -> convex hull.

Re: MD3-based collision support via ZScript

by TDRR » Sun Aug 04, 2019 5:39 pm

Deybar_TECH wrote:well I think I didn't think much about the slowdown.
but really my game needs a good aesthetic, use real-life models. like the ones it offers (google earth). and I think that until (* zdoom) doesn't improve its collision system, I won't be able to take advantage of that feature as it should.


TDRR wrote:So, anyone has any idea why this model doesn't have collision?

experimenting with this code I found that the model needs to have the properties (height & radius) surrounding the entire model in addition to retaining its (scale: 1.0). and the 3D model in (modeldef) has to cope with the scale in the code (zscript) and you don't have to use flags like: (NOINTERACTION, THRUACTORS) for the collision to really work.

te respondo en idioma ingles para que los demás puedan entender. :lol:
I already tried this and it didn't work. I even tried to set Radius and Height to 32767 which didn't work either. I'm stumped, another SM64 model import works just fine (But with messed up textures) yet it has full collision.

Re: MD3-based collision support via ZScript

by Deybar_TECH » Sun Aug 04, 2019 2:29 pm

well I think I didn't think much about the slowdown.
but really my game needs a good aesthetic, use real-life models. like the ones it offers (google earth). and I think that until (* zdoom) doesn't improve its collision system, I won't be able to take advantage of that feature as it should.


TDRR wrote:So, anyone has any idea why this model doesn't have collision?

experimenting with this code I found that the model needs to have the properties (height & radius) surrounding the entire model in addition to retaining its (scale: 1.0). and the 3D model in (modeldef) has to cope with the scale in the code (zscript) and you don't have to use flags like: (NOINTERACTION, THRUACTORS) for the collision to really work.

te respondo en idioma ingles para que los demás puedan entender. :lol:

Re: MD3-based collision support via ZScript

by TDRR » Sat Aug 03, 2019 10:16 pm

So, anyone has any idea why this model doesn't have collision?
https://www.mediafire.com/file/6ipdq47g ... n.pk3/file

It's an import of the garden in the observatory of Super Mario Galaxy 1. I repeated the exact same process i did for a SM64 map import and it worked very well, but this simply has no collision at all.

Some of the textures are wrong but it's as good as i could get them from memory and it's been a long time since i last played SMG1.

Re: MD3-based collision support via ZScript

by TDRR » Sat Aug 03, 2019 5:33 pm

Deybar_TECH wrote:Hi, I'm interested in using this model detector in my project since I want to use 3D models and textures
realistic from (Google Earth) and I don't want to try to transfer/convert the model geometry to
(Universal Doom Map Format/UDMF) in some map editor.

the credits will be for (ZZYZX). :wink:
Just to let you know, that would cause large slowdown with many models. (More than 10 i imagine already slows down a lot
EDIT: Maybe not that low amount of models, but since you are doing a flight simulator i think you are going to place many of them and anyways the way the collision works is not really appropiate for a flight simulator. Your plane would slide along the walls of a model or just flat out get stuck in it if the model you are going to use has lots of complex geometry.

Use MODELDEF, a DECORATE actor and use 3D floors to make fake collision with it.

Re: MD3-based collision support via ZScript

by Deybar_TECH » Sat Aug 03, 2019 3:06 pm

Hi, I'm interested in using this model detector in my project since I want to use 3D models and textures
realistic from (Google Earth) and I don't want to try to transfer/convert the model geometry to
(Universal Doom Map Format/UDMF) in some map editor.

the credits will be for (ZZYZX). :wink:

Re: MD3-based collision support via ZScript

by ketmar » Wed May 15, 2019 4:01 pm

yeah. i alredy tried several solutions to this (as i REALLY want to unify the code), but i think that in the end i'll leave 2d `traceBox()` alone, and will do 3d (vertical movement, i mean) as a separate step, and then will try to somehow blend them together.

Re: MD3-based collision support via ZScript

by Graf Zahl » Wed May 15, 2019 3:47 pm

ketmar wrote:still, physics problems are imminent. doom does its movement in two separate steps: first strictly XY, then vertical. this is a freakin' PITA for true 3d collisions, and a source of major problems in my current attempts to replace coldet code.
This is the biggest fuckup in the entire Doom movement code and the source of endless problems with movement precision.
Another is that the entire movement code is essentially 2D with the z-component as a sloppily handled afterthought, not an integral dimension.

In fact, a lot of this looks like it has been ripped right out of a 2D engine and quickly hacked to work for Doom.

Re: MD3-based collision support via ZScript

by ketmar » Wed May 15, 2019 2:15 pm

still, physics problems are imminent. doom does its movement in two separate steps: first strictly XY, then vertical. this is a freakin' PITA for true 3d collisions, and a source of major problems in my current attempts to replace coldet code. you cannot just add gravity to your velocity vector and call `P_SlideMove()` anymore, you have to do it in two separate steps. yet you can't just omit floor and ceiling checks, because of slopes (and 3d floors). also, Doomguy is usually standing inside a floor, not "on" it, which doesn't help also (and it cannot be changed, as alot of code does checks like "mobj->Origin.z == floor.z").

now just imagine that you have to marry "microteleportation"-based original coldet, and CCD... my "x6" estimation was prolly too optimistic. ;-)

p.s.: "first strictly XY, then vertical" -- now, this is a lie too. it is even more complicated than that.

Re: MD3-based collision support via ZScript

by Graf Zahl » Wed May 15, 2019 1:47 pm

ZZYZX wrote:
ketmar wrote: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.
You probably need to understand that this was mainly so that I can make stuff like 3d pipes hanging from the ceiling and having collision automatically. Or for me to be able to model stalactites/stalagmites/small lava craters in a cave and have a nice texture on them. It was not so that whole level can be constructed of 3D models.
So yea if it didn't have weird logic issues, I would use it in mapping (and would suggest using it to people who are also using 3D objects as an addition to a regular map).

Even then it would have been better to do it as a C++ extension in the engine and not as a scripted mod so that it could have been turned into a usable feature for everybody.

Re: MD3-based collision support via ZScript

by ketmar » Wed May 15, 2019 1:25 pm

@ZZYZX: and i am not talking about turning the whole game into triangle soup too. what i am talking about is fast and robust (both things matters) collision system, that works seamlessly with doom quirky physics and movement. impossible task. besides that, alias models are badly suited to work as collision meshes, but this is another story.

>I'm treating triangles as something that has 5 planes, not sure what 10 are for.
for robust "swept AABB vs triangle" collision check. to find real collision plane and normal, you have to do raycast instead of "AABB cast". and to do raycast, you need to shift planes, effectively doing minkowski sum of triangle and AABB. and to make that work, you need your inflated brush to include both AABB and triangle points. and to do that, in turn, you need to cap your triangle with axial planes on each vertex. after such capping you can safely perform raycast against a triangle, and your AABB will never miss it, and will never hit an empty space. in exchange you're getting stable, robust, and error-free collision system, and your sliding code becomes a trivial thing, operating on planes returned from sweep test.

(p.s.: this is that "beveling" i kept talking about. for AABB, it is enough to cap your brush; for spheres, you need to "bevel" them. as capping can be seen as a special case of beveling, i kept calling it all "beveling". ;-)

>Currently the most practical way of getting collision on "static" meshes in
>GZDoom is by enclosing them with invisible 3D floors. Anything else is just too
>cumbersome to setup and more importantly would scale poorly in terms of
>performance.

that is what i going to say too.

Top