[HOU-3029] V-Ray Remaps/Ramps issue

[martin_aufinger]

Hi everyone,

We (at GBK) are having an issue with the ramp parameter on 'V-Ray Remaps' on our project.
We have so far been working with build '52020', '0598092' (refereed to as old build) but recently updated to '52020', '8c7bc47' (refereed to as new build) due to a bug fix with crypto mattes.

Now it turns out that there are a few differences between the builds in regards to how ramps work which is slightly problematic in the middle of production. See screenshot below.

1) When using the remap in 'Remap type to Value', the colour output doesnt work. In the old Vray build the colour output was matching the float output.
2) The float output works correctly.
3) If a null is attached after the remap, the ramp stops having any effect.
4) If plugging a colour input into the same remap node, the output doesnt work (which may be intended)? however, a null after it changes the output value.

Can provide .hip if it helps.

Thanks
Martin

[bdancer]

1. Can provide .hip if it helps -- Yes it will.
2. Are we talking Solaris or?

[martin_aufinger]

No Solaris. Just old school vray.

I cant upload .hip extension? Is there any prefered way of sharing files?

[bdancer]

> I cant upload .hip extension? Is there any prefered way of sharing files?

I think .zip is allowed.

[martin_aufinger]

ah. thanks

file attached. debugremaps_marauf_v002.hip.zip
google drive link removed

[daeschri]

This same issue was previously logged in early February under ticket 23068 and all the the described issues were provided with example files then too.
Looks like the last message we received about it said Chaos needed more time to perform tests and then it seems it was automatically closed.

[Gosho.Genchev]

Hey all,

I'll chip in with some info - as daeschri said, we already know about these and we plan to split the Remap node into two separate "Remap Float" and "Remap Color" nodes to resolve confusion in the future. I'll talk to the developers and get back with more info tomorrow.

Best regards!

[martin_aufinger]

Thanks for the quick update and I understand the longterm plan to split the two. Makes sense.
However, it would still be great to get a fix for the current issue if possible.

I have two builds to chose from in mid production and both have different issues.

[martin_aufinger]

Hi Gosho.Genchev
Do you have any updates on this?

[Gosho.Genchev]

Hey martin_aufinger ,

I have a build from one of our developers to test the changes. I'll do it later today and get back to you with more info/ETA.

Best regards!

[martin_aufinger]

Great news. Thank you!

[Gosho.Genchev]

Hey martin_aufinger ,

There are a couple of issues with the new nodes to take care of before we can add them to the nightly builds. The developers are on it - I'll update you again on Monday - I hope I'll have good news by then.

Best regards!

[martin_aufinger]

Hi Gosho.Genchev

Thanks for the update.
That sounds like you are already implementing the spit into two separate nodes. I may have misread this as a midterm/longterm plan.

Will there be any backwards compatibility to the old node (ideally in a state where both outputs work correctly) ?

I understand the overall aim is to simplify by splitting it in two which makes a lot of sense but I am a bit worried if the new build would break all assets that use the old node. It would probably prevent me from using the new build on the current show.

Thanks
Martin

[Gosho.Genchev]

Hi martin_aufinger ,

We will keep the old node and simply hide it specifically to keep backwards compatibility. You shouldn't have any issues with your old assets.

Best regards!

[martin_aufinger]

That's great to know. Thanks!