Hi Everyone….
I started using Houdini apprentice just a few days ago to test if Houdini is right for me, and so far I have being enjoying it very much!

But after seeing a few tutorials I came accross this op: command that seems to be the prefferred way to reference geometry to an inside object rather than an external file. For example in this file is used as such:
op:`opinputpath(“.”,1)`

inside the attribvop_curveTangle1 operator.

This is fine by me, But I do wonder why not just link the input geometry as I did in attribvop_curveTangle operator.
It seems to me a lot more clean just to link the input to the primitive node rather than driving the string by a command.

I am asking because the op:`opinputpath(“.”,1)` it seems a bit unstable. Since sometimes when I just access the expression editor again and just apply the same expression without changing it it gives me an “Unable to execute command” error. Which brings me to my second question…Why just opening the expression editor and executing the same command gives me an error? Is there something special about the op: command compared to other expressions? or maybe is the fact that it uses ``.

To your first question: Your solution seems to work fine. In fact, it seems slightly faster. I did not notice this option existed in VOPs and I will certainly use it now. The expression is just a more universal solution and so it works outside of VOPs.

To your seccond question: I think you are right. I think the error occurs because it is using backticks. I am fuzzy on this, but I think the backticks mean that the stuff in backticks gets evaluated as an expression before the parameter content is read out.
I think the fact that the expression editor gives an error for this, is based on how the expression editor is implemented. I guess it is a kind of bug. On the upside expressions in backticks are typically very short. They are also typically used in the font SOP, where you have a sufficient space in the parameter without the expression editor.

DASD
To your first question: Your solution seems to work fine. In fact, it seems slightly faster. I did not notice this option existed in VOPs and I will certainly use it now. The expression is just a more universal solution and so it works outside of VOPs.

Really glad that I could help even a little bit considering the fact that this is my first 2 days with the soft After seeing a few tutorials who did not use it I started feeling I was using something that shall not be touched

To your seccond question: I think you are right. I think the error occurs because it is using backticks. I am fuzzy on this, but I think the backticks mean that the stuff in backticks gets evaluated as an expression before the parameter content is read out.
I think the fact that the expression editor gives an error for this, is based on how the expression editor is implemented. I guess it is a kind of bug. On the upside expressions in backticks are typically very short. They are also typically used in the font SOP, where you have a sufficient space in the parameter without the expression editor.

Interesting, I've never tried that, I got used to instantly use the script editor for everything since XSI. I really wanted to understand that expression because, as you say, referencing objects outside the VOPs is probably something I will be doing often. Thanks for the help!

Well, I can confirm as long as the script is not used in the expression editor everything works peachy….must be a bug.

My understanding is that op: is used the same fashion that you might use file// in Google chrome instead of http:. It helps to communicate to the underlying code that you want to use a file that exists within Houdini rather than a file on disk.

It's worth remembering that you can navigate Houdini through the textport the same way as you would a shell in Linux. cd /obj for example will navigate you to the obj network in that textport. So when you use op: you are telling Houdini to navigate to that node in the internal Houdini file system.

So an ideal place to put it, for example, would be on the “Get Attribute” vop inside of a compositing network. In this context, the Input options are File, or First through Fourth Inputs. The input options are useless if you want to read an attribtue from the SOP context, so this leaves you with using a File. You *could* write your SOP to disk, and read in a bgeo file, or you could use op: to navigate to the node in Houdini that you want to read rather than a bgeo file on disk.

As opinputpath() allows you to go several levels up, you could have a vop, inside a cop, inside an object level hda, reference a sop, inside an object that is plugged into the hda.