Ok, here's a tricky one for all you math / mesh wizards out there. My brain has been in a continuous loop for the past couple of days trying to sort this out, but I don't think my math is up to the task. I'm hoping someone here will be able to help me out or at least steer me in the right direction!
Here's the problem. I have 2 or more simple meshes that I'm creating on the fly. They only need to be flat triangles with no real 3d depth. As I do this, or after I do this, I need to determine whether or not they overlap, and if they do, I need to create a separate mesh that exactly matches their intersection. (this is so that I can handle that intersected area differently visually and computationally).
I've considered 2 possible approaches to this, but both have their difficulties and challenges.
1. The first approach i've considered is giving the meshes a little depth and then linepicking extensively from where the meshes are originating from to try to find the points where it collides with the other mesh, record these and then try to build a mesh out of them. 2 things make this really difficult -- I have to also linepick backwards towards the original object to find the end of the intersection, and i think that it will be very challenging to build the mesh correctly once i've found the intersection points (not sure how to organize all those points so that i can connect them right).
2. The second approach i've considered is to try to do some old-fashioned 2d wizardry, rendering the scene to image buffers and trying to figure out the intersections based on colors. If I were to render the scene top-down I could pretty easily show the intersections in a different color (by making the meshes additive), but once i've done that, it seems like i'll be stuck doing a whole mess of "readpixelfast"s which will be slow. Once I finished that, I could presumably place the result in a texture and give the UV coords to make it overlay the meshes correctly, though, which would be pretty simple.
So does anyone have suggestions for either approach?
If I go with the mesh way, is there a way to evaluate these intersections without all the linepicking? (i guess with straight up math?) Or is there some other method that I'm missing?
If I go with the second method, is there a way that I could evaluate the colors of the image / intersecting areas without reading every pixel to test its color? Maybe using images as textures overlaying one another? I am afraid I am out of my depth :)
Ok, I think I'll shut up now. Please let me know if you have any questions or suggestions!
cheers,
roland
Here's the problem. I have 2 or more simple meshes that I'm creating on the fly. They only need to be flat triangles with no real 3d depth. As I do this, or after I do this, I need to determine whether or not they overlap, and if they do, I need to create a separate mesh that exactly matches their intersection. (this is so that I can handle that intersected area differently visually and computationally).
I've considered 2 possible approaches to this, but both have their difficulties and challenges.
1. The first approach i've considered is giving the meshes a little depth and then linepicking extensively from where the meshes are originating from to try to find the points where it collides with the other mesh, record these and then try to build a mesh out of them. 2 things make this really difficult -- I have to also linepick backwards towards the original object to find the end of the intersection, and i think that it will be very challenging to build the mesh correctly once i've found the intersection points (not sure how to organize all those points so that i can connect them right).
2. The second approach i've considered is to try to do some old-fashioned 2d wizardry, rendering the scene to image buffers and trying to figure out the intersections based on colors. If I were to render the scene top-down I could pretty easily show the intersections in a different color (by making the meshes additive), but once i've done that, it seems like i'll be stuck doing a whole mess of "readpixelfast"s which will be slow. Once I finished that, I could presumably place the result in a texture and give the UV coords to make it overlay the meshes correctly, though, which would be pretty simple.
So does anyone have suggestions for either approach?
If I go with the mesh way, is there a way to evaluate these intersections without all the linepicking? (i guess with straight up math?) Or is there some other method that I'm missing?
If I go with the second method, is there a way that I could evaluate the colors of the image / intersecting areas without reading every pixel to test its color? Maybe using images as textures overlaying one another? I am afraid I am out of my depth :)
Ok, I think I'll shut up now. Please let me know if you have any questions or suggestions!
cheers,
roland