And just to be sure, I double checked, in regard to using the ‘$’ symbol for the names of the parms passed into the function with the Inline VOP, it seems to make no change in the resulting VEX file.

I tried it with a VOP network containing some 4 Inline VOP's (all calling functions from a single include file), and I diff'd the generated output with and without using the $'s for the params, no difference … except the time stamp of course.

Can you cite an example of how this is supposed to work?


–Mark

xionmark

Mario Marengo
hold on…

panic delivery!…..

l8r…

Huh???

:?

Hehehe…. In “production-talk”, that means “Hold on; the client just called saying they moved their shipping date one day earlier and you gotta deliver in 1hr if you want to make FedEx”.
Anyway… tape's out; all's good.

So,,,, like; DUDE!! :shock: – I just noticed the version number you posted : 6.0.383 (!)
I'm using 6.1.128 (!!) – get with the times, will'ya!?
Which of course means we might be talking in circles here…. I don't think I had started writing VEX shaders yet back in 6.0.383 so I can't recall how things were then, or if things might have changed since; but they likely have

xionmark
OK, you're gonna love this. Houdini doesn't seem to like when there are more than one include file in a VOP network. It only generates one #include statement, see below. Yet, I have one function, f1(), in one include file, and the second function, f2(), in another file. Of course, when both functions are contained in a single file, all's good. Looks like a bug to me. Can't think of any reason why you'd be limited to including only a single file.

Yup. I can reproduce that in 6.1.128. I'd call that a bug – I'll let you submit it.
I'm including 2 different files from two separate inline vops (and using both vops in the network to make sure they are cooking); and yet only one shows up in the temporary vfl dump (and obviously, the vop manager generates an error).

Go forth and submit! 8)

xionmark
Also, the error message for the above problem with multiple include files is a bit misleading
Wouldn't it be clearer if the first line mentioned that is was unaware of the symbol “f2”?

It does in my version: “Undefined symbol…”
Although the message “A value type of ”void“ …” seems to be the last-ditch message that VEX turns up with when things stop making sense to it. I'm starting to equate it to the more familiar “Confused by earlier errorrs… bailing.” message from g++

xionmark
And just to be sure, I double checked, in regard to using the ‘$’ symbol for the names of the parms passed into the function with the Inline VOP, it seems to make no change in the resulting VEX file.

It does in 6.1.128…


Gentlemen; start your downloads!

Mario Marengo
Hehehe…. In “production-talk”, that means “Hold on; the client just called saying they moved their shipping date one day earlier and you gotta deliver in 1hr if you want to make FedEx”.
Anyway… tape's out; all's good.

Go forth and submit! 8)

Oh .. I thought it was the *Pizza Guy* or something …

Yep, I'm still back in 6.0, I figured I'd upgrade soon, but I have been bitten by getting on the beta train a little early in the past … Suppose I could try and see though.



–Mark

Mario Marengo
It does in 6.1.128…


Gentlemen; start your downloads!

Interesting … I'll give it a try.

I'm hesitant to use 6.1.XXX though with the problems with the OTL's, or has that been fixed?


–Mark

OK… So I downloaded 6.1.128, and I get same results, I don't see any difference when using the $param format and when I don't. From reading the description, it should generate subroutines or something to give each inline VOP it's own scope, right?

Here's an image of a VOP net I'm using to test:
http://www.digitalcinemaarts.com/dev/debug/VOP_test.jpg [digitalcinemaarts.com]

Here's the .vfl it generates:



//
// VEX Code Generated by Houdini 6.1.128
// Date: Mon Sep 29 15:14:29 2003
// From: /vex/test_vex (my_vex_test_215.hip)
//

#define VOP_SHADING
#define VOP_SURFACE

#pragma opname test_vex
#pragma oplabel test_vex
#pragma opmininputs 0
#pragma opmaxinputs 0
#pragma label val1 Value1
#pragma range val1 0 1
#pragma label val2 Value2
#pragma range val2 0 1


