# julian johnson

Members

29

• #### Days Won

5

julian johnson had the most liked content!

36 Excellent

• Rank
Peon

• Name
julian
• Location
london

## Recent Profile Visitors

582 profile views

1. ## Define a function in point wrangle

// // VEX Code Generated by Houdini 16.5.268 // Date: Sun Jan 28 16:23:25 2018 // File: C:/Users/johnson/untitled // Node: /obj/geo1/attribwrangle2/attribvop1 // #ifndef VOP_OP #define VOP_OP #endif #ifndef VOP_CVEX #define VOP_CVEX #endif #pragma opname attribvop1 #pragma oplabel "Local Vop Code" #pragma opmininputs 1 #pragma opmaxinputs 1 #include <math.h> void _obj_geo1_attribwrangle2_attribvop1_snippet1(int _bound_test[]) { function int[] test() { int result[] = {1,2,3}; return result; }; _bound_test = test(); } cvex obj_geo1_attribwrangle2_attribvop1(export int test[] = {}) { // Code produced by: snippet1 _obj_geo1_attribwrangle2_attribvop1_snippet1(test); } Looks like a nested function when you expand the inner VOP node to VEX...
2. ## Define a function in point wrangle

I found this in the documentation: http://www.sidefx.com/docs/houdini/vex/arrays.html Not sure what a BNR is :-)
3. ## Define a function in point wrangle

function int[] test() { int result[] = {1,2,3}; return result; }; i[]@test = test(); I get syntax errors using the 'normal' array syntax in the documentation i.e. a simple int[] test(){}; but if you disambiguate using the 'function' syntax it seems to work..
4. ## get UV on curve by arclen in VEX

I think using primuvconvert() now that it has been fixed in 16.5.323 you can go one better in that primarclen() only worked on nurbs and bezier curves. Using primuvconvert() you can get an arclength from u for all curve types including polygonal curves AND you can use it to go in the other direction i.e. get a U value for a given arclength: //get arclength from u f@lenC = primuvconvert(@OpInput1, 1, 0, 8)[0]; //get U on curve using arclength f@u = primuvconvert(@OpInput1, @lenC, 0, 10)[0];
5. ## Help with the Cube Man

Again, I think this is probably too different to the setup you're working on but it's one way to scale and rotate the underlying polygons (which you can polyextrude into cubes later). For rotations you'd need to decide on the basis about which all transforms should take place. It was quicker to implement by using pack/unpack but I'm not sure that's the most efficient way.. cube man.hipnc
6. ## Parenting at geometry level

This is not particularly parametric, a template or procedural so probably useless! But here's a vex driven cube wrap using hierarchical matrices. Might be a little help... parenting_cube_example.hipnc
7. ## Orient Along Organic Surface?

vector bbox = relbbox(0, @P); int prim = point(0, "copynum", @ptnum); float height = sqrt(primintrinsic(1, "measuredarea", prim)); float range = ch("range"); float range_div2 = range * 0.5; float x = fit01(bbox.x, range, 1-range); float y = fit01(bbox.y, 0, 1); float z = fit01(bbox.z, range, 1-range); @P = primuv(1, "P", prim, set(x,z, 0) ); @P += prim_normal(1, prim, set(range_div2, range_div2, 0)) * y * (height * ch("mult_height")); @Atom if you fit between range and 1-range it scales from the centre.. @galagast didn't realise you'd already solved it!
8. ## Orient Along Organic Surface?

Really great, educational stuff on here - thanks to everyone for sharing. I've been trying to look at the flow problem on its own i.e. the fact that primuv is dependent on the winding order of the underlying poly and hence the direction of the fitted object is hard to control (without changing that winding order). Here's a scene that uses anim's (amazing) setup from the linked thread and some additional flowlines to try and conform the fitted geometry to a flow that snaps to the polygon directions. Some very, very coarse coding going on but with some more love (and optimisations) it might make for a nice hybrid. It's very slow at the moment probably because of the copy stamping! flow fit.hipnc
9. ## Python beginner - selecting all nodes of specific type

node_type = hou.objNodeTypeCategory().nodeTypes()['bone'] for x in node_type.instances(): print x Using instances() should give you the bone nodes in the scene..
10. ## Dynamics on growing curves

I think it's better to make the loops post sim and just offset and slide everything there. Here's a scene that shows how to do that. dynamic_tree_grow_help_03d.hipnc
11. ## Dynamics on growing curves

For wire constraints the name attribute on the points should match the name of the wire object in the DOP. To actually see the constraints in your network you need to rename the name attribute on the constraint points to something like 'wire' (instead of 'anchor' and 'root pts'). You then need to make sure the wire object in the DOPNET is also called 'wire'. Once you do that you'll see the constraint icons. However, I think you might have merged a load of lone points in your merge3 node. These are referenced later on as anchors but they look like free floating points (i.e.not part of any primitive) so they just sink with gravity. Has the animation changed since the first iteration? It looks like branches slide up crossing many anchor points now which might be tricky (I think in previous versions the branches were always anchored to a fixed point)... dynamic_tree_grow_help_03a.hip
12. ## Dynamics on growing curves

I tried this one, too, but could only come up with a post-simulation solution. I originally tried converting the constraints to polylines but that didn't give me any options for an offset. In the process of doing that I was experimenting with capturing sourceprim and sourceuv values on the constraint network. Ultimately, I used those attributes post simulation to offset the branches to the correct position. dynamic_tree_grow_help_01.hip
13. ## inherit velocity RBD Packed Object

That's a great new feature. Far less elaborate than before. So, now as long as you set the initial state to active 0 and animated 1, you can switch to active at any time, turn off animated via attribute transfer in SOPS and the objects will inherit velocity at any frame. test_active_velocity5.hipnc
14. ## inherit velocity RBD Packed Object

Ah. OK, I think I now see what you mean. Matt Estela's done a great example of what I think you mean here: http://www.tokeru.com/cgwiki/index.php?title=HoudiniDops#RBD_inherit_.40v_and_.40w_after_initial_frame I had a go on my own, too, and this seems to work as well. test_active_velocity4.hipnc
15. ## inherit velocity RBD Packed Object

Not sure I've understood your scene so take this with a pinch of salt. But, it looks like you're trying to transfer both the velocity attribute and the active attribute of the active object to the inactive ones. To do that I calculated the velocity on the active object using Trail SOP and then in the attribute transfer in the solver also transferred the velocity. Probably not what you meant! test_active_velocity3.hipnc
×
• Donations