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.

cwhite

Members
  • Content count

    117
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by cwhite

  1. The tuple size is required to be 2, but the second path is only used if the first one fails to load. This allows you to have a fallback in case your preferred path uses variables that may not necessarily be defined in every situation (or example, you might have a relative path like $HIP/agents/mocapbiped3/shapelib.bgeo so that your setup is portable if you upload it somewhere for rendering). Some applications like geodiff don't have $HIP defined when loading geometry, so the second path could specify the absolute path as a fallback. Shape libraries aren't required to be generated through the agent ROP. But, they are expected to have the same format (collection of packed primitives with a name attribute)
  2. The docs on the 'shapelib_include' attribute were missed when it was backported to 16.0 - tomorrow's build will have some info about it on the /crowds/agents help page (pasted below). It allows the shape library to be split across multiple files on disk
  3. Mocap Biped 2 has a completely different skeleton than Mocap Biped 3, so clips baked out from one cannot easily be used with the other
  4. Yeah, I meant the SOP network where the RBD objects' geometry comes from
  5. Around 10GB of memory usage in the Bullet solver is in the ballpark of what I'd expect for a sim of that size. Is there any indication of what nodes account for the other ~50GB (perhaps SOPs for the simulation's input geometry)?
  6. Yeah, the agent layer SOP can be used to add deforming shapes to a layer - just make sure to point it at the rest geometry (i.e. the input geometry to the Deform SOP). I think the H15 crowds masterclass had some examples of this. To switch an agent's display layer, you can use SOPs like the Agent Edit SOP, or change it in VEX via the setagentcurrentlayer() VEX function.
  7. If you're detaching limbs and the agent has deforming geometry (e.g. skin), you need to switch the agent to a layer which has different geometry that won't stretch out as the joints separate. This would involve slicing the geometry around the detachment point and adjusting the capture weights near the boundary, as well as possibly filling in the hollow interior. This of course means that you'd likely want to have a few predefined detachment points, unless you try to procedurally slice the skin geometry on the fly.
  8. An initial guess would be bad bounding boxes - you could turn on primitive hull display in the viewport to check
  9. There shouldn't be any issues with having multiple types of agents in the same simulation. Just make sure that for each state the agent may be in, the clip name is valid for that type of agent (if the Randomize Clips option is used, the clip name patterns are matched against the agent's clip catalog before selecting a clip).
  10. There were some shelf tool changes in 15.5 - instead of always creating a "stand", "walk", and "ragdoll" state, along with a stand to walk transition, the Simulate tool now prompts you to select some initial states that should be created based on the animation clips available. In the attached file, I just added a ragdoll state, along with a crowd transition DOP and crowd trigger DOP to implement the zombie -> ragdoll transition. ragdoll_zombies_v2.hipnc
  11. It's very important to understand why that appears to "work". Your example uses an expression function that's evaluated while evaluating the string parameter for the wrangle's code. This happens before the VEX code is compiled, and means that the VEX code will keep being recompiled whenever the value is dirtied by the upstream SOP's geometry changing. That can have significant overhead, such as when running inside a foreach loop.
  12. For this setup, where the agents start out very close to the obstacle and are walking toward it, having a low max turn rate means that the obstacle avoidance force can't change their direction quickly enough before they hit the obstacle. An alternative, though, is to adjust the allowed speed variance so that the obstacle force can slow the agents down somewhat as well.
  13. Glue doesn't work in this case because groups of glued objects are simulated together as a *single* rigid body with a compound collision shape, and impacts can then cause shapes to break off into separate objects. That means that If there are multiple animated static objects in a glued chunk, there's no sensible way to update the transforms of the other objects in the chunk - the solver just ends up picking the first one. Additionally, if there's only a single glued chunk, there's only one object in the sim and there won't be any impacts that cause the glue to break. As the previous post mentioned, pin constraints are a better choice for the boundary region since they behave as a more traditional constraint where constrained objects are simulated separately.
  14. You would need: 1) A shape in your agent's collision layer that is bound to the prop's joint. Then, the Bullet solver will update that joint's transform based on the results of the RBD sim, causing the hammer in the agent's display layer to be transformed. 2) No constraints between the prop's RBD object and any other of the agent's RBD objects. You can of course edit the constraint network manually, but you ideally shouldn't set up a joint limit for the prop joint in the Agent Configure Joints SOP, and should turn off the Pin Shapes With No Rotation Limits option on the Agent Constraint Network SOP
  15. That parameter can be a list of objects, so you can change that parameter to "BALL crowdobject1" For more complicated scenarios, the crowd trigger logic DOP lets you combine triggers
  16. Change the DOP Impact Objects parameter on the crowd trigger DOP to the name of the crowd object in your sim (typically just 'crowdobject1' or something like that)
  17. The solver creates several point attributes that describe the size, orientation, etc of the autofitted collision shapes (see the Collision Shape Attributes section of http://www.sidefx.com/docs/houdini15.5/nodes/dop/rbdpackedobject)
  18. If you can post an example file it'll be much easier for someone to answer your question / provide a solution
  19. The solver intentionally allows initially overlapping objects to gracefully separate, since there would otherwise be frequent problems with closely packed fractured pieces. There are some RFE's open to add some solver parameters to control this, but you can bypass it by setting the 'found_overlap' point attribute to 1 before the simulation starts. Then, you just want to turn on Split Impulse and set the Penetration Threshold to 0 so that collisions are resolved without adding any velocity. bullet_penetration_v2.hip
  20. You could use an Enable Solver or a Switch Solver
  21. If you have the crowd solver wired into a multisolver, you can wire in SOP solvers before and after the crowd solver to perform pre-solve or post-solve work
  22. There isn't currently anything built into the crowd solver for this, but you're thinking along the right lines. I would use a pair of SOP solvers - at the end of the timestep, use a Ray SOP in minimum distance mode and record the primitive number and uv coordinates, and then at the start of the next timestep use the Attribute Interpolate SOP to move the agents to their new position.
  23. There's an option on the particle motion tab of the crowd solver for how the agent's up vector can be optionally adjusted by the crowd solver. One option is to set it to the terrain normal.
  24. - For an in-place animation clip, the gait speed indicates how fast the agent was moving in the animation clip (think of it like the speed of a treadmill that the agent is on). The clip speed can then be adjusted based on the ratio between the particle speed and the gait speed to speed up or slow down the clip accordingly and avoid foot sliding. - If the speed limits are enabled, the min speed is (1 - variance/100) * gait speed, and the max speed is (1 + variance / 100) * gait speed
  25. The gait speed controls how the clip is retimed based on the particle speed, but if Limit Particle Speed to Gait Speed Range is enabled it is also used to set speed limits on the agent's particle. The 'steerforce' and 'steerweight' attributes accumulate a weighted average of different forces, which the POP Steer Solver (inside the crowd solver) uses to set the 'force' attribute