Sounds mad indeed.

Have you tried it in real code yet?

You would probably want to avoid heavy use od divisions because they're very costly in terms of cpu cycles.

I don't know if this approach works for games though...

I don't think that anything with "evaluate the integral" in it has a realistic chance of working as a collision system (unless the curve is a particular special case for which you can hardcode an easy closed form solution).

Usually you want something that works realtime or at least kind-of-realtime, and the algorithm is invoked for a few hundred or thousand objects. Evaluating a few thousand integrals of "some" function isn't precisely a lightweight operation. Of course, there may be cases where you simply don't care how long it takes...

I have a figure which is given by array of triangles and I have couple of points that i know for sure that they are inside my figure and I have my testing point. I build a plane with these three points.

You can use LaTeX here. Just enclose your code in \ ( and \ ) (without the spaces) for inline math, and \ [ and \ ] for display math. For instance \( \int_0^\infty e^x ~ \mathrm{d} x \).

Seems to me that you don't really need to compute the full path integral, since you only require its sign. You can do much better. If your curve/surface is closed and bounded you can use the even-odd theorem, which basically says that if you draw a ray from your point to infinity in any direction, the point is inside the curve if and only if it intersects the curve an odd number of times. This rule works for any (nondegenerate) curve or surface, convex or not. Note this is an if and only if condition, so one ray is enough to decide (and, in fact, it is transitive, in the sense that if the segment between point X and point Y has an even number of intersections, then X and Y are both inside or both outside). This is really just evaluating the sign of the aforementioned path integral, but much easier to implement because it doesn't require the concept of an integral and transforms the problem into a ray-surface intersection problem for which efficient solutions are known.

If your curve is simple, you can probably intersect it analytically with a line. If it is sufficiently well-behaved and you have a scalar field of it available, like in your first post, you can bisect to find intersections, which is at least tractable, if not terribly efficient. Otherwise, you can always raycast or raymarch, possibly using an acceleration structure. In practice, faster algorithms are used for the broad phase, while more sophisticated algorithms are used to resolve collisions accurately between polygons (narrow phase) often by splitting them into convex polygons beforehand.