Tomas Slancik
tamte
About Me
INDUSTRY
Advertising / Motion Graphics
Connect
LOCATION
New York,
United States
WEBSITE
Houdini Skills
Availability
I am currently employed at Method Studios
Recent Forum Posts
Overriding skinning information in SOP May 20, 2024, 7:56 p.m.
You can use Attribute String Edit to rename the region names within the boneCapture attribute
Just specify the attribute name as boneCapture* or directly as boneCapture.pCaptPath for it to work
Just specify the attribute name as boneCapture* or directly as boneCapture.pCaptPath for it to work
NicTangheOr if you really want to use the unpacked attribute, the region names are stored in a Detail attribute where you can edit them
It seems that you cant really change or ad bone capture regn names only the indexes wich doesn`t really help here.
Difference in contrast of Karma viewport and render May 18, 2024, 10:50 a.m.
EnivobI disagree, in my opinion seeing the live render in the viewport with the same LUT should look exactly the same as seeing the offline render in e.g. Mplay with the same LUT
The viewport is just a guide. You're comparing an 8 bit jpeg screen grab to a floating point EXR color space. What you render is the true pixel value. Click the viewport full range button and adjust the viewport f-stop to match the viewport to the render, but I think most people look past that task and just accept the render is the final look.
Blindly accepting any difference seems ridiculous
vex for loop "i" doesn't seem to change ? what have I done?(SOLVED) May 15, 2024, 9:20 p.m.
in your code you are just overwriting the num, one, two, three variables each iteration. so you will be left with the last one
the fact that the second code seems to work is that you stop at @ptnum-1 which at least will give you different value per point even though I assume not correct one since you are not only using @ptnum-1 as your center point, but also assuming that your geo has only a single curve with points ordered by vertex order, which is not a safe assumption generally and sampling primpoints array at the index @ptnum-1 is therefore pretty random or heavily dpendent on perfect conditions of the input geo
here is a code that may work better:
the fact that the second code seems to work is that you stop at @ptnum-1 which at least will give you different value per point even though I assume not correct one since you are not only using @ptnum-1 as your center point, but also assuming that your geo has only a single curve with points ordered by vertex order, which is not a safe assumption generally and sampling primpoints array at the index @ptnum-1 is therefore pretty random or heavily dpendent on perfect conditions of the input geo
here is a code that may work better:
int nbrs[] = neighbours(0, @ptnum); foreach( int nbr; nbrs){ vector nbrP = point(0, "P", nbr); float edge_length = distance( v@P, nbrP ); append( f[]@edge_lengths, edge_length ); } f@min_edge_length = min( f@edge_lengths );