21.06.2020, 13:59 fxtd

It is advisable to use packed fragments only in cases where either all fragments or most of them are used. A feature of packaged fragments is that “each fragment shares the same geometry, but refers to a subset of it.” Therefore, when deleting individual fragments, there is no memory saving. Even if you delete all the fragments, leaving only one, and write it to disk, then the cache size will be equal to the memory size of the entire model. And when loading the cache, you will still see only one fragment.

In cases where the logic of work involves changing the number of packeds, it is better to use the usual packed geometry. You can create them in a for-each loop with the pack node without breaking them down by name. Also, the copy to points node creates packed geometry.


15.06.2020, 23:16 fxtd

The name and path attributes are not used by packeds. All necessary information is stored in intrinsic attributes.


14.06.2020, 18:25 fxtd

Deformation things are sometimes more profitable to write in alembic than in bgeo.sc. Transformations are in no way more profitable to write in alembic.
If there is repeating geometry (several repeating packed primitives with the same path), writing them to alembic with separation by the path attribute will fail, and writing in bgeo.sc will be much more optimal.
And in the case of deformation, and in the case of transformation when writing to an alembic, you need to do a hierarchy separation by the path attribute, regardless of what we write: geometry or alembic primitives. Double packing will not happen.
This is not necessary in the case of deformations – memory savings will be about a percent. But it is better to make a breakdown in both cases for a single approach.


04.06.2020, 23:25 fxtd

This is a simple VEX code that allows you to change the size of objects:

matrix3 xform = primintrinsic(0, "transform", @primnum);
scale(xform, chf("scale"));
setprimintrinsic(0, "transform", @primnum, xform);