Hi all,
I'm hung up on what seems like a minor detail –
I'm creating vex code operators and putting them in an .otl file, and I'd like to embed my custom header file inside the otl so I can use #include in my code and keep it internal to the .otl.
Currently I'm adding my header file to the otl's “Extra Files” section and trying to format an #include line to use it, but so far I'm having no luck, I'm assuming it's just a matter of vex syntax. Any help would be much appreciated!

-JS-

Hmmm…wanting to do something similar.

My inlude header is referencing files I have written elsewhere in other directories on my machine.

They are functions I have written for vex in point wrangle nodes that are used in digital assets.

It works fine to reference those functions in external files with something like:


But I am trying to use GridMarkets for rendering and am in the process of waiting for a ticket response from them on how to create the ‘alias’ on their server. ( I know how to do it for Python external files, but with vex the method doesn't translate into something that works ).

So, I am thinking for the long run it would be usefull to know how to embed external files into a digital asset or even a hip file, so that asset/hip file becomes self-contained.

While at the same time retain directory/file structure of where my originating vex functions are.

I might be wrong but there seems be several way's to use vcc to compile your vex code into your hda. If you look under the “Assets” section there are a few command line args related to vex and hda's
http://www.sidefx.com/docs/houdini/vex/vcc [sidefx.com]

-b

Thanks bonsak for the suggestion…

That's actually the source for when I first found reference on using .

I don't see anything else though that would help with my intent; I will have to revisit that section later with fresh eyes just to make sure I haven't missed something.

I found another section that explains how to include an external file in your asset ( which is easy enough to do ), but the how to access that from vex is another story ( if it's possible ).

Accessing embedded files

Once you have embedded files into the operator type definition, you can access these embedded files from many places within Houdini. Geometry or channel files can be accessed from File SOPs or File CHOPs. Image files can be used as texture map files specified in VEX SHOPs. Script files can be accessed from the textport or parameter callbacks using the source command.

To access one of these embedded files, wherever a file name is called for, use the following:

opdefNetwork_type/asset_name?section

For example:

opdefShop/v_clay?DialogScript

To refer to the current operator, use

opdef:.?section

The opdef syntax always accesses the currently used definition for an operator.

You can also access an embedded file from another asset in the same library (.hda file). To do so use:

oplibNetwork_type/asset_name?Network_type2/asset_name2?section

The second operator type should exist in the same library that provides the active definition for the first operator type.

I've also tried making a copy of a digital asset in the hip file ( using the operator type manager ), creating a new operator type name and saving as “Embedded”, then switching to that type and uninstalling the digital asset used to create the embedded version.

I then opened in a text editor the file container the external vex functions that are referenced in the now embedded digital asset and made some changes.

That embedded asset, unfortunately updated its results to reflect the change to the vex functions I made. So it really isn't as “Embedded” as I had hoped it would be.

I thought maybe some of the “–hda” args would be related to what you are trying to do. Not sure though.

-b

Yeah…I looked at that list again today, and some of the “-hda” ones do seem to hold some promise, even one of the other non hda ones.

However, I am not savvy enough to be able to test them out…not really sure what I am doing using them.

But it certainly seems like it could be done considering the different things the vcc can do by reading the descriptions.

Probably a matter of putting in an RFE; For something like a ‘new’ include like
#Include itself already reads in the file, why not just give it the ability to store those referenced files as copies within a hip file, let alone an HDA, and read in from those copies.

Back a couple months ago when the webinar on vex was done it was mentioned ( how I interpret what they were saying ) that they want to develope and promote more use of vex in Houdini in the future.

In my case, I've seen the power of using vex with functions I have written that comprise about 3000 lines of code that make up about 7 seperate functions, that combined together do unique operations I haven't ( if possible ) been able to do with existing network nodes.

And being able to organize that code is a boon for ease of use.

It's greate to be able to only have to look at 5 lines of code in Vex that are basicly functions rather than having the 2k lines in one vex window, let alone having to copy and paste all those lines of code in each and every vex node that might happen to use all those functions.

Makes debugging much easier too, when you have only one function ‘in one location’ being used by many nodes.

Guess I am sounding like I am ranting…think I'm just shaking out how to put together the RFE proposal.