ubcsdelta
Installed yesterday, huge fun for us unhappy Mac users w/o NVidia gpus, please kindly accept my gratitude for making it available for Solaris 😊

However just can't figure out the way to pass point/prim/vertex color properties. Could please someone point me to the right direction?
Thanks 😊

I'd be really interested on this.
Did you find out by any chance ?

hi Ant,
first off you need to choose a point of view (say, your camera position).
Then you need to cast rays from the cam position to every face on your geometry.
If the ray intersects the face you're casting the ray to it means that face is visible.

This is the code (drop it in a Primitive Wrangle):
Note that this works with poly objects only.


p.s.
the number 10000.0 is just a number large enough to cover the distance from the camera to your object , this is because the VEX command intersect uses the lenght of the vector ‘dir’ as max intersection distance.

P.S.
I just realized you wanted a python/hscript version. Uhpss .. Well this is the faster version of that

I've a Python Processor Top node that has to process partitions coming from the input node.
This is what I'm doing :



Now, this all works, the only problem I have is that the node shows all the work items already cooked only when the node has done processing all the incoming partitions, opposed to …
1 - create the work items when it's processing it
2 - mark the newly created work item as ‘processing’ in bright green
3 - … marking the new work item ‘Finished’ when the result data has been written on disk

My question is : how do I show the node processing the new Work Items *while* it's processing them, like for any other TOP node ?

jsmack
Try transforming your blur space into polar coordinates before computing the delta. The logic is the same as for standard motion vectors, transform shading space to screen space before computing the difference.

#include <math.h>
vector latlong( const vector pos ) {
    vector tmp_p = set(pos.x,pos.z,-pos.y);
    float r = length(tmp_p);
    float phi = atan2(tmp_p.y,tmp_p.x);
    float theta = acos(tmp_p.z/r);
    return set(phi/M_TWO_PI,theta/M_PI,r);
}
surface
myshader( export vector motion = {0,0,0} )
{
    vector p1 = getblurP(0);
    vector p2 = getblurP(1);
    vector res;
    int found = renderstate("image:resolution",res);
    if (!found) res = {1,1,1};
    res.z = 1.0;
    p1 = latlong(p1);
    p2 = latlong(p2);
    motion = p2 - p1;
    motion *= res;
}

Jsmack !
This is exactly the kind of ‘spherical mapping math’ I was imagining, but couldn't really implement it at that time.
I'll try this as soon as I've a hour or so. Thank you !

jpparkeramnh
Hi Alessandro!

Did you ever figure this one out?

-Jon

hey Jon,
no , after a couple of days I gave up.
I wonder if the issue is still there in H16.
Did you find a solution by any chance ?

Found !

I'm using this code to add a spare parameter to a node.


It works great but it adds the parameter at the bottom of the folder “Folder”.
Is there any way to change the position of the newly created parameters , say, moving it ‘up’ , or ‘down’, or maybe after another existing parameter ?

Note: I'm not using parmTemplateGroup because I'm not modifying the asset definition. I need to add this as a spare parameter.

jlait
No. You'll need to make a temp volume for this purpose. The clCreateBuffer() is done from the API layer, not from inside the kernel.

Since you are wrapping this in an HDA likely, you can always delete the volume when done. Empty constant volumes don't take any RAM so this should be difficulty in using it, not an optimization issue.

Awesome ! I was hoping for this answer.
Thank you Jeff !

Recently I've been playing with OpenCL Wrangle SOP quite a bit and reeeally enjoying how fast this thing is.
More specifically I've been developing a HeightField Sand Solver that reads the current state of ‘height’ grid , processes it, and writes it out.
At the moment the data i'm copying on the device is the following:
'height' (volume) (Read=ON , Write=ON)
'temp' (volume) (Read=OFF , Write=OFF)

'temp' is a temporary field i need as a temporary data storage but I don't need it as node output. It's only a temporary internal data storage.

I was wondering if there is a way (and any benefit) to create my temporary data, aligned with some other data (in this case the ‘height’ volume) within the kernel and then destroy when the kernel is done.
I believe the OpenCL command to achieve this is clCreateBuffer but I might be wrong, and I wasn't really able to find good examples on how to use it.
Any idea ?

