Jump to content

toadstorm

Members
  • Content count

    77
  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won

    2

toadstorm last won the day on August 25 2017

toadstorm had the most liked content!

Community Reputation

36 Excellent

4 Followers

About toadstorm

  • Rank
    Peon

Contact Methods

  • Website URL
    http://www.toadstorm.com

Personal Information

  • Name
    Henry
  • Location
    San Jose, CA

Recent Profile Visitors

3,092 profile views
  1. missing reflections from fire

    There isn't supposed to be density in a candle simulation, unless you want visible smoke. The way the sim is set up by the shelf tool, it's not meant to emit any smoke. I think the reflection issue is just one of angles and normals on a perfectly flat plane. If you use a Bend SOP to curve your grid into more of a curved cyc shape, the reflections work fine. debug_refl_v002.hipnc
  2. I added some notes in the VEX code to explain what's going on, but I can elaborate a little further. The first two examples are doing exactly the same thing, one in VEX and one in VOPs: generating a @density attribute based on the Y position of each point on the grid, relative to the bounding box. The `relbbox` function returns a vector with components ranging between 0 and 1, based on where the point is relative to the bounding box of the object on each axis. The y-component of that vector is used as the lookup value for a ramp, using the `chramp` function. The ramp parameter is auto-generated by the point wrangle if you click the little "+" button next to the VEX code. You can then use this ramp to control the value of the @density attribute, which exists on the points of the grid. If you want to visually see the results, you can use a Visualizer SOP to view density as color. The Scatter SOP by default will look for a @density attribute to determine where to prioritize scattering points, but you could use other attributes if you like; density is just a convention. The third example is using the "attractor points" you were asking about. A number of points are scattered on the grid; these are the attractors. In the point wrangle, which runs over all points of the grid simultaneously, the nearest attractor point to the current iteration's point position is found using `nearpt`, and then the `point` function is used to get the position of that attractor. The distance between the current grid point and the nearest attractor point is computed and fit to a 0-1 range based on the "max_dist" channel, which is user-defined. The resulting 0-1 value is used with a ramp attribute lookup, and the result is bound to @density, same as the other examples. You could change the falloff ramp and the max distance to adjust exactly how the density is mapped to the grid points. If you wanted to solve this without VEX, you could try scattering a few points onto a grid, giving them all a @density value of 1 or some other positive value, then using an Attribute Transfer to transfer this attribute back to the grid points. Then use a Scatter SOP as before.
  3. You're inside a loop there... what exactly is that doing? I have a feeling that's probably the source of your problem. Can you post the .HIP?
  4. Access numpt at input 2 of wrangle

    There's a bit of a misunderstanding here... @numpt isn't a real attribute, it's a pseudo-attribute for convenience inside the wrangle. It's always relative to input0. If you want to get the number of points from input1, use the `npoints` function: `int npts = npoints(1)`.
  5. Follow camera VEX variations

    I think this is probably a better place for CHOPs than VEX, unless you want to get nasty with Channel Wrangles. Attached a shakycam scene example, with lag as well. I'm doing a little math in CHOPs to mask the shakycam effect (three Noise CHOPs added to translate) by the speed of the camera's movement, so the shaking only happens when the camera is moving. shakycam.hip
  6. Small Pyro Source

    There's a few things you could try here. First off, for the most part the individual smoke plumes don't interact with each other much. So you might be able to get away with running each little source as its own pyro simulation, with bounding boxes big enough to contain each individual plume but not so big as to cause more computation. You could then run all these simulations simultaneously, assuming you have a render farm for that. Second, very tiny pyro sources typically create very wispy effects. Some of the burning holes in your source video were pretty big, and you could probably safely go with a slightly larger source and then maybe mask out the very beginning of the emission in post. For smoke that is supposed to be very wispy though, you might want to start with a fairly low-res pyro sim, then emit particles from those tiny little holes and advect them through the velocity field of that low-res sim. You could then use Volume Rasterize Points to convert those particles back into a nice thin volume. This technique requires a lot of particles, though, and the rasterization process can be very slow. Whenever you can, parallelize your simulations! Don't run everything as one big sim unless everything needs to interact with everything else.
  7. pyro shader issue

    can you post your hip? also, if you're in H16, why is your flames shader in /shop/ context? was this brought over from an earlier version of houdini? have you tried creating a new flames shader in /mat/ context?
  8. Any ideas why this script is not working? :)

    All of your axis forces have the same axis (0,1,0), and the curl noise that's being applied is specifically multiplied against (1,1,0), which eliminates any motion on the Z-axis. Vary the axes of your POP Axis Forces and remove that multiplier on the curl noise and you should be good to go.
  9. Learning challenge Vex

    @nage is a built-in bind that automatically returns (@age/@life), or the equivalent of the my_value float Atom posted above. that said, setting @age = @ptnum is almost certainly not what you actually want to do... overwriting @age is going to get you some pretty weird results in most scenarios.
  10. Any ideas why this script is not working? :)

    You disconnected your POP Location DOPs from the rest of the network... so you're not getting any particles.
  11. Floating Particles in Water?

    A particle sim is a totally fine way to solve this, but for something like brownian motion for particles in water, you could probably solve this procedurally by just adding some noise to your point positions. I'm attaching an example with both methods; in each case you're starting by converting a box into a volume, scattering a bunch of points into that volume, running your noise through the point positions (either by just adding in the procedural case, or by noise forces via a POP Wind DOP), then attaching a Sprite SOP to visualize the points. underwater_particles.hip
  12. Add emitter to existing flip sim [solved]

    You can have as many sources going into a FLIP object as you like... you just merge the sources together and connect them to the Sourcing input of the FLIP solver. I appended a Fluid Source SOP to your sphere, used the FLIP preset, tweaked the radius a bit because your scene scale is fairly small, then connected a Source Volume DOP to the Sourcing input of the solver with the Source FLIP preset applied. water_2.hipnc
  13. Removing 'stepping' in moving smoke SIM

    If you're talking about the "smoke from moving objects" section, the easiest way to deal with emission from fast-moving objects is to run it through a Trail SOP to "smear" the geometry before connecting it to a Fluid Source SOP.
  14. Emit RBD objects

    I'm not sure why it wouldn't be working for you in H16 as opposed to 15, but in general your packed RBDs always need to have unique names in order to function properly. I haven't watched the tutorial you're referencing so I'm not sure if they cover that or not, but you definitely need it either way.
×