Hi everyone,

I created a ramp COP and I want to use it as a texture map. But it looks like any VEX shader I use wants me to give it a file name of an image on the hard drive. Isn't there a way to reference the COP image like we used to in older versions of Houdini?

Thanks!
Christine Smith

Hi Christine,

Yes, one can still reference COPs for textures. The expression isopimg/img1/Operator_name
I tried the above with both SHOPs & VOPs.

Cheers!
steven

that's something ive always wanted to know too, thanks

Thanks! I knew it had too be something simple!

There's something mystical going on with this method.

Seems like this technique has some problems with CopySOP. Try rendering the ShaderSOP and then CopySOP in the scene I've attached. ShaderSOP produces an textured object but CopySOP renders black.

I also get an error when rendering another scene: “Unable to load texture ‘opimg/img1/my_texture’”. However textures appear to be in place in the rendered image with operations done in COPs. And they render nicely even with CopySOP.

The japanese section of the forum had some discussion about this noting that there had been problems on loading textures in past versions of houdini. Have they come back or is this again about my blindness to my own negligence ?

1. The bogus error message is a known bug. Ignore it.

2. The reason your file doesn't work is because you've got the inputs to the copy sop reversed.

3. You can reference the image in COPs as simply Rainbow.pic, without any path qualifications, and in fact you should do this - that makes it easier for Houdini to find the built-in images. Your file as it stands didn't render for me because (among other things) it couldn't find the texture image file, since I didn't have it at ./houdini/pic/Rainbow.pic

… and just for fun, did you know that the URI-type location constructs such as op… also extends into HTTP and FTP?

Try this in a texture map field:

http://www.sidefx.com/templates/images/top_nologo_1.jpg [sidefx.com]


I believe you can even load OTLs and such directly over http either by listing http addresses in the OPlibraries file or when loading directly with otload, so it may even be theoretically possible to have a intranet (or internet) webserver serve out OTLs to clients. Another idea for an extension to the Exchange?

I think this is a pretty cool thing, if only we used it..

craig
2. The reason your file doesn't work is because you've got the inputs to the copy sop reversed.

I can't believe this..how in the hell have I managed to even stay alive this long when I obviously could easily use smith & wesson as a tea spoon without noticing anything..

3. You can reference the image in COPs as simply Rainbow.pic, without any path qualifications, and in fact you should do this - that makes it easier for Houdini to find the built-in images. Your file as it stands didn't render for me because (among other things) it couldn't find the texture image file, since I didn't have it at ./houdini/pic/Rainbow.pic

Thanks, good to know.

Jason: That's neat!

stevenong
Hi Christine,

Yes, one can still reference COPs for textures. The expression isopimg/img1/Operator_name
I tried the above with both SHOPs & VOPs.

Cheers!
steven

Is there a way to refer to the result of the img1 network? Say I wanted to continue to work on the texture without editing the expression.

just append the Null COP and name it however you want, like “OUT”
and reference that in your expression
then just continue editing your cop network making OUT always the last node or always connect to it what you want to send to your expression

Sure! Appending a OUT-null on the end of the comp is one way to do it. I wonder if there is a sligthly more flexible way to refer to a comp result. Would it be foolish to expect opimg/img1 to return the result of img1? What's the logic behind it not returning that?

Elias Ericsson Rydberg
…I wonder if there is a sligthly more flexible way to refer to a comp result. Would it be foolish to expect opimg/img1 to return the result of img1? …

I doubt that is more flexible on top of that it would be certainly much less safe way to do it

for example in SOPs you can do it, referring to geometry from Object just by referencing the Object itself like /obj/geo1
that is very unsafe since returned geometry is highly dependent on the display/render flag (sometimes you may want that, but still unsafe since you need to keep in mind not to play with the flags)

the same would happen if referencing on COP result worked just by referencing the COP network, It doesn't work probably because you can set display flag on more than 1 COP node and what do you consider result of the COP network then?
But even if it did work that way I would avoid using it for the very same reason
Nulls as a certain output point are very reliable and more flexible since you can reference many different stages from the same network

If i try to referance a node like

/img/comp1/OUT_BUMP

In arnold the renderer gives me the error

/mat/arnold_tabletob/image1: Invalid image file "/img/comp1/OUT_BUMP": Image "/img/comp1/OUT_BUMP" does not exist. Also, it is not the name of an image format that OpenImageIO recognizes.

Is it that this method doesn`t work ?

Is it that this method doesnt work in arnold ?

Or is it that I`m making a mistake somewhere ?

TangheStudent
Is it that this method doesn`t work ?

Is it that this method doesnt work in arnold ?

I don't know if it's supported in arnold, but it were, it still needs the prefix:

op:/img/comp1/OUT_BUMP

Unfortunatly arnold stil throws me.

/mat/arnold_tabletob/mat/arnold_tabletob/image1: Invalid image file "op:/img/comp1/OUT_BUMP": Image "op:/img/comp1/OUT_BUMP" does not exist. Also, it is not the name of an image format that OpenImageIO recognizes.


EDIT; its probably the missing `*` i wil try at a later time and c if that fixes the issue.

TangheStudent
Unfortunatly arnold stil throws me.

/mat/arnold_tabletob/mat/arnold_tabletob/image1: Invalid image file "op:/img/comp1/OUT_BUMP": Image "op:/img/comp1/OUT_BUMP" does not exist. Also, it is not the name of an image format that OpenImageIO recognizes.

It's possible it's not supported by arnold then. Textures will need to be written to disk first in that case.

For some reason for me it works in the viewport, but not when rendering to mplay or disk. So, basically, does not work.