#include <./houdini/vex/test_vex1.h>

surface
test_vex(float val1 = 0.1;
float val2 = 0.1)
{
int bound;
int bound1;
float test_out1;
float test_out2;
float sum;

// Code produced by: val1
bound = isbound(“val1”);

// Code produced by: inline1
test_out1 = f1(val1);

// Code produced by: val2
bound1 = isbound(“val2”);

// Code produced by: inline2
test_out2 = f2(val2);

// Code produced by: add1
sum = test_out1 + test_out2;

// Code produced by: output1
Af = sum;
}




No matter if I use the $param format or not, the resulting code is the same. Can you tell me what I'm doing wrong?

Thanks!


–Mark

xionmark
No matter if I use the $param format or not, the resulting code is the same.

In some cases it is…. and in some cases it isn't…. depends on what else is going on…

For example: follow your “inline1” with a copy of itself (insert it in the chain immediately after the current one). Pop up the “View code” window. Now switch between “f1($val1)” and “f1(val1)” and hit “refresh” on your code viewer. See the diff?
I'm still wading through all the implications of #includes and $'s in VOPs myself – and I hadn't really used the inline vop at all ‘til you brought it up :shock:
From within the vex manager, the ’$' operator seems (IMO) to translate into “unique to the local scope” – and since there's really only one scope, it goes as far as creating a new var behind your back to enforce this

Oh boy … this is not good …

I see this difference now, the variable names being passed to functions are being renamed! This isn't establishing “scope” at all! I thought for sure I'd see extra bracing, maybe some automagic function declarations, etc., but all that's happening is name space modifications to avoid symbol collisions …

This breaks all kinds of things … hardly know where to start … this is not good …


–Mark

Oh boy … this is not good …

I see this difference now, the variable names being passed to functions are being renamed! This isn't establishing “scope” at all! I thought for sure I'd see extra bracing, maybe some automagic function declarations, etc., but all that's happening is name space modifications to avoid symbol collisions …

This breaks all kinds of things … hardly know where to start … this is not good …


–Mark

xionmark
Oh boy … this is not good …

but all that's happening is name space modifications to avoid symbol collisions …

This breaks all kinds of things … hardly know where to start … this is not good …

Alright; that's enough coffee for you

But seriously… well… they *have* to avoid collisions at all costs, don't they? And given that VEX doesn't really have “scopes” or namespaces (functions are scopes, but blocks within functions aren't), this is likely the best that can be done at the moment…

Overall; I'd say use the Vex Builder for combining already existing VOPs (stay away from the inline vop). And if you want to make a new VOP, then use raw vex (that's with a *v*, you pervert ) – I've been writing all vops in vex, as you can at least have *some* control over the immediate environment of the vop itself (if not of the other eeeeevil things that may lurk around it).

Mario Marengo
Alright; that's enough coffee for you

But seriously… well… they *have* to avoid collisions at all costs, don't they? And given that VEX doesn't really have “scopes” or namespaces (functions are scopes, but blocks within functions aren't), this is likely the best that can be done at the moment…

Who me caffienated? :-)


Yep, they *do* need to avoid name collisions, but it's pretty darn easy to declare (in this case) the Inline VOP as a function unto itself, where it maintains the same names of it's arguments and return values, and establishes true scope.

Did you notice by chance what happens if you don't use the $param format? No name changes occur, *assuring* collisions, and there's no error raised in the VOP builder to notify the user of the mistake, much less prevent it from happening.

Overall; I'd say use the Vex Builder for combining already existing VOPs (stay away from the inline vop).

No way Man!

I needs my Inline VOP!!! Gotta get to the code directly …

