Is there a version of "in_solid" or "c_content" for meshes?

Hi all.

Seeing as in_solid and c_content are only applicable to WED blocks, does anyone know
of a way of achieving the same results with pure entity to entity collisions...

Not ACTUALLY collisions BTW.
Im trying to detect if a spawned entity is completely 'within' another.
That is using fully polygon detection on closed-mesh entities,
and I want to know if entity-A is 'inside' entity-B, or at least if
entity-A is inside 'something', without actually moving it at all.
And I need it to still detect true even if there are no polygons intersecting between the entities.

Any ideas on concepts, snippets, or theories anyone ?

Thanks all...

c_intersect with bounding boxes.

No luck.... c_intersect is A8 only, and I need polygon-accurate detection, not boxes.

NEXT...!

do a c_trace from the model origin to the model origin, that's how I do in my project to check if the player is underwater

sorry painkiller, thats no good either.

The model Im looking to be inside of is usually a complex shape,
so its origin is not guarenteed to be 'inside' the mesh...

Next...!

For that kind of thing you'll certainly need to write your own function that cycles through the vertices of two objects. Per polygon can be slow as it is, but the fact that polygons might not even intersect (one object completely within another, as you mentioned) is killer. If both objects are convex or you can reduce them to be composed of convex parts, you could use a simplified version of the Gilbert-Johnson-Keerthi distance algorithm. Even then, you'd want them to be fairly low-poly, assuming you want to perform this calculation every frame.

I have a couple of ideas in the back of my mind that might bear fruit if we know more about what kind of situation you're dealing with, and how much control you have over it.

Jibb

I suspected (bordering on certainty) that I would need my own function for this.
Im more after ideas rather than solutions...
The one object completely inside another is ONE killer, there is also the fact
that the 'large' object is not only NOT-convex, it may be comprised of several
separate closed-meshes... Read on for more details...


I'll fill you in a bit more where I can, as much of the actual usage is secret(for now).

Simplistically, this is for a TOOL that calculate the "actual" volume of a user-supplied model(MDL),
as well monitor/calculate its mass-distribution based on the models shape.
("actual" as in 'as close as I can get'...)

FPS is not too big of an issue(within limits). This is a "process" that is expected to
take several seconds to complete, not run every frame.
ATM I use c_rotate and the process can take up to 2 minsto process a complex model... (on a crappy PC)
(FYI: the c_rotate process is seriously flawed, but it is the best result I can get so far,
moving a CUBE_MDL through the entire models bounding-box and c_rotating to see
if it intersects anything. This is still only giving me locations of intersections though...)

Seeing as the user is supplying the model at run-time, Ive got no control over that.
It could be a simple cube, but most likely a complex shape like a humanoid...
Im currently not allowing for animations, as the tools output is only applicable
to static objects...

Thats all the useful info I can think of for now...

maybee that can help:
Make a c_trace from your entity witch you want to test to lets say 1000 above this entity. If the return parameter is negative, so the trace hits a polygon from behind and you stay in this model.

Nice try Widi, but I cant seem to get that to work...
I CANNOT get ANY c_trace's to hit the inside of the polygons for some reason...

I tried a few hours ago and the traces pass straight through...

Heres how I was testing it...

I tried it with various combinations of mode flags and so forth,
but never got it to detect hitting the 'red' cube...
(yes I tried without using the LIGHT flag...)

If you can spot whats wrong I would be grateful...
Im suffering lots of mental 'blanks' lately... I know this USED to work...


FYI Im using A7.86.0 commercial

I've liked and used this behaviour on prior versions, too, but it has been removed. As EvilSOB said, the trace simply passes through the polygon now.

I have this solution from the manual, never tried it by myself.

what?
why was it removed?
It would've been my approach as well.
Evilsob, have you asked the developers about this? if they remove the function, there must be an alternative?
and not only in A8...?

Okay, so the small mesh is a cube of whatever unit-size you're using to measure volume, right? And you'll basically check a 3D grid of these cubes against the object you're considering?

Here's a bit of a thought: You have a 3D-array of bits (inside and outside), all set to "outside" (0 or 1, doesn't really matter). Go through the vertices of the big model, and at each one find the nearest point in the array behind the normal. Set it to "inside", and put the indices of each of those "inside" bits in a list. For the next stage you'll repeatedly go through the list, and each point will run a function for each of its "children", where each child is an "outside" bit adjacent to this point, that goes through all the polygons in the big mesh and sees if any of them separate a child from its parent. If none separate the child from its parent, the child is set to "inside" and added to the list. When each "parent" is done, it is removed from the list. This is repeated until the list is empty -- that is, no more points have access to empty points.

You now have a volumetric representation of the mesh (which most be closed, obviously, for this to work). For each bit you add, also increase a counter by 1 to get instant access to the volume of the mesh.

Something like a sword with polygons pressed up against each other could be trouble -- you could end up with an outside bit being called "inside", and that means everything will be considered inside. To prevent this, for each bit you set to "inside" in the first stage, first make sure it isn't right in front of the normal of any polygons in the mesh.

I hope that makes sense, and I haven't overlooked something silly

Jibb

maby you can use D3DXIntersect its only not inserted inside d3d9.h so you would need to add it yourself and dont know if you can us it in gs

its just a idea

Sorry bout the delay in my responses, but christmas and all, y'know?

Widi: Thats cool, cause the manual still 'suggests' that it is possible. (grrr)

Germanukol: I probably will try Developers later.

JulzMighty: I was thinking the same concept myself, but Im more focussed on getting
the actual "edge"-detection sorted out first, as the 'fill' process may flow on from that...

flits: D3DXIntersect is basically useless to me dude, as it is testing a RAY intersecting a mesh...
BUT thanks anyway, your suggestion has inspired me to do a bit of research into 'mesh to mesh'
intersection techniques performed at a D3D-level, I didnt think of going there.
(It doesnt matter about if they are included or not, Ive accessed
non-included D3D functions before, so it will be do-able)


I am still going to stay open to further suggestions and/or ideas, but this issue
is now pushed to a lower priority as I want to get the rest of the programs interfaces
completed before I forget them, as theres a lot still only exists in my head,
and I want to put them into code before their architecture falls out my ears...


FYI: Merry Christmas and Happy New Year to all...