Jump to content

  • Log In with Google      Sign In   
  • Create Account

Defend

Member Since 10 Jun 2004
Offline Last Active Today, 12:25 AM

Posts I've Made

In Topic: Finding usable normals from complex embedded sphere-tri situations. Try to po...

Yesterday, 12:54 AM

 

 

By all means, if there's some real-life justification I'm missing that could convince a user one way is more "correct", I would be happy to hear it.

That justifacation is easy to make:

In physics, either you do it correctly and it will work, or it will fail (jitter, tunneling) - there is not much space in between.

 

That's why I am pointing out that this isn't using physics any more than the moving portal uses physics. The reason there's next to no confusion between working and failing when simulating actual physics is that we simply have reality to give us validation. We don't have that here. Reality won't validate any behaviour you might give to a bowling ball and a diamond slab that occupy the same space at the same time, any more than it will validate ways to push a box through a moving portal.

 

So what validation are you using? You are claiming that one particular behaviour (defining a collision normal the way you do) is validated; is simply the "accurate" behaviour. What causes you to believe this?

 

Meanwhile I think it's easy to argue that the goals of behaviour of unreal situations are at the developer's whim. That's why I'm skeptical. I need to see something that shows why this situation shouldn't fall into the same category as moving portals, jelly blocks in Minecraft, or surfing in Team Fortress 2; the category of behaviour goals for unreal situations that the developer invents because that's what the developer likes.

 

---

 

Regarding the image, thanks for giving it a look. 

I see it hitting 1 "edge" (the top corner) and 1 face (the bottom line). You have called this less satisfying, but I am not sure you're saying that because of that example, or just your general opinion. In that example I am perfectly satisfied with that result. That's what the OP was all about: find any example that doesn't give a satisfying set of normals. 

 

Importantly, bear in mind that we need all those individual normals for restricting sliding motion; that is unavoidable. Regardless of whether we desire a collision normal or not, we aren't saved from having to calculate those sliding planes; we absolutely need them. I believe then that the only thing your approach saves us from is 3 lines of code that find a simple average. Compare those 3 lines to your code; altered for 3D, then altered further to handle completely arbitrary shapes instead of cubes.

 

For all that extra complication, if one is to claim that this is in fact the way things should be done, then something needs to validate that claim that isn't just personal preference. 

 

These are my personal preference factors for the averaging approach (unless my approach breaks somewhere):

 * the collision normal comes from the surfaces involved, not the depth.

 * I don't want penetration slightly altering collision normals,

 * The player will know that the planes along which they feel movement being blocked are going to define their jump, and they can predict this jump by feel, without having to look at the ground.

* Collision normals that match those of the equivalent non-embedded situation (as in the 3 examples shown earlier)

* A character embedded deep in the ground, but only a tiny bit in the wall, will kick off the wall as effectively as a character only touching the ground and only touching the wall.

 

Both our approaches are consistent, predictable, and have something that the player can pick up intuitively, but I wouldn't call yours or mine "the" way it is supposed to be done.... unless I hear of something that supports that claim. Currently I would be comfortable writing in a guide "If you want depth to affect your collision normal as well, here's an approach for that." 


In Topic: Finding usable normals from complex embedded sphere-tri situations. Try to po...

07 February 2016 - 08:54 AM

I don't want to just poop on that idea, but I think that calculating the centres of possibly quite complex shapes, multiple times per frame, is kind of bordering on overkill. It's not that it's complicated (it is though), it's that it's complicated without something in reality to justify the approach. If it were based on a real-life physics situation then I would embrace any complications required to do things the "correct" way, but I don't believe there is one correct way, no more than there is a correct way to solve the moving portal problem. 

 

http://9gag.com/gag/adj90GB/moving-portal-problem

 
If the developers had done it one way, players would have said "Yeah, that feels right."
If the developers had done it the other way, players would have said "Yeah, that feels right."
And people argue both ways using classical physics until the cows come home.

 

Since tennis balls don't slide around inside bricks in real life, if someone were to put volume centre calculation in a guide, readers would question its justification. 

 

So in my opinion the goal is just something that feels consistent and acceptable to the user, but from there I say the developer really has free reign. Averaging, weighting, penetration depths, volume centres... they're all going to give a normal of some kind, and all can feel fine.

 

Personally, averaging is fine to me for what I have in mind. I don't find value in embedded situations giving different results to their non-embedded equivalents, nor in asking the user to factor in penetration when trying to intuit the direction they're going to jump in. But maybe you do. Perhaps you're imagining a scenario where penetration definitely *will* factor into the users intuition. And that's cool too. (But on that note, I don't think your volume-centering idea gives anything to the user that the weighting/penetrating idea didn't already.)

 