And if you want to make a new VOP, then use raw vex (that's with a *v*, you pervert ) – I've been writing all vops in vex, as you can at least have *some* control over the immediate environment of the vop itself (if not of the other eeeeevil things that may lurk around it).

raw vex …

Yea, I've trying to “catch up” with all the new stuff you can do with VOP's and OTL's, but I don't feel as comfortable doing that quite yet.

Well, darn it all, I'll add that to my list of RFE's for VOP's, have about 5-6 of them, been spending a lot of time build VOP nets the last few weeks and found some things that really slow down workflow.

But this scope issue to me is fundamental to the design of VOP/VEX, it really limits me. Looks like it's time for an HDK implementation instead …

Having found no real solution to declaring my own globals in VEX, I was looking over the VRAY library and examples. There's an example for a lighting and atmosphere shader but nothing for surface and displacement shaders. I'll still keep looking, but would you happen to know if one can write shader functions (or entire shaders) as a DSO, like one can do in prman?

I just got done with a project of converting some 3D Max noise and pattern functions into VEX, but there were a number of limitations that could be easily overcome if I could write it in C/C++.


–Mark

xionmark
Yep, they *do* need to avoid name collisions, but it's pretty darn easy to declare (in this case) the Inline VOP as a function unto itself, where it maintains the same names of it's arguments and return values, and establishes true scope.

Yes; but you still have a potential mess on the assignment side. i.e: depending on if you assign to $test_out1 or test_out1… and the function itself would need to be defined with a $, which also has to be prepended at the call point…

xionmark
Did you notice by chance what happens if you don't use the $param format? No name changes occur, *assuring* collisions, and there's no error raised in the VOP builder to notify the user of the mistake, much less prevent it from happening.

Just in case you didn't know this: you can see compilation errors by MMB on any of the tiles. So if the collisions result in non-compilable code, you should see vcc's screams with MMB – accidental overwriting of a variable would go silently unnoticed, though…

xionmark
Having found no real solution to declaring my own globals in VEX, I was looking over the VRAY library and examples. There's an example for a lighting and atmosphere shader but nothing for surface and displacement shaders. I'll still keep looking, but would you happen to know if one can write shader functions (or entire shaders) as a DSO, like one can do in prman?

Is “VRAY” SESI's api to Mantra in the HDK? – if it is, then ask me again when the HDK comes bundled with the package… I might have a clue then

As far as writing a shadeop for VEX a-la PRMan, yes, of course you can – I've done quite a few and it works great
Plus you get to overload your functions instead of ending up with all kinds of cryptic names like my vex-lib functions.

What are you trying to do exactly?

Mario Marengo
Is “VRAY” SESI's api to Mantra in the HDK? – if it is, then ask me again when the HDK comes bundled with the package… I might have a clue then

Yes, I think so. The html docs that come with the HDK, you can view those without a license. I'm just now starting to look through the Doxygenated documentation of the Houdini API. In the html docs, they still talk about MAT's & TOP's, so I'm not sure which direction to go yet. The VRAY docs only talk about an atmosphere and lighting shader …

:roll: Re: The HDK … Oh boy … don't get me started … arggghhhh :?

What are you trying to do exactly?

Well, I want to keep some values around between calls to the shader, thus the need for “globals” in VEX, and have things like arrays, structs, disk & network I/O, etc.

I'd also like to compare performance between the two, like calling some fairly involved noise and fractal functions in full compiled code instead of “p-code”, .vex files; I can better optimize the functions that way, and I suppose drop down into assembly language where need be.


–Mark

Mario Marengo
Is “VRAY” SESI's api to Mantra in the HDK? – if it is, then ask me again when the HDK comes bundled with the package… I might have a clue then

Yes, I think so. The html docs that come with the HDK, you can view those without a license. I'm just now starting to look through the Doxygenated documentation of the Houdini API. In the html docs, they still talk about MAT's & TOP's, so I'm not sure which direction to go yet. The VRAY docs only talk about an atmosphere and lighting shader …

:roll: Re: The HDK … Oh boy … don't get me started … arggghhhh :?

What are you trying to do exactly?

Well, I want to keep some values around between calls to the shader, thus the need for “globals” in VEX, and have things like arrays, structs, disk & network I/O, etc.

I'd also like to compare performance between the two, like calling some fairly involved noise and fractal functions in full compiled code instead of “p-code”, .vex files; I can better optimize the functions that way, and I suppose drop down into assembly language where need be.


–Mark

I was wrong the VRAY library, I meant the RAY lib.

Hmmm .. a bit of confusion, I think it's version related. Though there's still 2 examples in the toolkit docs about a light and atmosphere shader, the header files for all the RAY lib's classes are null files …

There's now a directory for VRAY, some info and examples on VRAYprocedural (looks interesting) but I can't find anything on writing shaders per se with the HDK. I've got some old docs from ver. 2.5 or so and it's got a some stuff on extending TOP's, MAT's, etc., but I can't find the RAY lib docs yet …

Where'd everything go?




–Mark

xionmark
Well, I want to keep some values around between calls to the shader, thus the need for “globals” in VEX, and have things like arrays, structs, disk & network I/O, etc.

Oh; is that all? 8)
I don't think you need to go HDK for that.

