Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Whatsinaname last won the day on October 26 2014

Whatsinaname had the most liked content!

Personal Information

  • Name
  • Location
    Hole in Ground

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Whatsinaname's Achievements


Newbie (1/14)

  • Week One Done Rare
  • One Month Later Rare
  • One Year In Rare

Recent Badges



  1. I would try and do the fracturing myself, either using boolean fracturing or Voronoi fracture and see if it helps. The RBD Material Fracture is a high-level node that does many different operations inside, but your geo might be a bit special, so it won't work in your specific case. Voronoi Fracture and Boolean fracture do have some options regarding the treatment of normals. Alternatively, you can try creating new normals for the geo before fracturing, maybe those new normals are in a better spot for RBD Material Fracture to work straight out of the box.
  2. What Kushal says and: - try splitting it up into layers, if possible. - Source your particles more cleverly, you might want to use fewer particles for inner/back walls, etc.
  3. You can multiply any attribute with noise. There must be something wrong in your setup, however here's a very plain and very simple solution you could use inside a wrangle as a test: // will multiply myAttribute by a random number between 0.1 and 0.33 based on the point number f@myAttribute *= fit01(rand(@ptnum2), 0.1, 0.33);
  4. You need another volume source, just source velocity, and deactivate all the other fields. Use a merge node and merge it behind the original volume source that you have already got in your scene. Attach it to the same input as your original volume source was attached to (i.e. 4th input in the image above). This new volume source should import data from your first simulation (ideally from the cached data) . It's also important your velocity field is in the correct space, etc...but I reckon you already figured that out.
  5. visualize the collisions inside the FLIPobject during your simulation. It will show you how the solver 'sees' the collisions. I think this will give you a clue.
  6. Looks like you are using an attribute name that is used internally, making something freak out. Send your scene to SideFX.
  7. add a preroll. Create a thinner version of that intersecting geometry (no idea where you created it or how it was done, so it's difficult to be any more specific about it), ideally with the same point count. Use a blendshape during preroll to grow it from its shrunk/non-intersecting position into the desired position. You can also turn it into a vellum object (but without any forces such as gravity applied to that very vellum object) during the process described above. As cloth/vellum objects cannot self-intersect it would create proper folds during the (aforementioned) growth during preroll.
  8. Use volumes. a) turn the object you want to collide it with into a VDB. b ) pipe the geo object (your plant...whatever) into a point wrangle. c) pipe the VDB into the point wrangle's 2nd input. float f = volumesample(1, "surface", @P) //samples a volume called "surface" which is fed into the second input as counting starts at 0 if(f<0) { @Cd=set(1,0,0); } else { @Cd=set(0,1,0); } This will colour the collided points red. Depending on your implementation of the growth animation, you can now use this collision information to make your 'plant' do something when it is colliding with that collision object. The reason why you don't get an earlier answer is probably that nobody knows how you implemented that 'animated growth'. Your description is rather murky and there are many ways to do this.
  9. Couldn't run your scene because of my ancient Houdini version. However: I guess the solver won't update the attribute if you're using a wrangle. Try using a vellumconstraintproperty node, instead. This is the proper way to change constraint properties inside a vellum simulation.
  10. They can do whatever they like, but: - fix that annoying memory leak. Having to re-start Houdini every hour because it doesn't release memory is no fun. (Yes, I am running Linux) - fix the viewport. Killing and re-opening the viewport every 15mins because it is displaying garbage (especially when working with packed geo) is a productivity killer.
  11. When trying to close Houdini, a dialogue window pops up asking the user if they want to save the file or close Houdini right away. It seems like the saving (using this dialogue, not saving in general which is working fine) has lead to several corrupted files in our internal network, therefore I was wondering if there was an option to de-activate this? When closing Houdini, the scene should just close and neither try and save anything nor should the user have the option of doing so as this might result in corrupted files. Is that possible somehow?
  12. I'm using a Gas Damp Microsolver to slow down my pyro sim. However, it seems like it is broken (H17.5.258). No matter which parameter I change, it sucks out all momentum of the sim, bringing it to a standstill. I'm using really ridiculous values, like a Target Speed of 500 (my sim is waaaay slower than that.) As far as I understand it, values below 500 should be ignored, but no matter what I put in there as a target speed, all velocities are lost after a few frames. Scale...well, if it's 1, 0.1, 0.0001 or whatever...it kills all motion after a few frames. Controlling it by a field...same result. Did anybody else ever have a similar issue with this particular microsolver?
  13. Use some dissipation, I think that might help a lot.
  14. That weird pyramid in the bg? My first guess would be some rogue particles at arbitrary positions making the meshing algorithm go crazy. Try creating a bounding box around the area of you want to mesh and kill everything that is outside that area. On top of that, delete any attribute that you don't need for meshing, using an attribute delete before using the particle surface SOP. It could also be a weird hiccup...try adding a slightly different number to your Particle Separation value, something like 0.11 instead of 0.1. See if the odd structure is generated with slightly different settings.
  15. Inside your FLIP sim, look for the FLIPobject > VIsualisation > Collision. Turn that on. Run a few frames of the sim, so you can see how the solver sees your collision object. My guess is that it might be all over the place. Ideally, you want a closed (no holes) model for this purpose, therefore you will have to create a proxy of your boat to make it collide.
  • Create New...