I did some more investigation and renders.
A simple hip file illustrating the issue I'm having is attached below.
The issue seems to be happening looking right and left in the lat-long render, which corresponds to the areas with sudden changes of color in the motion_vectors render below (and the consequent streaky artifacts in the vectorBlur generated by Nuke).

It feels like the vectors should be treated with some spherical mapping math. Did anybody run into this before ?

In the past I've generally used a simple shader like the one in the pic attached, when it comes to render motion vectors, and it works pretty well with a regular camera.

I tried to use the same shader to generate a motion vector pass for a lat-long (spherical shader) render for a VR project, but it doesn't seem to work as expected. The vectors are there but the Vector Blur in Nuke doesn't produce the correct result. Not only the direction of blur is incorrect, but it doesn't seem to take into account the distance from the camera (far objects move slower than closer object, in camera space).

Is there anything anybody can think of that could help me on this ?

Mark,
thank you for the reply man, I really appreciate that cause I've been banging my head on this for a couple of days.
Actually it does make perfect sense that if I am addressing primitive groups contained into the packed disk, of course at some point they have to be unpacked before rendering.
I must admit that I was hoping this would happen as last step before rendering (as I understood from the manual), since (I assume) a packed primitive has to be unpacked anyway before being rendered.

mtucker
One way you could speed up this particular file is to get rid of the sub-target, and instead set a condition on the top level target, using a Primitive Group of @path=*geo0*, and @path=*geo1*. There is still a big slowdown, but not as much because mantra doesn't need to evaluate the style sheets for the primitives inside the packed primitives (the material gets assigned to the packed prims themselves).

In my original setup (the one where I experienced the issue initially : from 5 min a frame to 8+ hours a frame 20% of the frames, and memory crash for the remaining 80%), I initially created a very simple Style, containing just a “set material” to the whole Object.

Anyway, I removed all the conditions and sub-targets in the example hip file too, and I definitely got some improvement.

Frame 100 : 3' 55” (opposed to 6' 20” in the version with target Conditions).

According to what you said, assigning a Style to the object level, would not need Mantra to evaluate the style sheets for the primitive inside the packed prim, so , theoretically, there should be no slow down at all, is that correct ?

mtucker
The basic problem is that style sheets can do just about anything to the materials in your scene. Each primitive inside each instance could in theory have a different material assigned by the style sheet. In such a context, the increased render time and memory usage would be understandable. Unfortunately right now mantra is not as smart as it could be about short circuiting some of these evaluations when the style sheet is not going to set overrides at that level of granularity. This results in excessive unpacking/unsharing of geometry and evaluation of style sheets, which leads to the slowdowns you are seeing.

Ah ! this second part of your reply answered my previous question I guess
I've always wondered why Style Sheets are mentioned pretty much only associated with Houdini Crowd, and now it makes more sense, since agents geometry is apparently light, and the agents never arrive to the million (at least in the examples).

mtucker
At this point all I can do is thank you for the excellent example file, and say that as style sheets mature, their performance is definitely an area we know we need to focus on.

Thank you for explaining Mark, and since there is no workaround to fix this issue at the moment, I am really looking forward for this to happen, hopefully in the next Houdini build.
Maybe in the future Style Sheets can be applied to every attribute / parameter in the setup, opposed to Shading only !

I have a setup constructed this way:

polygons –> packed disks –> instance SOP –> delay load (render)

I'm instancing 9 different bgeo sequences (100 frames each) stored on Disk over a template point cloud using Instance SOP and using a Delay Load shader for rendering.

