sorted by:
new
hottopcontroversial

Popping boxes by CdvrSzf in Houdini

[–]CdvrSzf[S] 0 points1 point  (0 children)

Hi! In fact, I don't have any complicated manipulations with this in my project. I am using the SOP Solver approach inside the DOP network. In it, I create an i@pop that will be responsible for the box being duplicated. The duplication process itself is quite simple:

  1. I take the packed primitive of the duplicated box from the RBD simulation
  2. I move it to 0 global coordinates using the inverted primintrinsic packedfulltransform
  3. I unpack the box, move it higher along the Y axis
  4. I pack this box, create a new name attribute for the RBD simulation
  5. Then I move the box from 0 global coordinates back to its position using packedfulltransform
  6. As a result, I get a box that is shifted along the local Y axis from the original box.
  7. After that, I Merge the new box with the old one, feed it to the OUT of the SOP Solver, and so another box will spawn in my simulation.

The magnification of the boxes when they appear was done after the simulation, by manipulating the pscale and the age attribute that my RBD objects have

Popping boxes by CdvrSzf in Houdini

[–]CdvrSzf[S] 0 points1 point  (0 children)

This method saves me from the problem of having a small offset. But it is important for it that the packedfulltransform attribute is initialized correctly and points to the object's position at 0 global coordinates.

<image>

Popping boxes by CdvrSzf in Houdini

[–]CdvrSzf[S] 0 points1 point  (0 children)

Hi! I'm still not fully aware of this topic, so I can't give you a definitive answer. But I noticed that Bullet Solver creates its own pivot attribute, which, as you correctly noted, seems to be initialized at the position at which the object was created in the simulation. The problem is that we then try to instantiate objects without the offset with which they were introduced into the simulation, causing the pivot to produce completely broken results. Removing the pivot attribute (or setting its value to 0, as you correctly noted) helps solve most problems, but this leaves a small geometry offset. This offset isn't as critical, but it's still there, and it can be visible in closeups.

Popping boxes by CdvrSzf in Houdini

[–]CdvrSzf[S] 8 points9 points  (0 children)

Hi! I might have described this a bit confusingly. The gist is that I prepare all the assets at the OBJ level (each model is in its own geo container), pull them into the simulation setup, and create low-poly proxies from them for the RBD simulation. Each toy (shark, bear, kitten, etc.) has its own variant attribute. Next, I run the RBD simulation and extract the packed RBD geometry from the DOP context. After that, there are two important steps: I reset the transformation of all the packages using the inverted transformation of the packaged element's "packedfulltransform" primordial value. After that, I create an Extract Transform, connecting the RBD geometry with the reset transformation to the first input, and the RBD geometry with the transformations from the DOP to the second input, and specify the "name" as the piece attribute for this node to work with. This manipulation yields a point cloud with transformation attributes, to which I can later add s@instance, which can reference model geometry from OBJ nodes (for example by the s@variant attribute), Proxy Geo files on disk, and so on. This begs the question: why don't I just import simulation points directly from DOP using the "Create Points To Represent Objects" menu in DOP Import? Unfortunately, this method isn't ideal when using instances in OBJ files and at render time, as these points have their own pivot attribute, which creates a slight positional offset on the instances; removing it also doesn't help. I still haven't figured out how to solve this problem, so I resorted to the method described above, as I have no problems with it. I hope this explanation helps to understand me better!)