are these VEX known bugs or i am missing something?

DOCUMENTATION SAYS:

As of Houdini 12, you can define new structured types using the struct keyword.

AND

you can declare a function which can returns an array.

BUT:

This is an old issue, I submitted in April 15 2014:

Wrangle SOPs do not allow functions that return an array

The developers said:

“This is a problem with the current VEX grammar that doesn't allow array functions inside of functions.

It also isn't allowed in the attrib vop, in your file what is happening is the outer-code section is being abused to define a function, something that will crash and burn when you cut & paste that node.”

Hopefully with the stellar array support in H14, this will be added

in your file what is happening is the outer-code section is being abused to define a function, something that will crash and burn when you cut & paste that node."

if you mean “code” instead of “node” at the sentence end (cause i didn't cut & past any node):
actually first, i wrote it letter by letter. same thing happened. i copied and pasted the exact documentation example to say that everything is completely sidefx fault.

Hopefully with the stellar array support in H14, this will be added

technically this is not our big problem even now. there is a simple workaround.
we define array before function call. and pass it as an argument to the function.

what does suck is struct type definition failure. it is a good tool for code management when code size gets bigger and bigger.
at H14 new features sidefx mentioned “Expanded support for structs and classes”, while we can not find anything related to classes. search class keyword in the VEX documentation. :x

sometimes i think some features implementation is not completely complete to be sure enough every thing works flawlessly. they use it internally but abandon us at the entrance, to prevent some future incompatibilities, and when they got happy with the feature then say to us, here you are.
but give me the right to use of the feature which has been announced at H12.

sorian
what does suck is struct type definition failure. it is a good tool for code management when code size gets bigger and bigger.

When code management size gets bigger, one might want to consider separately maintaining the VEX code rather than as wrangles in a scene file. (eg. VEX SOP). I think the problem is that struct support hasn't improved to the point to exist inside functions yet, which is a requirement for all code inside wrangle nodes.

a super fast reply. thanks edward.

and what about class definition?
what you announced at release 14 as class (“Expanded support for structs and classes”) is what we know as classes in an object oriented programming environment?
if it is where is it. where is it's documentation?

sorian
if you mean “code” instead of “node” at the sentence end (cause i didn't cut & past any node):
actually first, i wrote it letter by letter. same thing happened. i copied and pasted the exact documentation example to say that everything is completely sidefx fault.

No SESI meant node because they were commenting on my idea that using AttribVOP with a Snippet VOP where the struct is defined inside the Outer Code section of the node works. But SESI advised against this, because it's abusing Outer Code and is likely to fail.

sorian
technically this is not our big problem even now. there is a simple workaround.
we define array before function call. and pass it as an argument to the function.

what does suck is struct type definition failure. it is a good tool for code management when code size gets bigger and bigger.
at H14 new features sidefx mentioned “Expanded support for structs and classes”, while we can not find anything related to classes. search class keyword in the VEX documentation. :x

sometimes i think some features implementation is not completely complete to be sure enough every thing works flawlessly. they use it internally but abandon us at the entrance, to prevent some future incompatibilities, and when they got happy with the feature then say to us, here you are.
but give me the right to use of the feature which has been announced at H12.

Passing arrays is fine but returning arrays is still not supported in H14. This is an important feature to have. Otherwise we have to return a large string and then use this result in another function as an argument. But you have to split this string, convert to numbers, and create another array before using which has a very large performance overhead.

edward
When code management size gets bigger, one might want to consider separately maintaining the VEX code rather than as wrangles in a scene file. (eg. VEX SOP). I think the problem is that struct support hasn't improved to the point to exist inside functions yet, which is a requirement for all code inside wrangle nodes.

This doesn't help as much IMO. Because storing the code in HDA in Extra Files when you are editing it is not very manageable. If you store it outside, then you have to remember to reload this file each time you make a change. You need the code to be inside the HDA for Orbolt.

If you are talking about File -> New Operator -> VEX -> Geometry, then AFAIK this is still using the SOP context not CVEX which leaves out a lot of nice features, important functions IMO.

If the CVEX variant is added, this provides a great alternative for some cases.

But even then there are other common cases where the large VEX/Wrangle code is part of a network for an HDA that does a very specific thing so not suitable to be a separate HDA.

I do this for my Select Edge Loop SOP where all the calculation is done in a single Wrangle node that creates a string detail attribute that contains all edges (“p0-1, p1-2, …”).

But this result has to be used in a Group SOP since creating/modifying edge groups is not supported in VEX.

I have used the same workflow many times. where this kind of Wrangle node usage is very common for non-trivial HDAs.

ArrayType returning functions are allowed and do work, just not in the Wrangle SOPs (ie. when defined inside the Wrangle SOPs).

But they do work if you define these in an external source file which is then included into your Wrangle SOP using the include directives.

The same goes for structs (custom data structures with member functions are supported) and I really like somethings about this. However the one thing I feel missing is Data persistence with Structs (ie. we cant read the data from another Wrangle node or store these on points as attributes). I have however found some workarounds to those.

Congratulations to the team at SESI! This release is really smashing!

bhaveshpandey
ArrayType returning functions are allowed and do work, just not in the Wrangle SOPs (ie. when defined inside the Wrangle SOPs).

We are talking wrt Wrangle SOPs.

its a bug or i am not able to understand how addattribute in cvex context works, in h13 addattribute worked fine,

Add Attribute VOP and addXXXattribute() VEX functions just create new attribute on the geometry, and the value you are plugging in is the default value of that attribute so it's the same for all
to populate the attribute use Set Attribute VOP

it is useful if you are planning to create and set attribute values for other than current point(, prim, …)

if you however want to always write to current point(, prim, …) use Bind VOP instead

pusat
No SESI meant node because …

oh, ya, i got it.

pusat
Passing arrays is fine but returning arrays is still not supported in H14. This is an important feature to have. Otherwise we have to return a large string and then use this result in another function as an argument. But you have to split this string, convert to numbers, and create another array before using which has a very large performance overhead.

in the ideal vex we should have:

// function declaration
vector
fillTheArray(){
return { {1, 0, 0}, {0, 1, 0}, {0, 0, 1} };
}
// some where inside program body
// …
vector return_array = fillTheArray();
printf(“\n return data: %f”,return_array);

which fails.
so we rely on reference type argument passing of vex functions, which holds variables updated, after function call.

// function declaration
void
fillTheArray(vector return_data){
return_data = { {1, 0, 0}, {0, 1, 0}, {0, 0, 1} };
}
// some where inside program body
// …
vector return_array;
fillTheArray(return_array);
printf(“\n return data: %f”,return_array);

so i don't see any need for returning string and do some splitting and reverse converting to get to our original data type.
doesn't this trick fit your cases?

pusat
You need the code to be inside the HDA for Orbolt.

what ‘edward’ mentioned about using a vex DA beside what ‘bhaveshpandey’ told about including an external file, are good workarounds for in house developments.
but these workarounds don't serve well for commercial DA developments. cause, inside code section of outer body of our vex DAs and even Python DAs in locked commercial assets, we always have codes visible, according to my hearsay. i didn't check it myself yet. (correct me if i'm wrong).
this simply decommercializes every heavy commercial work when delivered on orbolt.
so no heavy work happens. or we should find some hackish ways which makes difficult and some times impossible to get good designed programs.

actually IMHO this is a big pitfall for orbolt growth, which should be addressed by SESI as soon as possible. orbolt service is about 3 years old now. so hiding written codes is an initial necessity, which must be there.
houdini has a vast amount of tools for doing every cg related development better than every other package which helps us in the best way. but at the end sidefx prevents us to do crossing the finish line.
so SESI either set at your top priority, addressing wrangles mentioned issues or do something about hiding the codes.

i don't think making codes invisible in locked assets be very difficult task.
my suggestion:
just colorize the text same as background color, and make the text field inactive. this way you prevent selecting the codes and make them invisible.
sometimes limitations force us to be more creative and find more tricky ways of doing things.:wink:

————-

i really don't like to see this error flag again on below file vop sop.
and do see structs have been attached to the points without doing any hack.

@tamte
thanks for the explanation

Let me show you my point of view on locked assets in commercial pipeline.

From various reasons (security, maintainability, bug fixing, unguaranteed support from original asset creator on Orbolt etc.) I'm strongly against locked black-box assets in any pipeline.

I don't mind trying free locked version and then buy source code access for full version or buy commercial plugin from well defined entity with clearly defined support.

Simply connecting black-box assets to any pipeline with short turnarounds and ability to deliver in time is risk that doesn't worth it at all.

'pezetko'
i am attune with you, in some degrees, not completely

pezetko
From various reasons (security, maintainability, bug fixing, unguaranteed support from original asset creator on Orbolt etc.) I'm strongly against locked black-box assets in any pipeline.

these issues are imaginable for every piece of software and every plugin, from plugins with short development cycle, developed by indie developers to big products developed by big companies. as an example just look at what happened to that big product, softimage, by the most monstrous CG company behind it, AD. the biggest unguaranteed support ever.
so don't blame orbolt for these. these are explainable issues for every software product, which have their own solutions. this is the reason why different software developers, have different ranks in the industry.

pezetko
I don't mind trying free locked version and then buy source code access for full version or buy commercial plugin from well defined entity with clearly defined support.

Simply connecting black-box assets to any pipeline with short turnarounds and ability to deliver in time is risk that doesn't worth it at all.

it depends on the type of the work and the studio your working in.
full control over the pipeline, is the reason why ‘disney’ makes it own in house renderer ‘Hyperion’ for rendering ‘big hero 6’, while mantra performs well and they have access to it surely.
but at the same time there are small houses to even individuals which haven't an army of developers that mantra performs very well for them (i haven't forgot big studios use it too )
although this is a large scale example, but can describe the assets usage percentage differs, based on the type of the users, from indie artists to big production houses and quality of the asset.

being black_boxed, sometimes matters, and sometimes doesn't matter.
in later case, eg. by every H version vex\cvex growing ( and by future accessing to those H14 hidden class type definitions ), one might want to write a cloth solver. here judgment, about quality of the solver is based on speed, stability and quality of the solve. if asset tester got satisfied, then would be a customer. who wants accessing to the codes of a cloth solver for optimizing it's simulation and how many can do it?

but for some types of assets, i am in your side, being black_boxed is equal to asset unusability.