By all means, if there's some real-life justification I'm missing that could convince a user one way is more "correct", I would be happy to hear it. 

 

 

The discussion on what to do with normals is welcome; it's making me think. As long as the thread's topic of how to select them does also get closer to closure. And possibly it has now, because you actually seem quite confident about the normal selection process. We describe it with different language (you say Voroni, I say "hey guys I've got this 7 step diet routine") but it looks like we are thinking the same way.

 

The image I posted last (the pyramid) actually produces an edge normal, but I think you called vertex not because we disagree, but simply because the image isn't clear. I tried to find good angles, but looks like I failed hehe. Here it is again, new angle. 

 

Attached File  Pyramid2.png   455.41KB   0 downloads

 

So edge, yeah? Between the purple and blue.

 

 

A final one, if you want, about selecting normals:

 

Attached File  Contrived.png   8.38KB   0 downloads


In Topic: Finding usable normals from complex embedded sphere-tri situations. Try to po...

06 February 2016 - 03:01 PM

Rejecting some normals and averaging the rest sounds no good idea, instead you should weight the normals in a way that the resulting normal has no abrupt changes when the moving sphere enters an additional region.

 

I don't think that makes it a bad idea, because the abrupt changes are no more abrupt than changes in mesh itself. It seems odd to fear sudden changes in incline while embedded, when they're already fine while not embedded (such as if example 1, realistic situation, were to travel to the right) if that is simply what the mesh dictates.

 

I'm not eager to smooth over all non-embedded changes in direction. I prefer the collision response to be as sharp as the mesh. That said, the way you suggest weighting things is a good idea I'd surely use if I feel differently about smoothing later. 

 

To clarify something also, I wouldn't be averaging anything for moving through the mesh. I would be restricting to all valid sliding planes found (ie., using all selected normals). Averaging was what I suggested for things like jumping off of it.

 

 

And just making it explicit again, the topic is about asking "how to select normals", not "what do I do with normals once selected". I'm not sure if you've noticed, but your suggestion also rejected normals, and we happen to have agreed on which ones. It could be that you're only thinking in terms of face normals, so you have rejected an embedded *edge collision's* normal intuitively. In Example 1 we've both ignored the edge intersection (the bottom corner, since the image is in 2D) that the right-hand triangle would register.

 

That's the kind of thing I'm actually looking for agreement/disagreement with in this thread.

 

In case that is confusing ("Why would the right-hand triangle register an edge intersection?"), it's because the collision detection algorithm checks triangles one by one.

 

But those 3 examples are only simple ones. Here is an example that has no face intersections: 

 

Attached File  Pyramid.png   485.36KB   0 downloads

 

The orange lines are simply guidelines displaying extrusions of each tri's face along its normal, to show more clearly that the sphere's centre does not project onto any face.

 

The question continues to be: Which normals would you choose, and is there any problem in the process I wrote for selecting them?

 

 

Finally the collision can be resolved by projecting the sphere along collision normal so it does not intersect any involved mesh elements.

 

Actually the whole goal of this is to have no such collision resolution trying to put the sphere "on" a surface. If the sphere is embedded, it stays embedded and moves just as comfortably as a non-embedded sphere. Besides, as you mentioned, cheeky displacements like that are just asking for trouble. 


In Topic: Finding usable normals from complex embedded sphere-tri situations. Try to po...

06 February 2016 - 01:50 AM

Hmm after a quick read this seems to be a different thing. Probably because my opening post was rushed, so I didn't spell out exactly what I do and don't have already. 

 

Finding the closest point on any triangle is something I already assume is done. Convex, concave, it doesn't matter.

 

The task that I think I have solved, and am asking for comments on, is to devise an algorithm that knows which normals to accept, and which normals to ignore, from the set of closest points found in any given embedded situtation. An embedded situation can involve multiple tris, and thus, multiple collision normals, some of which should be ignored.


In Topic: Finding usable normals from complex embedded sphere-tri situations. Try to po...

06 February 2016 - 12:03 AM

Thanks for those terms, I'll look them up. That's really helpful. 

 

Regarding crossing surfaces, part of the process of ignoring back-facing collisions is ignoring the tri completely once the sphere's centre goes behind its surface. So I believe that situation is ok. 

 

I'm not sure why you say convex though... my examples are concave. Perhaps I should have made it clearer in the images. The black lines are facing up... as if they're the ground.

 

Regarding finding closest features between a point and a polyhedra, that is something I am already able to do, convex or concave.


PARTNERS