attribute color remap, something feels wrong

[anbt]

Hello guys,

I made a quick example to illustrate my issue.
I figured out how to bring the colour values of the different vellum stresses out of the solver, so I can use them in rendering (in my example I am talking about the stretchdistance)

I use the attribute transfer and then try to remap the colour range. Vellum uses this purple to red range and I am just trying to remap it with the point vop to a different range but it doesn't seem right. 
The gradient is different. The blend between colours seems a lot harsher after the PointVop.

Attached some screenshots to illustrate my point. I put the hip file in case.

Any clues?

Thanks

 

test_color_att.hip

[underscoreus]

Heyo,
You're right in that it seems a bit off, this is probably due to the fact that when you plug the bind into the ramp node it converts the color vector into a float and the way Houdini does that automatically if I don't remember wrong is by only grabbing the first value of the vector, in this case, the red channel. So all you are getting out of/processing in the ramp is the red channel.

I've made two mockups that get you some better results, one that just post-processes the values you create for the stretch distance (can't say I looked too far into that subnet. Whenever I see include statements in the wrangles I tend to nope out pretty quick because I am not very familiar with other libraries other than the default vex library ) and one where I compute the stretch distance the way I would usually do it and then transfer it over to your geometry. My method gives a little different looking result to yours so it's whatever you fancy. Both should still be accurate.
 
One last note is that I used Houdini 18.0.460 to make this file so there might be some changes and conversions from the version change.

Hope it can help!

 

test_color_att_mnb.hiplc

[anbt]

Thanks a lot for your answer, I will look into what you did as soon as I can  

 

EDIT: Your little VOP network does bring much better results, I implemented it on something else and it works well. But I don't understand the logic (yet). 
I don't get why you do    stress.r + stress.g - stress.b    to get the correct result.

Regarding your other method, with the attribute transfer, it doesn't work, and I have no idea why, I don't have any errors  I see some colours, but it doesn't change according to the stretch, it stays identical. As you pointed out, perhaps it is because we don't have the same Houdini version.
Hahaha, yes, the way I extract those stress values from the solver in the subnet is also a bit of a mystery to me, I went deep inside the velum solver where they compute the geometry visualisation and grabbed the nodes I needed, but I don't understand it all!

Edited March 18, 2021 by anbt

[underscoreus]

8 hours ago, anbt said:

Your little VOP network does bring much better results, I implemented it on something else and it works well. But I don't understand the logic (yet). 
I don't get why you do stress.r + stress.g - stress.b to get the correct result.

This method was mostly me messing around going by eye, it's not necessarily a very accurate representation. I just split out the colors into individual float values in the vop and looked at them individually. The values that come from your subnet seems to be visualization colors that are from the "infra-red" preset, meaning that blue colors are where the values are weakest, so when adding it with the other colors I just tried inverting it using the negate node so that it would not add values in the areas where there is supposed to be low values. Like I mentioned this is a very touch and feel approach, not very accurate and it needs a bit of tweaking to work at all.

 

8 hours ago, anbt said:

Regarding your other method, with the attribute transfer, it doesn't work, and I have no idea why, I don't have any errors  I see some colours, but it doesn't change according to the stretch, it stays identical. As you pointed out, perhaps it is because we don't have the same Houdini version.

Hmm, maybe. You could try to recreate the setup in your original scene and see if you can make it work there. However, it might just be that you'll want to tweak the min and max values on the "remap_stretchdistance" attribute vop, I might have set it to be too uniform. I just tried clamping it a bit more with values like 0.115 min and 0.436 max. Still, I will admit that this method does look quite a bit different from the other values you get, but again, I can't really answer as to why that is unfortunate because I don't really know how the other values are calculated. All I can say is that my method simply gets the difference between a constraints "restlength" attribute (the length of the primitive at the first frame of the simulation) and its current length each frame and outputs it to an attribute, then transfer that onto the simulated geometry and remap it afterward and then blur it using the smooth node for a nicer looking result.