yeah, that's about the same as when you use the first return in my function: simply create a volume for every triangle. The fine art is then to remove the enclosed tris. Even more efective would be to create only the needed Tris/quads, of course.
I have found elias_t's ray intersect triangle code in the archives and I assume it would work much faster than linepick, but I still try to find an idea on how to use it.
where Linepick will return the first pickable triangle that was "hit", the function by elias will only tell if the ray was intersecting a certain triangle. So theoreticly I'd have to check all triangles for every ray and return the one of those that are intersecting wich has the lowest distance from the intersection point to the pivot.
I guess that's also how Linepick works internally (thus the exponential slowdown with highpoly stuff and Linepick)
At least this Linepick replacement allows a simpler structure in general:
now we only have to store the vertex and triangle data in arrays and will then be able to generate a shadow volume using only the required sihouette triangles.
The source mesh'es triangle data must also be accessible in the arrays to allow to obscure things, like in the version using Linepick.
It's also useful that the ray intersection code doesn't care about normals, so it will work form both sides and you don't have to worry about flipped triangles.
The only question left is: will the 32 Bit accuracy be high enough to prevent the rounding errors seen with Linepick? (if it really WAS linepick that caused it).
And maybe: will it be fast enough?
I'll try to implement it this way the sooner or later.
I have found elias_t's ray intersect triangle code in the archives and I assume it would work much faster than linepick, but I still try to find an idea on how to use it.
where Linepick will return the first pickable triangle that was "hit", the function by elias will only tell if the ray was intersecting a certain triangle. So theoreticly I'd have to check all triangles for every ray and return the one of those that are intersecting wich has the lowest distance from the intersection point to the pivot.
I guess that's also how Linepick works internally (thus the exponential slowdown with highpoly stuff and Linepick)
At least this Linepick replacement allows a simpler structure in general:
now we only have to store the vertex and triangle data in arrays and will then be able to generate a shadow volume using only the required sihouette triangles.
The source mesh'es triangle data must also be accessible in the arrays to allow to obscure things, like in the version using Linepick.
It's also useful that the ray intersection code doesn't care about normals, so it will work form both sides and you don't have to worry about flipped triangles.
The only question left is: will the 32 Bit accuracy be high enough to prevent the rounding errors seen with Linepick? (if it really WAS linepick that caused it).
And maybe: will it be fast enough?
I'll try to implement it this way the sooner or later.