Last minute API additions for Gthree

[ebassi]

Gthree has some in tree functionality that really belongs to Graphene.

Proposed changes:

• add graphene_triangle_init_from_float() initializer; this is useful for buffer objects with lots of triangles stored as vectors of floating point values
• add intersection methods for graphene_ray_t; this is used for hit testing objects like spheres, boxes, and triangles
• add graphene_triangle_get_uv()

[ebassi]

Would be nice if @alexlarsson could do a review so I can merge it in time for next week's GNOME 3.34.0 release.

[alexlarsson]

So, this looks overall good to me, but there is something weird with the triangle intersection kind.
I ported gthree to use this new API here:
https://github.com/alexlarsson/gthree/tree/use-graphene-intersection

However, with this PR as-is, it gets the tri intersection kind wrong here: https://github.com/alexlarsson/gthree/blob/use-graphene-intersection/gthree/gthreemesh.c#L217 as can be seen in the interactive demo. If i switch SIDE_FRONT/BACK around it works, but otherwise it doesn't.

The fix for this is to switch the two kinds in intersect_triangle like so:

diff --git a/src/graphene-ray.c b/src/graphene-ray.c
index 56bc051..b0bf411 100644
--- a/src/graphene-ray.c
+++ b/src/graphene-ray.c
@@ -661,13 +661,13 @@ graphene_ray_intersect_triangle (const graphene_ray_t      *r,
     }
   else if (DdN > 0)
     {
-      kind = GRAPHENE_RAY_INTERSECTION_KIND_ENTER;
+      kind = GRAPHENE_RAY_INTERSECTION_KIND_LEAVE;
       sign = 1.f;
 
     }
   else
     {
-      kind = GRAPHENE_RAY_INTERSECTION_KIND_LEAVE;
+      kind = GRAPHENE_RAY_INTERSECTION_KIND_ENTER;
       sign = -1.f;
       DdN = -DdN;
     }

This actually matches what three.js does here:

https://github.com/alexlarsson/gthree/blob/use-graphene-intersection/gthree/gthreemesh.c#L217

Where if DdN > 0 and we're backface culling then we have no intersection, which totally smells like a LEAVE kind of intersection to me.

This was actually how I coded the gthree version of the intersector initially, but I had to switch it around to make the code work. Reverting this to what three.js does is nice, but I don't understand what the difference is. Why did I have to revert it to make the previous version in gthree code work???

[alexlarsson]

Ah, i found the difference:

-  kind = ray_intersect_triangle (local_ray, vC, vB, vA, &t);
+  kind = graphene_ray_intersect_triangle (local_ray, triangle, &t);

I.e. the old gthree code passed the vertices in the wrong order, effectively flipping the triangle.

So, the patch about is right and should be applied.

[alexlarsson]

So, this looks good. I thought there were some issue with the sign of the v coord initially, but that was just due to some weirdness in how the graphene box primitive sets up the uv coords.