Jump to content

What is the reasoning behind the variable behavior?


kgoossens

Recommended Posts

I wasn't aware of these issues. But then using variables in the transform node is actually something to be avoided unless you are really sure you are never going to channel reference them.

This has always been true for all local variables. It is not specific to any SOP in particular. Basically, these cases where people noticed the new behaviour in 12.1 means that their .hip file has always been a ticking time bomb. It might work today, but then modifying the file later could mean that suddenly things cooked differently.

Link to comment
Share on other sites

Hi Edward,

Thanks for the answer, but how can I explain it correctly to my students?

I'm not able to find a correct explanation of it in the help file.

Because what I was saying to my students is that variables such as $SIZEX is like a shortcuts from bbox("../surfnode",D_XSIZE). Except it is getting it's information directly from the connected node. So this is probably wrong.

Cheers

Edited by kgoossens
Link to comment
Share on other sites

The correct explanation is to first differentiate between regular (global) variables and local variables. Such variables are always marked as "local" in the documentation. Then explain that local variables are "local" in the sense that they are local to the scope of the node cooking. So the values of the local variables only have meaning when evaluated inside the cooking of the node itself. This is regardless of whether it is something like $TX or $SIZEX. They are both documented as "local" variables for this reason. It is a bug that you can see the value of $SIZEX but not $TX. Since $SIZEX is a local variable just like $TX, it also has no meaning outside of its owner node cooking. In fact, the "$SIZEX" value is computed during the cook of the node from its input.

Link to comment
Share on other sites

I haven't seen this behaviour but wanted to say that I am glad that SESI breaks backwards compatibility in the pursuit of correctness :)

I hate it when companies like Microsoft keep broken bugs because they official reply that someone somewhere in the world relies on this bug so they can't fix it. So you have to use a workaround that makes your code very unreadable.

In the end their software becomes extremely bloated and full of gotchas that require countless hacking (Windows Forms for one).

Just wanted to say that I am grateful that SESI favors correctness over backwards compatibility.

Sorry for the minor derail :)

  • Like 1
  • Downvote 1
Link to comment
Share on other sites

Hi there is this related ?

New houdini version updated

Friday, September 14, 2012

Houdini 12.1.73: To maintain backwards compatibility (only in H12.1) for uniform local variables in SOPs like $CEX, we now relax the check so that once again, they return non-default values when evaluated outside of cooking.

mangi

Link to comment
Share on other sites

  • 2 years later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...