All you need to do is pass some initialization state from VEX to the shadeop (“signed” with some unique id based on the shader instance), and then update/calc/retrieve data from the C++ objects using the same initial id as a calling card. If you can define things in such a way that the VEX side is always the “trigger” for all actions (which is the typical case), then this should work fine.

As a sketch, for storing arbitrary (persistent) data…
Since you could get away with saying that all vex data is just one or more of int, float, or string, then on the C++ side you can keep, say, a global std::map<T_Id,T_VexData>, where T_Id can be a std::string so the user can pass along the name of the instance ($OS) as an id. And where T_VexData is, say, a std::vector<T_TokVal>, where T_TokVal is a std::pair<std::string, std::vector<T_VexType> >. Since you'd only trade in 3 types (int, float, and string), T_VexType can probably get away with being just an abstract base for a simple traits-like template with only the three specializations.
The shadeop interface forces everything to void*, so all set/get operations on T_VexType can be generic without much pain – i.e: you're being forced to cast everywhere anyway…

The only question is whether something like that would play nice with the SIMD architecture, but I've used a similar setup with PRMan before (which is also SIMD) and have had no problems.

Mario Marengo
The only question is whether something like that would play nice with the SIMD architecture, but I've used a similar setup with PRMan before (which is also SIMD) and have had no problems.

Right! SIMD has messed up things like disk I/O, but I think in this sense it'd be no problem at all … unless … (and here is where I kind of started this whole thread from …) I need to keep data in my “globals” that needs to be processed in a defined, sequential manner, then SIMD will be a problem. But hey, that's what the HDK is for eh?


–Mark

xionmark
… unless … (and here is where I kind of started this whole thread from …) I need to keep data in my “globals” that needs to be processed in a defined, sequential manner, then SIMD will be a problem.

Hmmm… I still don't see a problem.

Just buffer your data and process in bursts.

What I mean is that if you must process A through D in the sequence A B C D, then nothing gets done until A is finished, even if SIMD has graciously completed B and D for you.
Even if the data is an unstructured stream (doubtful), you can probably still impose enough linearity to be able to process in buffered “chunks” or “buckets”….
… just a thought.

Mario Marengo
Hmmm… I still don't see a problem.

Just buffer your data and process in bursts.

What I mean is that if you must process A through D in the sequence A B C D, then nothing gets done until A is finished, even if SIMD has graciously completed B and D for you.
Even if the data is an unstructured stream (doubtful), you can probably still impose enough linearity to be able to process in buffered “chunks” or “buckets”….
… just a thought.

From what I recall, and it has been some time, when I would try to write data out to disk, it was never in the order I assumed, thus the need to write the plugin with the HDK instead of as a VEX DSO. This is when I found out about the SIMD nature of VEX, which is OK in some cases, but not always. These were CHOP VEX DSOs not shader operations, I was really surprised until I found out about the SIMD nature of VEX, then it made sense.


–Mark