Jump to content

henderthing

Members
  • Content count

    28
  • Joined

  • Last visited

Community Reputation

5 Neutral

About henderthing

  • Rank
    Peon

Personal Information

  • Name
    Matthew
  1. 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
  2. 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); }
  3. Learning VEX via Animated Gifs - Bees & Bombs

    Very cool. I gave myself a time limit when I threw that up last night and just stopped after 15 minutes. But I could swear there were only a couple primitive types (not including 'sphere') that you could add not long ago... So thanks for that! Your cgwiki is amazing, BTW. Great work, clearly illustrated without loads of extra words. Well done! The continuous hue thing is a bit tricky, because all meaningful values go from 1 to 0 at some point. The version pasted below addresses this, and adds better support for inner and outer radius, and allows you to shift hue. I added spaces before and after the stuff I changed (except the npoints at the beginning ;-)) 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, add cycle anim to keep hue from spatially animating float hue = (fullramp+@Frame/cycle+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); }
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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.
  9. 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
  10. 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
  11. jack frost

    looks at least a bit like this process: https://vimeo.com/25604611
  12. 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
  13. Pop Group Point Count

    AARGH! Thank you. I don't know how many times I scanned local variables for POP nodes without seeing $NGRP!!! Since I posted this, I realized that I didn't need to have the group count within POPs, as all I'm using those particular groups for is to draw lines between particles with the Add SOP. I ended up using the Partition SOP instead, which doesn't require a point count. Thanks again. This will come in handy. -m
  14. Pop Group Point Count

    Hello- I'm using the group POP to create groups using the rand tab according to the rule $PARENT. This is working out great, but requires for me to know how many parents there are--(how many numbered groups I wish to create). For the first iteration, which comes from a SOP group, I can use: argc(pointlist("SOP",groupname)) to get the number of new groups I'll be creating in my POP. However, after that, with every split I'd like to use, this expression does not work. Is there a way to query the number of points in a POP group? How about a way to find out, given a group of points, how many parents there are among them? -m
  15. Accessing Attributes In Pops

    Yeah--it's all working fine now, but I was still a little confused as to when the attribute becomes 3 floats. In the VOPnet it's a vector, the input to the addAttrib node is a vector, the addAttrib node says "vector signature" at the top of the parameter panel, but at the sop level, the attribute is clearly 3 floats. Now I see that this is the default behavior of the addAttrib node, and there is a checkbox called "Vector Qualifier" that can cause the attribute to be a vector at the SOP level. Good times. Thanks -m
×