Hi
Long time since I posted.
I have an animated horse that I'm trying to measure the thickness of different parts - legs, body, head, ears, etc. I basically want to pump it into color but I'm having a hard time generating a procedural way to measure an attribute for thickness.
The idea is that the thinnest parts change color first.
Any help!?
Thanks!
Measure Geometry Thickness
17058 21 7
-
- moonlightkiss02
- Member
- 8 posts
- Joined: 2月 2014
- Offline
-
- moonlightkiss02
- Member
- 8 posts
- Joined: 2月 2014
- Offline
-
- circusmonkey
- Member
- 2624 posts
- Joined: 8月 2006
- Offline
-
- eetu
- Member
- 606 posts
- Joined: 5月 2007
- Offline
-
- buki
- Member
- 1773 posts
- Joined: 12月 2006
- Offline
it would be nice and a reliable way to do this in sops, it would be very useful
daniel bukovec | senior fx td | weta digital
qLib -- http://qlab.github.io/qLib/ [qlab.github.io]
qLib -- http://qlab.github.io/qLib/ [qlab.github.io]
-
- mawi
- Member
- 251 posts
- Joined: 1月 2008
- Offline
-
- old_school
- スタッフ
- 2540 posts
- Joined: 7月 2005
- Offline
Did a 30 second Google search wrt Lightwave, didn't find much… What I did find was scant reference to thickness being evaluated from a “surface thickness gradient”. No other info so I am assuming that you need to bake a map out by rendering which fires rays??? Assumption here…
Whatever…
The firing rays works very well to evaluate thickness and you don't have to resort to the VOP SOP approach as you do have to correct those “perfect” cases such as fingers where the tips can fire right up to the shoulder anyway, and VOPs this means recursing over neighbours which means point clouds, blah. Just use a couple Attribute Promotes and a smooth.
Done.
See the attached file.
Whatever…
The firing rays works very well to evaluate thickness and you don't have to resort to the VOP SOP approach as you do have to correct those “perfect” cases such as fingers where the tips can fire right up to the shoulder anyway, and VOPs this means recursing over neighbours which means point clouds, blah. Just use a couple Attribute Promotes and a smooth.
Done.
See the attached file.
There's at least one school like the old school!
-
- mawi
- Member
- 251 posts
- Joined: 1月 2008
- Offline
-
- moonlightkiss02
- Member
- 8 posts
- Joined: 2月 2014
- Offline
-
- moonlightkiss02
- Member
- 8 posts
- Joined: 2月 2014
- Offline
-
- old_school
- スタッフ
- 2540 posts
- Joined: 7月 2005
- Offline
Excellent vex wrangler question. With the wrangler, I declare a local variable with the type something like this:
float my_variable = 1.0;
When you do that, my_variable will not be exported to the geometry and is only local for the current iteration through the points. It is local to the SOP.
As opposed to this:
@my_bound_variable = 1.0;
will add the float “my_bound_variable” to the geometry as a float type attribute to be used in subsequent SOPs.
It's wise to only add the additional attributes you need later on. You can quickly add geometry bloat.
float my_variable = 1.0;
When you do that, my_variable will not be exported to the geometry and is only local for the current iteration through the points. It is local to the SOP.
As opposed to this:
@my_bound_variable = 1.0;
will add the float “my_bound_variable” to the geometry as a float type attribute to be used in subsequent SOPs.
It's wise to only add the additional attributes you need later on. You can quickly add geometry bloat.
There's at least one school like the old school!
-
- moonlightkiss02
- Member
- 8 posts
- Joined: 2月 2014
- Offline
OK, that's cool!
So I ended up putting it into a VOPSOP for a little more artistic control but kept your version to switch between. I'll probably make it an asset for the company I'm at. Seems super handy!
A couple things I noticed:
1)the peak was renamed after the first wrangle and the network still worked for me, which is odd.
2)The horse geometry I've included for some reason didn't play well with the subdivide and point sops. The point sop errors saying it can't evaluate NX, NY, NZ. If I add the normals before the subdivide it works, but I'm not sure why the normals would error out from the subdivide.
So I ended up putting it into a VOPSOP for a little more artistic control but kept your version to switch between. I'll probably make it an asset for the company I'm at. Seems super handy!
A couple things I noticed:
1)the peak was renamed after the first wrangle and the network still worked for me, which is odd.
2)The horse geometry I've included for some reason didn't play well with the subdivide and point sops. The point sop errors saying it can't evaluate NX, NY, NZ. If I add the normals before the subdivide it works, but I'm not sure why the normals would error out from the subdivide.
-
- PradeepBarua
- Member
- 443 posts
- Joined: 9月 2012
- Offline
1)the peak was renamed after the first wrangle and the network still worked for me, which is odd.
Because peak value of 0.001 is very minimal and dist is equal to dist minus this value (@dist -= ch(“/obj/sphere_object1/peak_avoid_self_collision/dist”)
. As there is wrong reference so dist = dist. So you do not notice much difference.
-
- PradeepBarua
- Member
- 443 posts
- Joined: 9月 2012
- Offline
2)The horse geometry I've included for some reason didn't play well with the subdivide and point sops. The point sop errors saying it can't evaluate NX, NY, NZ. If I add the normals before the subdivide it works, but I'm not sure why the normals would error out from the subdivide.
Your geometry already have vertex normal. That's why point sop errors out.
Just delete vertex normal or promote it to point. If you promote it then you don't need point sop.
-
- PradeepBarua
- Member
- 443 posts
- Joined: 9月 2012
- Offline
PradeepBarua
Because peak value of 0.001 is very minimal and dist is equal to dist minus this value (@dist -= ch(“/obj/sphere_object1/peak_avoid_self_collision/dist”)
wow!!! wrangle's semicolon and my close parentheses giving me this
sign. never mind
-
- pelos
- Member
- 621 posts
- Joined: 8月 2008
- Offline
-
- grayOlorin
- Member
- 1799 posts
- Joined: 10月 2010
- Offline
if you are looking for thickness based on 3D locality and not camera based, I recommend looking up medial axis of 3D meshes. I used something like it to calculate thickness of tree branches to drive stiffness. I put an RFE for this with SESI as a very useful atomic SOP to have for different things, but we did a poor man's implementation at my studio for our purposes.
This is probably one of my favorite papers on it. You do not have to nail it exactly, but even an approximation using the ray SOP may get you there:
http://web.siat.ac.cn/~huihuang/Skeleton/Skeleton_page.html [web.siat.ac.cn]
This is probably one of my favorite papers on it. You do not have to nail it exactly, but even an approximation using the ray SOP may get you there:
http://web.siat.ac.cn/~huihuang/Skeleton/Skeleton_page.html [web.siat.ac.cn]
-G
-
- littlegreenlantern
- Member
- 5 posts
- Joined: 7月 2015
- Offline
-
- Chassaigne Victor
- Member
- 15 posts
- Joined: 12月 2015
- Offline
-
- BabaJ
- Member
- 2127 posts
- Joined: 9月 2015
- Offline
The attribute @dist has a certain value before the line of code you show is executed,
after that line is finished the value of @dist will have had the value from the channel reference ch(“/obj/sphere_object1/peak1/dist”) subtracted from it.
it could have easily been += which would have had the channel reference added,
and if *= multiplied by it.
In the line you reference it is a short form for the same thing as this:
after that line is finished the value of @dist will have had the value from the channel reference ch(“/obj/sphere_object1/peak1/dist”) subtracted from it.
it could have easily been += which would have had the channel reference added,
and if *= multiplied by it.
In the line you reference it is a short form for the same thing as this:
@dist = @dist - ch("/obj/sphere_object1/peak1/dist");Edited by BabaJ - 2018年6月18日 19:02:40
-
- Quick Links