Everything works great if I don't use Style Sheets.
Render time per frame ~5 minutes, super fast (and above all, as I would expect, the render time is independent from the geometry since I'm using instances).

As soon as I create a style sheet on the object, suddenly the render time sky rockets to ~30 minutes to 8+ hours, and many frames just error out and never even get to start the render.

So I recreated a simple setup to document this behavior:

- Template points : ~ 400 points (20x20 grid)
- 9 Geometry Sequences (cached on disk):
each one is : ~200 polys at frame 1 constantly growing to ~600.000 polys at frame 100

Then using Instance SOP I instance randomly one of the 9 geometry sequence on to the template grid, (via s@instancepath).

This is what the render looks like (no_style_sheet.png attached)

Then I assigned a simple Style Sheet set on the object. (with_style_sheet.png attached)

STYLE SHEET DISABLED (Green Mantra Shader applied):
Render Time:
Frame 001 : 18“
Frame 025 : 19”
Frame 050 : 19“
Frame 075 : 19”
Frame 100 : 18“

STYLE SHEET ENABLED (see style.png attached)
Render Time:
Frame 001 : 40” (2x slower)
Frame 025 : 1' 15“ (4x slower)
Frame 050 : 2' 20” (4.2x slower)
Frame 075 : 3' 54“ (12x slower)
Frame 100 : 6' 20” (21x slower)

From what I understood from the manual :

..Stylesheets can let you change looks without having to edit the geometry or regenerate the scene description (IFD) file. This may be useful for studios working with huge scenes, where a quick tweak with a stylesheet might be faster than regenerating a huge IFD.

Apart from the render time which becomes unmanageable very soon, the big problem I see is that the setup with Style Sheet is no longer independent from the geometry instances. It almost feels like, suddenly we loose all the benefit of instancing, pretty much like if the geometry is unpacked and then rendered.

I'm quite new to style sheets so I wonder if I missed something along the way in this setup.

I attached the hip file below.

note:
I tried even without Delay Load with the same results.

Have you tried to “attach” the fixed point to the object first ?
With the node Point Deform you can “carry” the fixed point along with your object deformation / moving / tumbling. Once your fixed point moves along with your object then you can use the attribute transfer approach.

Of course this would mean that the fixed point is no longer really “fixed”, since it's moving with the object now.

hey Frankvw,
yes I've been banging my head on the casting thing a few times in the past.
In VEX, functions overloading is used massively, so explicit casting is critical.
I'm glad it worked in the end !

hey Frankvw,
assuming your geometry has a certain number of primitive groups and the primitive attribute Cd,
try this code in an Attrib Wrangle SOP set to Detail mode:


// groups array
string groups = detailintrinsic(0, ‘primitivegroups’);

for (int g=0; g<len(groups); g++)
{
// prims array per group
int prims = expandprimgroup(0, groups);
// random color every frame different per group
vector randCol=vector(rand(g*4.2343+@Frame));
// assign random color to all the prims of the group
foreach(int p; prims)
setprimattrib(geoself(), “Cd”, p, randCol, “set”);
}

I'm appending the path where the python module lives via houdini15.0/scripts/python/pythonrc.py

import sys
sys.path.append('…./path')


This works well for me importing external modules into any houdini context , included HDA.

The problem I'm having is that when I update the external module, I have to re-start Houdini to have the HDA pick up the changes.

Is there any way to re-source an external Python module from within an HDA
?

bonsak

mrWolf
Basically an “include” that works at the session level, instead of the node level. I've already asked this question around and never got an answer. I guess it's not possible.

It would be great if that was possible. Maybe you have to make your own plugin (hdk) for this to work though. http://www.sidefx.com/docs/hdk14.0/_h_d_k__vex_op.html [sidefx.com]
EDIT: Not that i know how to do that

-b

Yeah,
OR
A workaround that just came to my mind is simply to save a default preset for the wrangle nodes that always contains an #include line pointing to a certain .vfl file containing, for instance, general purpose functions.
Not ideal, but it should do the job.

bonsak
Hi
Not sure if this is exactly what your'e after but if you put your vfl's anywhere in the $HOUDINI_VEX_PATH or in $HOME/vex/include. Then you can include them in your wranglers:
#include <my_external_vex.vfl>

-b

That's handy, thank you Bonsak.
But I was looking for a way to avoid writing the include statement itself in every Wrangle node. Basically an “include” that works at the session level, instead of the node level. I've already asked this question around and never got an answer. I guess it's not possible.

I am wondering if there is any way to #include a .vfl vex file so that the functions sourced in the file are available in the whole Houdini session. More specifically, in every Wrangle Node. I was expecting to find directions about this in the section “user-defined functions”, in the VEX Language reference in the houdini help, with no luck !