Ray.intersectObject doesn't seem to work on non-planar quads

[kig]

The intersectObject code should split non-planar Face4s into two Face3s.

https://github.com/mrdoob/three.js/blob/master/src/core/Ray.js

[WestLangley]

This is a known issue. See #1256 for the cause and a work-around.

[kig]

Thank you very much, that's perfect!

[mrdoob]

As far as I understand it, the problem is basically about normals. Right now we use the normal of the face for the first part of the Ray checks. But a Face4 should have 2 normals in order for this to work without having to recompute the normal for every check.

I can't think of a nice way to solve this. Maybe the triangulation is a good solution for this?

[bhouston]

This should be closed as "won't fix." Quads in a mesh are invalid if they are not planar. If they are not planar, it should be two separate triangles otherwise it is considered an invalid mesh.

[mrdoob]

Oh. That's interesting.

[WestLangley]

Quads in a mesh are invalid if they are not planar. If they are not planar, ... it is considered an invalid mesh.

If this statement is true, then due to round-off error, almost all quads are non-planar, and hence almost all meshes containing quads are invalid.

Do we want to make it our policy that a mesh having a quad that is non-planar (outside of round-off error) is "invalid"?

[bhouston]

@WestLangley asked "Do we want to make it our policy that a mesh having a quad that is non-planar (outside of round-off error) is "invalid"?

I think that is generally the case isn't it? Quads have ambiguous triangulations and if a Quad is non-planar than the result can be dramatically different depending on the triangulation scheme. I guess I am used to Polygon Meshes where you can assume that each face is planar. Many things like a face normal do not make sense on non-planar quads. If a face isn't planar it should be split into two or more faces each of which are planar themselves (within a tolerance because you are right there is always floating point error.)

[WestLangley]

Yes, I am aware of the issues with non-planar quads. I was asking a policy question.

If our policy is non-planar quads are "invalid", then we need to be careful in our own examples not to generate any -- for example, in dynamic terrains.

If non-planar quads are valid for us, then perhaps we should revisit all the unresolved related issues, and try to deal with them -- like this one.

[bhouston]

I think it should be policy that non-planar quads are invalid. Yes we can of course deal with them but it will be costly in terms of code and speed.

My suggestion is that dealing with this is generally a preprocessor step rather than within the engine itself. We could write one function on GeometryUtils that converts bad quads into triangles and people can use that to preprocess their meshes.