Jump to content


Popular Content

Showing most liked content on 02/14/2016 in all areas

  1. 1 point
    Hello, I've been finally getting around to learning Houdini constraints and motors. Here's a first set of tests that I've ran. They are all quite simple beginnings, but I've learnt alot, particularly about ways to generate constraints in SOPS and then apply to DOPS, which seems really powerful. Im also using this to have a little peek at mantra, and learn how to set up really simple scenes. Heres the hip files for anyone else trying to work this stuff out. They are a bit disorganised, and alot of them contain ROPS that will need to be rerendered. hip_file hip_file hip_file hip_file hip_file
  2. 1 point
    http://www.sidefx.com/docs/houdini15.0/nodes/dop/gasvorticlegeometry basically you direct where and in which direction the curls should go.. worth a try.
  3. 1 point
    Ah ok, I misunderstood your original question; when you said 'animation', I thought you were referring to shape/transform animation, not what's basically a timewarp curve to apply to other animation sequences. I'm sure there's a more elegant way to do it, but here's one way: vex_time_lookup.hipnc So here's my logic: Animate your sphere by branching to a bunch of transforms, range 1-24, keyfaming @P.x between 0 and 1 to represent the timewarp Merge em all, connectivity, trail of 24 frames, timewarp that freezes frame 24. We have each sphere animation now frozen in space and time as a motion trail add sop to create prim, using 'class' as the grouping attribute. Now we have a geometry curve that matches the time curve. Basically, we've done what the chops network does. The wrangle to construct the instancepath string is a little obtuse, but basically the logic is for each point to randomly select one of the timewarp curves we've generated, and lookup the point that corresponds to the time we're after. Reading its P.x will give us the frame offset we want for the geo on disk. As I mentioned, I feel there's a more elegant way (my gut tells me the point cloud functions should be able to do this for free, but I couldn't get it to work). Its nice to visualise the timewarp curves as geo anyway. Btw, had to double take when I clicked from your username to your vimeo account to your day job. Portal 2 ruined all other games for me, the writing was so good, but equally important was the twisted design and animation style, that seems to be largely down to you and your previous work. Still my favourite game of all time, trying hard to keep my fanboy in check... -matt
  4. 1 point
    if you have linux, then scripting up a loop shouldn't be too hard. #!/bin/csh set START = 1 set END = 100 set FRAME = $START while ($FRAME <= $END) mantra -f myFile.$FRAME.ifd @ FRAME = $FRAME + 1 end that's a really basic loop in csh. it'll iterate over your frame range (change START and END to be whatever you want). you'll need to specify your complete ifd location. also, use $F in the ifd write and not $F4 (this loop doesn't handle padding with 0's). you'll need to save that to a file and "chmod +x" the file to make it executable. good luck.
  5. 1 point
    Unless its really necessary to have your chops stuff be responsive to point positions, you'd be better off writing out all your variations to bgeo sequences on disk, construct file paths per point in a wrangle, and read it all in with an instance sop. Even if you do really really need to have the chop setup be totally live, it'd be worth rethinking it so it doesn't have to be. Eg, say the red cubes in this example needed special behvaiour in a certain area, I'd make another variation of that anim, write it out, and make sure that only those points in that region get to load that geo sequence. See the attached example. instance_anim_v01.hipnc
  6. 1 point
    ifd = Instantaneous Frame Description. they are the direct commands mantra uses to render a frame. mantra does not need houdini running in order to render, it simply needs the commands generated by houdini. this means you can generate those commands to a series of files (1 per frame) and then launch mantra to do the actual rendering. the benefit for you would be that houdini would not be loaded and taking up your ram at the same time your frames are rendering. to generate ifds, you simply toggle on the "Disk File" toggle in the "Driver" tab on your rop. then you need to find a suitable location for your ifd's and name them something appropriate (with $F in the name if you have multiple frames). then when you click render to disk, it will just do the ifd generation. the hard part is then processing those ifds thru mantra. it's not hard per se, but you need to call mantra over and over again as each frame is completed. it's basically the job of a render farm/manager. if you're just doing a single frame, you could probably manage it manually. but more than that is rough -- particularly on windows. how many frames you want to render? do you have any kind of render farm software?
  7. 1 point
    You can use hscript in a shell to open/navigate/manipulate a hip file hscript -v /path/to/file.hip # open the file opcd /out # navigate in /out context opls # list nodes render nameOfMantraNode ; q # push the "render" button on your mantra node and quit once finished. alternative to last line can be opparm -c nameOfMantraNode execute ; q which will simulate you pushing the button render on the mantra Node.
  8. 1 point
    laplacian.hipnc So i built the laplacian op and i get the same result from the sop volume analysis laplacian (slice1 to slice2) Comparing techniques it appears that splitting the divergence and gradient operations results in a loss of high frequency values (comparing slice2 to slice3 in the file) Problem with discretizing these pde formulas is the inherent loss of data from sample rate, so simplifying the algorithm to one step probably reduces data loss from sample rate. just my guess
  9. 1 point
    looks awesome ! i like it very much and thanks for sharing , because you are helping me too to understand some things . .cheers