Jump to content


Popular Content

Showing most liked content on 12/04/2017 in all areas

  1. 2 points
    Ha! It's funny, we were thinking of doing a big thing, and then I started questioning whether it was this year or next year that was our 20th anniversary. Well whatever, thank you all for making this such a great forum, and here's to another 20 (or 19, or something)... Cheers! Marc
  2. 2 points
    here is a quick test + hip : 1 - ray sop 2- cloth solver with NO collision + NO gravity 3- blend sop + smooth sop wrrinkles-00.hiplc
  3. 1 point
    During the last 3 weeks, a did some Rnd and published my results on vimeo . Some people asked me to share my files here, so here we are i hope it will help!
  4. 1 point
    ok, give or take a month or so, but approximately 10 years ago today Jason and I launched odforce as a way to get people to send us stuff . Nothing like being the only two Houdini users on an entire continent to motivate one to do something. Anyway, thanks for being with us for the first 10 years, lets see where the next 10 lead us. :balloon: :balloon: :balloon: :balloon: :balloon: Marc
  5. 1 point
    this i am starting new Project: meshing fractals into real Geo. Last year, i've to created "fancy 2.5D" splines fractals. this year i bringing it to "3rd Dimensions". this are basic primitive rendering which i plan to use in huge scene. goal : manage Billions of polygon's / Data in a efficient way. the final scene will 1000 times complexer Geo. this are simple Geo / renderings:
  6. 1 point
    Hello I've started with this around H 16 release. Basically wanted to explore, to which level I'd be able to use procedural modeling when it comes to characters. So, "non procedural" part here belongs to another app, exactly Maya, where I've created a base body model, rig, posing - while Houdini part is hair of all sorts (hair, eyelashes, eyebrows..), also a lot of suit. Detailed map, what exactly belongs to which app is here. Let's say that 'harness system' is what I'm considering as most successful part. Later, started with Mantra renders, which turned out in kind of addiction - here are few of around hundred renders of this thing, I did in Mantra.
  7. 1 point
    - You can create a point group sop and replace your manual numbers in the dop by taping your group name. - an other method to constraint your points is to define a @pintoanimation attribute =1 in a wrangle sop ( and @pintoanimation=0 for the non constraint points) - and the last method to have more flexible control, is to write this in a wrangle sop for instance : @targetstrength= @Cd.r * 1000000; in the cloth object/deformation/target strength, write the value "1" because this number will be multiplied by the @targetstrentgh value. (note : i use @Cd.r from an attribe transfert) ++
  8. 1 point
    Digging back in time... Odforce is 20yrs old, damn man.
  9. 1 point
    Hello Caskal, maybe you can watch this : ( same pink color ) or you can look at this thread : there are somme hip to make wrinkles. (related to "softbody week 6" video)
  10. 1 point
    Hopefully it will work for a number of different shell types.
  11. 1 point
    I wrote a guide on writing simple node operating on OpenVDB volumes in HDK: Creating simple C++ OpenVDB node in HDK What it does is basically: the node will take a VDB volume as an input and point cloud, then at position of each point it will activate matching voxel in VDB volume. You can also check repository with the code: VDB Activate from Points
  12. 1 point
    I had to match animated Maya lattice in Houdini once in past. I don't have that file anymore so only from memory: I did it as Marty suggested. I exported box lattice from Maya naively as a couple of poly boxes that matched lattice division and inner structure with the same lattice applied to them as Alembic. That way I got exactly same point deformation on multiple cubes that in wireframe looked exactly as Maya lattice gizmo. Then I had to recreate Maya's lattice functionality in Houdini as the algorithm in Houdini is a bit different (e.g. no extrapolation, different smooth functions etc.). I did it with vex at the end. Today it's probably easier to do it in a Deform wrangle. I think it is a really old algorithm, like from 1986 or so, you should be able to find the paper online.
  13. 1 point
    (haha, just saw Marty's comment...which is exactly what I did !!! didn't mean to copy your idea Marty) if you try to export the Lattice itself from Maya (as Alembic), it will say error 'unsupported'....coz it doesn't like the Lattice as not a 'real' geo. So you simply get creative....you create a box, a REAL box with the dim/div of the lattice you intend to export. Then you create a Lattice to deform that box....Then you export the animated box as you proxy lattice. Attached is an example, my MayaProxyLattice is really just an animated box (that was deformed with a real lattice in Maya) MayaLattice.hipnc MayaProxyLattice.abc
  14. 1 point
    no idea about Maya lattice sorry. Maybe you can deform a box that is exactly the same as the lattice then export that, but no idea tbh.
  15. 1 point
    Gifstorm! First I've used a visualizer sop to show @v coming out of the trail sop: That makes sense so far. To make the next step easier to understand, I've shrunk the face that sits along +Z, and coloured the +Y face green, +X red, +Z blue. So, that done, here's that cube copied onto the points, with the v arrows overlaid too: The copied shapes are following the velocity arrows, but they're a bit poppy and unstable. So why are they following, and why are they unstable? The copy sop looks for various attributes to control the copied shapes, @v is one of them. If found, it will align the +Z of the shape down the @v vector. Unfortunately what it does if it has only @v is a little undefined; the shapes can spin on the @v axis when they get near certain critical angles, which is what causes the popping and spinning. To help the copy sop know where it should aim the +Y axis, you can add another attribute, @up. I've added a point wrangle before the trail, with the code @up = {0,1,0}; ie, along the worldspace Y axis: you can see all the green faces now try and stay facing up as much as they can (note the view axis in the lower left corner), but there's still some popping when the velocity scales to 0, then heads in the other direction. Not much you can do about that really, apart from try some other values for @up, see if they hide the problem a little better. What if we set @up to always point away from the origin? Because the circle is modelled at the origin, we can be lazy and set @up from @P (ie, draw a line from {0,0,0} to @P for each point, that's a vector that points away from the origin): Yep, all the green faces point away from the center, but there's still popping when @v scales down to 0 when the points change direction. Oh well. Maybe we can venture into silly territory? How about we measure the speed of v, and use it to blend to the @up direction when @v gets close to 0? Better! Still a bit poppy, but an improvement. Here's the scene with that last setup: vel_align_example.hipnc To answer the other key words in your topic title, I mentioned earlier that the copy sop looks for attributes, obviously @v and @up as we've used here, but if it finds others, they'll take priority. Eg, @N overrides @v. @N is still just a single vector like @v, so it too doesn't totally describe how to orient the shapes. You could bypass the trail and the wrangle so that there's no @v or @up, set @N to {0,1,0}, and all the shapes will point their blue face towards the top. Without any other guidance, it will point the red side of the shapes down +X. If you give it @N and @up, then it knows where point the green side, and you get a well defined orientation. While using 2 attributes to define rotation is perfectly valid, there are other options. The one that trumps all others is @orient. It's a single attribute, which is nice, and its party trick is that it defines orientation without ambiguity, using a 4 value vector. The downside is quaternions aren't easy to understand, but you don't really need to understand the maths behind it per-se, just understand what it represents. The simplest way is to think of it as @N and @up, but glommed into a single attribute. Another way is to think of it as a 3x3 matrix (which can be used to store rotation and scale), but isolated to just the rotation bits, so it only needs 4 values rather than 9 values. In houdini, you rarely, if ever, pluck quaternion values out of thin air. You normally generate what you need via other means, then at the last minute convert to quaternion. Lots of different ways to do this, coming up with ever funkier smug ways to generate them in 1 or 2 lines of vex is something I'm still learning from funkier smug-ier co-workers. Eg, we could take our fiddled @v, and convert it to a quaternion: @orient = dihedral({0,0,1} ,@v); What that's doing is taking the +Z axis of our shape-to-be-copied, and working out the quaternion to make it align to @v. You could then insert an attrib delete before the copy, remove @N, @v, @up, and now just with the single @orient, all the shapes rotate as you'd expect. vel_align_example_orient.hipnc
  16. 1 point
  17. 1 point
  18. 0 points
    Hi, I have a simple simulation for sparks generation (plz see attached). Although I can generate the sparks and control their lengths as I wish, I cannot seem to know how to control their thickness, i.e. I want each spark to have a different size. I've tried three different method to vary the thickness but no works. In the setup, I use pop network to emit particles, then use add to create poly-lines for each spark, then: -If I use wireframe node, I could not find any variable that changes the wire thickness per primitive, I've tried $PR but it does not work (the whole node gets reddish lines) -If I use for each loop to scale each primitive alone, the transform node would scale the spark uniformly and although it's possible to try to orient the transform node with the spark such that it would be possible to scale the thickness only, it would require some math and I don't think it should be that "troublesome" -If I use for each loop and generate each spark individually by sweep+skin, the circle that is used for cross section is outside the loop and it cannot be changed for each primitive! Thanks, laser_sparks_odforce.hip