Welcome to od|forum

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.

mestela

Members
  • Content count

    554
  • Joined

  • Last visited

  • Days Won

    39

mestela last won the day on April 11

mestela had the most liked content!

Community Reputation

431 Excellent

About mestela

  • Rank
    Houdini Master

Personal Information

  • Name
    matt
  1. Heh, would you tell us if we guessed correctly?
  2. If your particle density is high enough, a vdb from particles should be fine. Quickie setup: smoke_curve_trail.hip
  3. If you explicitly cast chramp to a vector first, the 'create spare parameters button' will create a colour ramp. Eg @Cd = vector(chramp('myramp',@P.x));
  4. Cool stuff!
  5. You're not using apprentice but any chance? Fbx export is disabled in apprentice.
  6. Writing vex isn't like writing code in other language, especially for graphics. Even tools like processing, which is probably the closest equivalent in terms of a purpose built language for manipulating graphics, involves more boilerplate code and fiddly stuff than I'm comfortable with. The fact that you can create a wrangle and write something as simple as... @P+=noise(@P); ...and it works, I don't think any other language or 3d system can match that. And as others have said, Houdini doesn't compel you to use vex or vops, use whatever is best for the task at hand. I do shadery visual stuff in vops, and pointcloud lookups and loops in vex, and often I'll combine the two with snippets sitting inside vops. I remember when I started learning houdini thinking 'ew, wrangles, too hard', but over time they've become my standard go-to node. Don't make the mistake of skipping vex cos you've had a bad time with other languages. It's incredibly elegant and powerful, and for the most part its faster to write and debug a simple 3 line vex wrangle than to create and debug the equivalent 12 node vop network.
  7. Ha, awesome! Also, Bees and Bombs is on Patreon, worth supporting: https://www.patreon.com/beesandbombs
  8. Nice! Could do it in a detail wrangle and get the single-node prize, including creating the spheres: int pt; vector pos; int total = chi('total'); for (int i = 0; i<total; i++) { float nptnum = 2.0*i/(total); //ptnum, normalized 0-almost 2 @P=(i/50+1)*set(sin(nptnum*2*$PI),0,cos(nptnum*2*$PI)); //double circle--exploit that ptnum is int //vectors-- axis is 2D perpendicular to out vector out = normalize(@P); vector pivot = out*1.5; vector axis = set(out.z,0,-out.x); //timing cycles float cycle = ch("cycle_frame_count"); float ramp = (nptnum-@Frame/cycle)%1; 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); matrix3 m = ident(); scale(m,0.03); setprimintrinsic(0,'transform',newsphere,m); int newprim = addprim(geoself(),"polyline",pt,pt+50); } The bit that's eluding me is the colour ramp; I can keep it smooth, but the colours always stay cool on the outside and warm on the inside, or I can lock them down, but you get a discontinuity where the rotation resets. Should be a simple fix but I can't quite see it...
  9. Sweet! Saw this one yesterday, haven't quite got it right, maybe someone else will have an idea of how to fix it: mobius_hsv_twist.hipnc
  10. Yep, or just resample to the resolution you need before the wrangle. Every time I've needed this effect it's been a very quick growth, so I've been able to get away with quite low res segments.
  11. It's been verbified in the latest daily build. https://www.sidefx.com/changelog/?journal=&categories=&body=Carve&version=&build_0=&build_1=&show_versions=on&show_compatibility=on&items_per_page=
  12. This seemed like a good way to compare foreach vs compiled foreach vs the groom.h trick outlined earlier on odforce vs removepoints by curveu. The speedup with compiling is huge, but its still slow compared to a wrangle approach. carve_compare.hip
  13. Agreed, it all feels more obtuse than it needs to be.
  14. It's annoyingly fiddly; where you've typed 'second' in the dop data parm on the inputs tab on your wrangle, change it to 'obj0/second'. To be clear, the only way I worked this out was to drag 'second' in the geometry spreadsheet into the parm, which gave me the full path, then i reduced it down until it stopped working.
  15. Looking at the original scene, the problem was it was freezing time for all the cubes before creating the constraints. I split off the animated cube from the freeze, and extended the search radius for the connect adjacent pieces, the bottom cube drags the rest and makes them topple over. I put some notes on making constraint networks here: http://www.tokeru.com/cgwiki/index.php?title=ConstraintNetworks glueToDeform_me.hipnc