Welcome to od|forum

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.


  • Content count

  • Joined

  • Last visited

  • Days Won


Community Reputation

203 Excellent

About Skybar

Personal Information

  • Name David
  • Location Sweden

Recent Profile Visitors

5,971 profile views
  1. I don't have maya so I can't check for you, but I think I remember I used to pack the primitives. So in your case each agent is one packed prim. Then I set the 'path' attribute, a string, to something like /crowd/agents/agent_#. A unique path for each packed prim. Then on the alembic rop you choose "build hierarchy from attribute" and use your attribute there. Quite unspecific but that's the general idea I think worked. You might not need to use packed prims at all, I guess the path attribute is the important part.
  2. This is a very good mindset. Teaching yourself to fish rather than getting a fish handed to you will benefit you in the long run. Tutorials have their place, but what will happen if you don't have a solid understanding when there is no tutorial for what you need to do, or no one to ask? Lots of people around don't even try to think for themselves, but that is most vital skill you can have. I'm not saying you shouldn't watch tutorials or ask for help, but it depends on how you do it and what you intend to take away from it.
  3. Turn on perfomance monitor, check what takes up the time. Easy way to pinpoint problems.
  4. Not sure if this uses bullet, but it looks like bullets convex hull. Instead of viewing the volume representation, go to the Bullet Data tab of your collision object and show guide geometry. That's probably what it collides with. So instead of convex hull choose concave.
  5. I don't think you can access groups as an attribute outside of vex. The docs call it a "special virtual attribute": http://www.sidefx.com/docs/houdini/vex/snippets#accessing-group-membership "Special" meaning it's probably exclusive to vex, at least thats my interpretation.
  6. Under the tab 'SDF From Geometry' there, Edge Location has a default value that will make the sdf bigger.
  7. Well you are looping a lot, so yes it will be slow with that approach. Here's a simplified version I did quick: backface_delete_2_dv.hip
  8. Try append the multiple paths with semi-colons, like: PATH = C:/path1;C:/path2;C:/path3
  9. I'm rendering a couple of volumes with cvex and the volume procedural. I've pointed the bbox path to a SOP, and everything works as I want it. But sometimes when I render on our farm, that bounding box somehow gets screwed up and cuts my volumes in half. It never happens locally, and only sometimes on the farm seemingly at random. I can submit a render, it screws up, I submit again, and it works. I have NO idea what is going on, but it feels like it sometimes just stops evaluating the bounding box path and just takes the first frame (or something). My volume (simulation) is moving from one spot to another, and as long as it stays in that original position it works fine which leads me to believe it simply just stops evaluating the bbox as time goes on and the volume eventually moves out of the initial bbox. But only sometimes. Has anyone experienced something similar? Have I forgotten something? Like a checkbox on the mantra rop to "force evaluate everything", I don't know. I'm lost.
  10. You can use a Primitive SOP for this, to avoid using foreach.
  11. I'm not exactly sure, but I think it's a blend to PIC. So for example 95% flip and 5% pic. I THINK there is a setting on the flip solver to do this but i cant remember now.
  12. Just a heads up that this can be problematic, even though they're not visible they are still there. So potentially you could end up with tons of infinitely small geometry; they aren't visible but still take up memory and whatnot.
  13. I think the name splashy and swirly is quite misleading. Splashy uses FLIP and swirly uses APIC. Even if the names might describe them in some situations, APIC can be a lot more energetic in others because it retains the rotation/angular velocity of the particles. See the glasses here at 5:05 for example https://vimeo.com/159438315
  14. Havent worked with flip for a long time but there is settings on the flip solver to control how splashy it is i think. If that is what you are trying to do. But you could maybe do a ramp along Y and increase the drag the further down it is.
  15. You have a bunch of inputs on the flip solver. To do something with the particles you usually use the particle input, and with volumes the volume input (can't remember the specific names). So just lay down a geometry wrangle/gas field wrangle and pipe it into an input.