how do I add points to a group over time
6041 7 0- breht
- Member
- 11 posts
- Joined: June 2016
- Offline
I am trying to make something to find out if polys in a model can be seen so I can remove deep undercuts. My has been to shoot rays in a bunch of of direction and if any = 0 I know they can be seen. my problem is that I can figure out how to to add points to a group/or change the color overtime without overwriting the whole set.
if there is a simpler/better way to do this I would be grateful to hear it.
if there is a simpler/better way to do this I would be grateful to hear it.
- jlait
- Staff
- 6413 posts
- Joined: July 2005
- Offline
As soon as you say “over time” you need a simulation. While this means DOPs, the good news is you can set this up without ever seeing DOPs.
Put down a Solver SOP in your SOP network. Place your original geometry in the first input.
Now, inside the solver sop, there are 5 nodes. Four are grey and merge in your original inputs. These do not feedback, but read your sop chain. This is how you can get your animated source in.
The purple node is the feedback node. This has the previous frame's geometry. So, append your “add to point group if visible” node to the purple, set it as the display flag. Then hit ‘u’ to return to the higher level and hit play. You should get it accumulating.
Alternatively, you can use a For Loop to feedback and accumulate, but the solver sop has the advantage of making it easy to step through time and see how it works.
Put down a Solver SOP in your SOP network. Place your original geometry in the first input.
Now, inside the solver sop, there are 5 nodes. Four are grey and merge in your original inputs. These do not feedback, but read your sop chain. This is how you can get your animated source in.
The purple node is the feedback node. This has the previous frame's geometry. So, append your “add to point group if visible” node to the purple, set it as the display flag. Then hit ‘u’ to return to the higher level and hit play. You should get it accumulating.
Alternatively, you can use a For Loop to feedback and accumulate, but the solver sop has the advantage of making it easy to step through time and see how it works.
- breht
- Member
- 11 posts
- Joined: June 2016
- Offline
- breht
- Member
- 11 posts
- Joined: June 2016
- Offline
- jlait
- Staff
- 6413 posts
- Joined: July 2005
- Offline
When in “Attribute” mode the Ray SOP takes the name of the attribute. So it should be just rayvector, not @rayvector. This is the preferred mode over using the @xvec/@yvec/@zvec.
You need to freeze the file sop before uploading so we can see how this works with your geometry. Or provide the geometry as an attachment as well.
You need to freeze the file sop before uploading so we can see how this works with your geometry. Or provide the geometry as an attachment as well.
- breht
- Member
- 11 posts
- Joined: June 2016
- Offline
- jlait
- Staff
- 6413 posts
- Joined: July 2005
- Offline
I'm not sure what is intended with xyz/step…. They are currently set to
@NX-@P.x
but:
1) There is no @NX. This should be @N.x to get the normal.
2) Subtracting position from normal isn't meaningful.
I think since you are wanting to sample a bunch of directions around the point you should just set x/y/z step to some small value. Its actual size doesn't matter as the ray sop will be normalizing it anyways.
You don't need to sample in the ray sop, at least not to the level of 300 samples, as you are sampling above.
You also have a problem that you are walking over a cube. This means doubling your resolution is eight times the samples, but really should only need four times the samples. Simplest option is just to replace the whole x/y/z count with a single count and run
@raydir = rand(@count);
@raydir -= 0.5;
which will give you random ray directions letting you set your quality by just running longer.
Final problem is a bit subtle… You are using @dist == 0 to detect if no collision happened. However, the Ray SOP only updates the dist value if a collision occurred. So if a point collided in an earlier frame, it will have a non-zero distance value and never become zero again. We can fix this by setting @dist to -1 earlier.
With these changes, and reducing ray resolution to 4 (so it completes in 125 frames) we then have everything go red at the half way point. This is because raydir is exactly zero, which means the ray sop won't hit anything, and everything gets flagged. A work around is just to jitter the raydir if it is exactly zero. But as mentioned above, it would be better to pick a random vector until one gets a non-zero.
In the attached I've changed the second solution to accumulate the total visiblity rather than treating it as zero/one. This helps handle cases like the deeply recessed components. You can then group on a threshold of the visibility attribute.
@NX-@P.x
but:
1) There is no @NX. This should be @N.x to get the normal.
2) Subtracting position from normal isn't meaningful.
I think since you are wanting to sample a bunch of directions around the point you should just set x/y/z step to some small value. Its actual size doesn't matter as the ray sop will be normalizing it anyways.
You don't need to sample in the ray sop, at least not to the level of 300 samples, as you are sampling above.
You also have a problem that you are walking over a cube. This means doubling your resolution is eight times the samples, but really should only need four times the samples. Simplest option is just to replace the whole x/y/z count with a single count and run
@raydir = rand(@count);
@raydir -= 0.5;
which will give you random ray directions letting you set your quality by just running longer.
Final problem is a bit subtle… You are using @dist == 0 to detect if no collision happened. However, the Ray SOP only updates the dist value if a collision occurred. So if a point collided in an earlier frame, it will have a non-zero distance value and never become zero again. We can fix this by setting @dist to -1 earlier.
With these changes, and reducing ray resolution to 4 (so it completes in 125 frames) we then have everything go red at the half way point. This is because raydir is exactly zero, which means the ray sop won't hit anything, and everything gets flagged. A work around is just to jitter the raydir if it is exactly zero. But as mentioned above, it would be better to pick a random vector until one gets a non-zero.
In the attached I've changed the second solution to accumulate the total visiblity rather than treating it as zero/one. This helps handle cases like the deeply recessed components. You can then group on a threshold of the visibility attribute.
- breht
- Member
- 11 posts
- Joined: June 2016
- Offline
-
- Quick Links