Jump to content

Leaderboard


Popular Content

Showing most liked content on 04/07/2021 in all areas

  1. 1 point
    @Mark01 Open in Houdini 16.5 CHOKOLADA.hipnc
  2. 1 point
    You need to create a smoke sim first, then advect your particles with AdvectByVolume and no need to post the same question twice, thanks
  3. 1 point
  4. 1 point
    You have 2 diff edges, make 2 groups and use poly bridge .
  5. 1 point
    The sweep SOP can do the shape along with remapping the UV coordinates and Vellum for additional deformation. dry_fruit.hiplc
  6. 1 point
    yes, simple pyro, save your vel field to disk and create a separate dopnet with a popsim and add an AdvectByVolume DOP node There is an example in the docs https://www.sidefx.com/docs/houdini/examples/nodes/dop/popadvectbyvolumes/AdvectByVolume.html
  7. 1 point
  8. 1 point
    No need for loops and stuff. Take one VDB and put it in the first input, merge all the others and put it in the second input. On the VDB Combine choose "Flatten All B into A" and choose the appropriate operation, like SDF Union for sdfs.
  9. 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
  10. 1 point
    Natural place for .NET platform is HOM, which is an API serving Houdini's internals to aliens (like currently Python interpreter), so C# would behave in Houdini pretty much like Python, with all pros&cons (like read-only access to frozen gdp outside a node, limited number of callbacks, single threaded UI etc). Houdini doesn't have any other API .NET/Mono could be wrapped around, so afaik introducing it to Houdini is more a problem of API, than platform itself. Wrapping a whole HDK seems to be unrealistic if not impossible at first place. The platform itself however is anther subjects of considerations. Is it really multi-platform, how about its maintenance, does it have any future? I doubt anyone would bet on it, if it was a pure Mono project (which is supported by MS anyway), without MS supporting the majority of people at .NET. In other words,my opinion is that Mono is an artificial project and it wouldn't exists if MS wouldn't like to prove .NET is multi-platform. Knowing things a bit, I presume SESI would have to pack up own mono compilation and ship with Houdini. Dependency with the fig leaf in essence. Additionally, anyone who tried to pair .NET application with right Mono version on Linux, knows how great idea is to bring into your pipeline "OS independent" library designed by MS. Surely there would be some pros, as C# plugins wouldn't be so dependent of builds versions, free and good windowing, threading etc, but this is valid under assumption HOM or any other API would allow C# to coexist inside Houdini, which as I suppose is not a trivial task. (and in fact it looks like the main advantage of .NET in Max was how it changed Max to make it happen). Finally Adsk seems to manage business differently for a purpose - suited to its multi-market clients (with games in focus). But having many languages to your disposal doesn't make your life any good by itself. In fact these 5 or 6 different languages in XSI talk to the same API deriving the same bugs from it, adding its own to the bin, along with number of inconsistencies in API's calls and documentation. I definitely don't see SESI going this way, specially that Houdini already have its babel tower, but at least these 5 languages supported in Houdini serve different purposes (and some are legacy thing) - and afaik C# without changing Houdini itself would inherit the same limitations as Python. I think SESI stays focused on tools already provided to make them better. Things like Python everywhere by extending HOM is happening, more Python Objects types, more serial routines handling well heavy data. Real pita compared to .NET is Houdini interface, single-threaded and in fact hardly scriptable. My secret dream is to have at least a QT-pane, which serves as a canvas for Qt widgets, if not just Qt everywhere - which I believe won't happen ever from philosophical reasons. In terms of performance perhaps making Python and VEX more productive is better option, isn't it? Note that you can already call VEX from Python, read/write serialized attributes, but thing totally absent is a primitive context for VEX. Primitive VOP allowing to change topology, deal with bones and VEX extended to support structures, so you have very productive geometry engine suitable for things Python is a wrong bet.
×