duplicate objects with vex

[-HEAVY-]

VEX is relativly nu to me, even when I am familiar with mel and some other programming languages.
So be Patient with me and dont make it to complicated

At the moment I am creating a brickwall with a few for each Loops and I thought, hey those simple
transformations can even be done in a wrangle.

but all those point creation and create geometry with vex tutorials doesn't take into account when
there is an incoming prim or box that should only be transformed - so i am more confused now.

can somebody give me a short forloop example to move and duplicate a box, when the box is piped into the wrangle?

thx
deHeavy

[f1480187]

You need to recreate everything from scratch by looping over geometry entities.

// Detail wrangle.

// Compute new position based on copy number and translate parameter.
vector copypos(vector pos; int copynum; vector copyt)
{
    return pos + copyt * copynum;
}

for (int copynum = 1; copynum < 5; copynum++)
{
    // Copy point cloud from input.
    for (int i = 0; i < @numpt; i++)
    {
        addpoint(0, copypos(point(0, "P", i), copynum, {2, 0, 0}));
    }

    // Copy primitives to new points.
    for (int i = 0; i < @numprim; i++)
    {
        int new_prim = addprim(0, "poly");
        foreach (int pt; primpoints(0, i))
        {
            int new_pt = pt + @numpt * copynum;
            addvertex(0, new_prim, new_pt);
        }
    }
}

It's a waste of time, if you have no good reason to do such thing. Computing transform attributes on copy points with VEX and then copying input geo with Copy node is a more straightforward way.

vex_duplicate.hipnc

Edited March 25, 2017 by f1480187

[-HEAVY-]

thx f1480187 for the effort, but seems a bit overkill to me.
Konstantin over at Sesi-Forum provided me with a much slicker version.
 

vector offset = chv("offset");
int copies = chi("Copies");
int prim_pts[] = primpoints(0, @primnum);

for (int i = 0; i < copies; i++) 
{
    int add_prim = addprim(0, "poly");
    
    foreach(int pt; prim_pts) 
    {
        vector pt_pos = point(0, "P", pt);
        vector offset_Mult = offset * (i + 1);
        int add_pt = addpoint(0, pt_pos + offset_Mult);
        addvertex(0, add_prim, add_pt);
    }
}

but yes i think doing all that create prim, foreach point in prim - create points, create vertex , is maybe a bit much when it comes to bigger scenes.

 

[f1480187]

The slick snippet copies primitives N times working in Primitive mode. This is faster than copying connected geometry when operating on Detail level: 3.5 vs 4.5 seconds for 500 Pigheads. But if you use Fuse after that, you will wait another 13 seconds. Not a big deal, but you can fuse something that shouldn't be fused, like, neighboring bricks ideally aligned with each other, or disconnected points which wasn't fused intentionally. And Copy and Transform node did whole stuff for 0.5s, 7 to 9 times faster than VEX!

On real task, you may want to copy some attributes on the copies. You will have to keep track of entity numbers, manipulating arrays of integers and managing counter variables. It can be painful and hard to debug. Computing copy transformations will grow quickly too. If you don't generate something (see a good example of such generator asset), I see no reason to duplicate geometry with VEX, it's slower, more difficult, and more limited than using Copy when possible.

[-HEAVY-]

Yeah, as i said, i got the point. Its a waste of time and resources with not much flexibility. Its better to vex the point and use copys or instances. 

How do you measure all that performance, I dont belive you take a stopclock for that..? 

[f1480187]

Use Performance Monitor for proper testing. It's a great profiling tool. Press "Record", make something to cook, then stop recording and inspect what was going there. It's very artist-friendly, you can learn it in five minutes.

For quick looks, press MMB on any node and see Last Cook timer. For simple comparisons, I usually Merge nodes and make a non-critical change in common upstream node, like, rename it. So, all Merge's inputs will cook in same time and with similar conditions. For some reason, Houdini shows node' own cook times, which usually a fraction of milliseconds for non-atomic subnets and assets. You need to dive inside. For example, to see actual cook time of Wrangle, dive inside it and MMB on it's Attribute VOP node.

Always make computationally heavy tests. Seconds or even minutes. Comparing milliseconds is prone to temporary anomalies and caching stuff. Also, it's good practice to do several tests with different conditions. Changing load in linear way can affect cook times in non-linear manner.

By the way, sometimes drawing heavy geometry in viewport takes more time than actual cook. Performance Monitor shows viewport statistics too.

[-HEAVY-]

Greate, thx a lot.  I really have to dive into Performance Monitor.

heavy likes heavy Tests