Test inside geometry failing

[Eric Thivierge]

Anyone notice how many times this just doesn't work correctly? Even
toggling the Closed volume inside often doesn't give the correct results
as well...

I have a voxel setup with particles and testing inside a geometry to
keep the ones that are within, works, however there are many points
still outside the geo that remain and aren't deleted. The ones left
outside changes each frame as well.

Anyone have any sure fire methods / workarounds that don't involve
having helper nulls to delete the remaining ones outside?

--
Eric Thivierge
===============
Character TD / RnD
Hybride Technologies

[Peter Agg]

Is this the thing where you get giant cubes of bad volume data, or something else?

[Eric Thivierge]

Not necessarily cubes. If I run a smooth op on the geo it fixes much of it (although this is not a solution for me) so it's got to be the internal methods not liking something about the geometry.

Eric Thivierge
===============
Character TD / RnD
Hybride Technologies

[Peter Agg]

Yeah, that's my only suggestion really - I've had quite a few problems before where I had very dense particles being culled by complex geo and on random frames you'd get very distinct cubes where the volume calculations have freaked out. Never found a particularly useful workaround, I'm afraid. 

Simplifying the geo has helped, sometimes not grouping them together and doing several tests on individual parts did. But sometimes that just shifts the problem to different frames - for the project I was on we had one of those unfortunate 'just do it in Houdini' moments.

Good luck! :)

[Steven Caron]

maybe instead of just doing it in houdini he could use SDFs?

http://blog.blackredking.org/?p=47

[Ciaran Moloney]

On Tue, May 7, 2013 at 8:37 PM, Steven Caron <car...@gmail.com> wrote:

maybe instead of just doing it in houdini he could use SDFs?

http://blog.blackredking.org/?p=47

Yeah, that'll also fail on complex shapes...

Often, subdividing the geometry will fix the problem.

[Raffaele Fragapane]

You could write/wire the test yourself.

Point inside hull is fairly trivial outside of fringe cases, shoot a ray in any direction, if it intersects an odd number of times, it's outside, even, it's inside.
You might want multiple rays and take the median of the result, or work conservatively and flag it even if just one tests true.

You can further refine this with a force field approach, run a distance from hull (closest location on geo), and if the point is close enough to a location with a normal facing away from its distance vector remove it, and remove anything within a certain threshold (very close) indiscriminately.

Testing against denser geometry also helps, even if it's more expensive, sparse and variedly populated topology tends to introduce more room for error.

Lastly, a triangulated mesh, especially if you have a certain degree of dis-planarity in your geo on large enough areas, will also improve things in my experience.

--
Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!

[Raffaele Fragapane]

ARGHH, as usual, no proof reading is as good as the one done after sending.

Even = outside

Odd = inside.

[Ciaran Moloney]

IIRC implementing the ray intersect technique is problematic in ICE, since the raycast node only returns the first intersection. You'd have to manually shoot subsequent rays after every hit.

[Eric Thivierge]

Thanks guys,

Ciaran, your addon actually works exceptionally well in my case. The slider for the "Override_test_distance" gets rid of the errant areas very very well. Not to mention generating this particle cloud is super fast now. You've saved me some late night work today. :)

I did try to roll my own but was still getting the unwanted areas. The tips on how to build it are appreciated as it may help in future cases.

Cheers,

Eric Thivierge
===============
Character TD / RnD
Hybride Technologies

[Ciaran Moloney]

Cool! 

I always wanted to add the ray intersect test to make this thing more robust, but have long since run out of energy...

Ciaran