# henderthing

Members

31

8 Neutral

• Rank
Peon

• Name
Matthew
1. ## Need help with loops and Foreach

Been playing with this ever since prototyping a basic version for a crystal card in "the Last Mimzy"... It's also fun to build this way in 3D, filling a cube or volume, and flesh out the wireframe that lives on the resulting edges... Will post a version of that when i get some time... Here are a couple low detail animations from several months ago:
2. ## Stereoscopic cameras from scratch

You can also build L/R functionality into a houdini/mantra or Arnold lens shader. I've done this for both pano (equirectangular) and equidistant immersive lens shaders. Basically, each pixel (or sample, for that matter) is rendered as viewed from a different point in space, calculated by your shader. In the case of the equidistant lens shader, I got around the issue of twisting divergence vectors around the poles by offsetting my ray origin by a fraction of the derivative of my projection ray with respect to image plane x. (This is for a forward facing 180 degree "fisheye" stereo view). It works nicely and while there is some angle/shape to the divergence vector field, it's pretty natural and conforms nicely to the way you would naturally look around within the projection environment... Can't speak to other renderers/cameras... Also thanks to SideFX for granting my feature request a few years ago to make this possible with path tracing!
3. ## Learning VEX via Animated Gifs - Bees & Bombs

Clif- 1. In my network, I create a circle and use the ends sop to get rid of the face (n-gon). The "unroll" option gives you a polyline with coincident points at the start/end. Then I copy it 4 times. This gives me 4 primitives, each of which is an open polyline. I use \$PI/2 * primnum (90 degrees) to initialize the 4 corners of the square cross-section. All the way up to the skin SOP, there are 4 polylines--each one a primitive. They just look like a single curve because of the way I've rotated the points. You can see this by doing something like @Cd=random(@primnum)... So-- there are primitives here-- and they are actually polylines. 2. Yes--but you need to be careful. In the case of a quad poly surface (poly grid, for instance)--each quad will have a vertex at each corner, but each point will be a collection of 4 verts, each belonging to a different poly (primitive). So--in a pointwrangle, which primitive number will you get with @primnum? Guessing here, but probably the lowest one. 3. modulo is super-useful! 4. Trig, vectors, linear algebra, analytic geometry and calculus are all super-useful. And Houdini/vex makes it much easier to get a handle on these things. The reason 1/@numprim doesn't work is that your numerator and denominator are both integers. I'm lazy--and rather than cast them with float(), I just type: 1.0/@numprim. The 1.0 is a float, and you will get a float. There may be a reason for not doing this, but I've never had problems with it. Hope this helps Cheers -m
4. ## Learning VEX via Animated Gifs - Bees & Bombs

Hi Clif- I took a look and thought I'd take a quick stab at this and make a couple comments. No need to "declare" new attributes in a wrangle SOP. That's all handled automatically--you can just go and set your new @myattribute to a value. While copy stamping is no problem for something this small-- I generally avoid it these days as it doesn't scale well. Most of the functionality can be handled much (much!) faster by the fully threaded wrangle SOPs. I built it this way next to your network in the attached file... Cheers -m RainbowRing_02.hipnc
5. ## Learning VEX via Animated Gifs - Bees & Bombs

