Hazoc Posted March 29, 2011 Share Posted March 29, 2011 Hello Has anyone solved the problem of selecting primitives by testing if they fully or partially occupy same space with a selector primitive/primitives ? Attribute transfer offers some help but requires tuning of the Distance Treshold parameter, so it's not very procedural method. group_by_inclusion.hipnc Quote Link to comment Share on other sites More sharing options...
graham Posted March 29, 2011 Share Posted March 29, 2011 (edited) I might do something like this. Since it uses a ForEach it might not be super ideal for huge amounts of geometry in which case I might rely on doing it more script based instead of node based. For each primitive you can scatter some points on it and then attempt to group those points by the bounding geometry. If there are any points in the group then you group the primitive. If you wanted to test for full enclosure you'd compare the number of points in the group to the number of points you scattered. group_by_inclusion.hipnc Edited March 29, 2011 by graham Quote Link to comment Share on other sites More sharing options...
Hazoc Posted March 29, 2011 Author Share Posted March 29, 2011 I might do something like this. Neat hack:) I'm afraid everything is too slow for this since I'm testing a new greeble technique:) Quote Link to comment Share on other sites More sharing options...
graham Posted March 29, 2011 Share Posted March 29, 2011 (edited) Yeah it's definitely not so hot then. The best solution for large amounts of geometry is to use c++. In the original file I upped the grid to be 600x600 divisions for a total of about 359000 primitives. I was able to calculate that 3721 of them were at least partially contained inside the control box in approximately 90ms using a custom Python function built using inlinecpp. It works by iterating over each primitive, getting the bounding box for it and intersect it with the bounding box of the other geometry. The only downside with this is that if the bounding box is close to the primitive and the primitive is not planar to one of the axis planes you might get unenclosed prims grouped since instead of a bbox that is the shape of your prim with no height it now has height to take into account the fact that it is non-planar. You of course could also change to checking for full enclosure to mitigate this. If you've got the ability to compile using the HDK it might be a worthwhile solution. Edited March 29, 2011 by graham Quote Link to comment Share on other sites More sharing options...
Hazoc Posted March 29, 2011 Author Share Posted March 29, 2011 Yeah it's definitely not so hot then. The best solution for large amounts of geometry is to use c++. In the original file I upped the grid to be 600x600 divisions for a total of about 359000 primitives. I was able to calculate that 3721 of them were at least partially contained inside the control box in approximately 90ms using a custom Python function built using inlinecpp. That's very good! I wonder how fast this task is anyway possible to execute if some custom system was solely dedicated to solve box inclusions. Inlinecpp seems awesome. I took a look of some of your module which had point tree building and some other crucial stuff pulled neatly from HDK to assist hom scripting. I've been planning to start learning it now when there's a detailed guide from the community how to setup a compiling environment in windows. I'm not very familiar with C++ nor HDK but your code snippets were higly readable. Quote Link to comment Share on other sites More sharing options...
petz Posted March 29, 2011 Share Posted March 29, 2011 a simple hack for testing if prims are inside another geometry is some kind of ray-intersection testing. this can be done in vex and it is quite similar to how bounding box checking is performed in the hdk. its acceptable fast and under most circumstances it does a good job. but as graham said, if performance is an issue there is no way around the hdk. file is attached! petz Quote Link to comment Share on other sites More sharing options...
petz Posted March 29, 2011 Share Posted March 29, 2011 forgot to attach the file! petz group_by_inclusion1.hipnc Quote Link to comment Share on other sites More sharing options...
Macha Posted March 30, 2011 Share Posted March 30, 2011 (edited) Volume samples would be another one. Not as fast as Grahams but not so far off I think (tested 600^2 grid and 1^3 box in 125ms) intersectme.hip Edited March 30, 2011 by Macha Quote Link to comment Share on other sites More sharing options...
graham Posted March 30, 2011 Share Posted March 30, 2011 Yeah, volumes was my next test method but I had to head out. It might not be quite as fast but it's definitely a lot easier to implement and no code required. What I also liked about using volumes is that you can use the actual geometry shape, as opposed to merely a bounding box of your geometry. Quote Link to comment Share on other sites More sharing options...
Hazoc Posted March 30, 2011 Author Share Posted March 30, 2011 Volume samples would be another one. Not as fast as Grahams but not so far off I think (tested 600^2 grid and 1^3 box in 125ms) Hmm this is quite good. I only need to generate one volume since I'm doing box clipping operations with various size boxes. I just then match the size of that volume to fit the box in question. Thanks guys! Quote Link to comment Share on other sites More sharing options...
petz Posted March 30, 2011 Share Posted March 30, 2011 using volume samples works if at least one vertex of the prim is inside the volume. if thats not the case as in hazocs first example you won´t get propper results. the same problem appears when you´ll use a group-sop with bounding-option enabled to find points which are inside the geometry. it doesn´t work for general intersection-testing. petz Quote Link to comment Share on other sites More sharing options...
Hazoc Posted March 30, 2011 Author Share Posted March 30, 2011 (edited) using volume samples works if at least one vertex of the prim is inside the volume. if thats not the case as in hazocs first example you won´t get propper results. the same problem appears when you´ll use a group-sop with bounding-option enabled to find points which are inside the geometry. it doesn´t work for general intersection-testing. petz The original problem remains, true. I just have to compromise here. It might work OK, if not then it's inlinecpp and lot's of studying:) Edited March 30, 2011 by Hazoc Quote Link to comment Share on other sites More sharing options...
Macha Posted March 30, 2011 Share Posted March 30, 2011 using volume samples works if at least one vertex of the prim is inside the volume. Ah it's true. As a slight improvement we could scatter points on the edges near the volume. Quote Link to comment Share on other sites More sharing options...
web design Posted April 7, 2011 Share Posted April 7, 2011 Neat hack:) I'm afraid everything is too slow for this since I'm testing a new greeble technique:) Quote Link to comment Share on other sites More sharing options...
dyei nightmare Posted April 7, 2011 Share Posted April 7, 2011 (edited) Ah it's true. As a slight improvement we could scatter points on the edges near the volume. macha youll have to teach us how you did this is fucking awesome effect Edited April 7, 2011 by dyei nightmare Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.