If you look at the scene graph tree, you'll see that there is a separate primitive for every sphere. It would probably be more efficient to set up a point instancer prim, or import as points with a width attribute
Yes this is what I initially was thinking. It sort of indirectly adds to my ‘question’ I've had about USD when I first started learning it.
As a starting point I assume USD is like a different method of ‘looking’ at the data ‘underneath’.
Like having a different ‘style’ of a Master Boot Record of a disks bits of data.
Like Houdini has its' version of looking at it, while USD has another - the assumption being the data underneath doesn't change;
When converting from one to the other.
So when importing the already copied to points, I would assume it shouldn't be much work for that conversion.
That being said - the LOPs InstanceToPoints node indeed is the solution for the ‘issue’.
However, I can't seem to figure out to get it to use the points pscale attribute to vary the scaling of the spheres being copied.
I'm assuming I will have to ‘transfer’ that ahead of time and create usd variances of scale for the sphere itself?
Same for mantra, why would you copy spheres to points, when points render as spheres anyway?
* Because it's a work in progress
* Much easier and quicker to see geometric modifications and results from sop operations in the viewport instead of having to render out a sequence.
* It's being created in stages of bgeo caches that will be layered to each other.
* The spheres will be swapped out with other geometric polygonal shapes.
Thanks guys for your feedback.