Doh! Didn't even notice that i double-compensated for anim. corrected version below. but also noticed something else broken that I can't explain (and can't really look into at the moment). At frames 48, and 18 (and, I'm sure, cycle multiples of those), points disappear... hrm. >:-| int pt; vector pos; int total = npoints(0); for (int i = 0; i<total; i++) { float nptnum = 2.0*i/(total); //ptnum, normalized 0-almost 2 @P = fit(i>=50,0,1,ch("inner_radius"),ch("outer_radius"))*set(sin(nptnum*2*\$PI),0,cos(nptnum*2*\$PI)); //vectors-- axis is 2D perpendicular to out vector out = normalize(@P); vector pivot = out*.5*(ch("inner_radius")+ch("outer_radius")); vector axis = set(out.z,0,-out.x); //timing cycles float cycle = ch("cycle_frame_count"); float ramp = (nptnum-@Frame/cycle)%1; //orig ramp is sawtooth w 2 peaks, this creates 1 ramp, and stabilizes anim spatially by subtracting anim float fullramp = 0.5*(ramp+(i>=0.5*total))+.5*@Frame/cycle; ramp = smooth(0,ch("width"),ramp); float angle = -\$PI*ramp; //rotations vector4 rotq = quaternion(angle,axis); @P-=pivot; @P= qrotate(rotq,@P); @P+=pivot; //new prim pt = addpoint(0,@P); int newsphere = addprim(0,'sphere',pt); // map fullramp to hue float hue = (fullramp+ch("hue_offset"))%1; vector color = hsvtorgb(set(hue,1,1)); setprimattrib(geoself(),"Cd",newsphere,color,"set"); matrix3 m = ident(); scale(m,0.03); setprimintrinsic(0,'transform',newsphere,m); int newprim = addprim(geoself(),"polyline",pt,pt+50); }

7. ## Learning VEX via Animated Gifs - Bees & Bombs

Just tried to do everything but the dots in one node. It's next to your network. While we can create points in a wrangle, we still need an input geometry--so I just used a point generate sop. So--two nodes plus the two more that would be needed to finish the job! ;-) Cheers One_node_twist.hipnc
8. ## Learning VEX via Animated Gifs - Bees & Bombs

I've uploaded a simple way to make a perfect sphere this way. I made no attempt to match original proportions, etc. Just to demonstrate some principals. VEX is commented. I broke the @P.y out into separate lines so that you can comment out the lines at the end to see what each step does. As for simple flat color like this-- use the "old" Constant shader in SHOPs I've done that in this file, and assigned color via the prim wrangle sop. Cheers -matt b_and_b_cubewave.hiplc
9. ## Learning VEX via Animated Gifs - Bees & Bombs

While we're at it... One more--less directly lifted from B&B. Just my take on a concept: bees_and_bombs_dotspirals.hiplc
10. ## Learning VEX via Animated Gifs - Bees & Bombs

nice thread! I've been an admirer of beesandbombs for some time. Couldn't resist... I think, I'm pretty close to this one: https://beesandbombs.tumblr.com/image/161819595524 I suppose I cheated a bit by not generating my own circles--but I didn't feel like it, so there! bees_and_bombs_spiralSpheres.hiplc
11. ## Nearest single point ID to attribute

I'd be interested in better understanding this as well. For instance: What, exactly, are the two pciterates doing? Why would each pciterate represent a different member of the point cloud if each is simply iterating over all of the (2) points in the cloud? Inside the for loop, how do I know which point the pcimport node is getting its data from? What about this structure tells me that it wouldn't grab \$PT for the current point itself? The basic logic seems to be "if there are two points, get the point number." You can see the missing puzzle piece in the previous statement. It's very difficult to find in depth explanation for the function of many of the looping features in VEX. This network works great, and beats the hell out of doing a per point forEach loop, but it would be great to understand exactly how it works.
12. ## Lens shader and PBR

Thanks, Dan- Just heard back from SESI this morning, confirming your post with a bit more info. Seems doable--modify the VEX in a copy of v_pathtracer. I'm assuming that P is in camera space in this context. I'm also not sure how I would prevent P from being modified on subsequent ray hits. It's not obvious to me from looking at the VEX--is there a hit count I can query so that I modify P only on the 1st hit? FWIW--here is the reply from SESI Thanks again, Dan! -m
13. ## Lens shader and PBR

Apologies for cross-posting. This is also in Coder's Corner/Shaders--but since this is actually a vopnet... I've developed a stereo lens shader for Arnold, and have replicated its functionality in Houdini--almost. I'm using a grid in front of my ortho camera, transforming P to NDC and driving all of my math from these values. I am using "Refracted Light" VOP in my surface shader to fire rays from an origin that I've computed in a direction that I've computed. All is fine and well when using Ray Tracing--although I was a bit surprised to find that [0,0,0] P ray origin in this context is actually Camera Origin, not Object Origin.(even though it's a surface shader) That's fine--move grid to -0.1 in Z and Camera to zero and all is well. When I started working with PBR, I find that I cannot change the Ray Origin using "Refracted Light." No matter what I do, the ray origin is geometry Surface P. I can get close to the proper results for non stereo if I use a tiny, tiny grid and ortho plane size--but this will never be exact and makes me feel dirty. Furthermore, I need to dramatically alter the ray origin across the image plane for any stereo application of this shader. So--three questions: - How can I exert this control over ray origin in PBR? (direction works fine) - Is there a way to detect the renderer being used from within the shader? (like I said--PBR and RT behave very differently) - Will we ever get the capacity for creating proper lens shaders for Mantra? I'm sure this all stems from a fundamental misunderstanding I have regarding what to do with the BSDF parameter--but not sure how to proceed. Any help is appreciated. Cheers -matt Like This Quote MultiQuote Edit
14. ## jack frost

looks at least a bit like this process: https://vimeo.com/25604611
15. ## Lens shader and PBR

If this has been covered--I couldn't find it. I've developed a stereo lens shader for Arnold, and have replicated its functionality in Houdini--almost. I'm using a grid in front of my ortho camera, transforming P to NDC and driving all of my math from these values. I am using "Refracted Light" VOP in my surface shader to fire rays from an origin that I've computed in a direction that I've computed. All is fine and well when using Ray Tracing--although I was a bit surprised to find that [0,0,0] P ray origin in this context is actually Camera Origin, not Object Origin.(even though it's a surface shader) That's fine--move grid to -0.1 in Z and Camera to zero and all is well. When I started working with PBR, I find that I cannot change the Ray Origin using "Refracted Light." No matter what I do, the ray origin is geometry Surface P. I can get close to the proper results for non stereo if I use a tiny, tiny grid and ortho plane size--but this will never be exact and makes me feel dirty. Furthermore, I need to dramatically alter the ray origin across the image plane for any stereo application of this shader. So--three questions: - How can I exert this control over ray origin in PBR? (direction works fine) - Is there a way to detect the renderer being used from within the shader? (like I said--PBR and RT behave very differently) - Will we ever get the capacity for creating proper lens shaders for Mantra? I'm sure this all stems from a fundamental misunderstanding I have regarding what to do with the BSDF parameter--but not sure how to proceed. Any help is appreciated. Cheers -matt
×
• Donations