Big slow vrscenes when instancing alembic with lots of primitives

[glacierise]

Hi guys,

We had a situation where we instanced an alembic with lots of packed prims inside to lots of points. The vrscene gets a record for every point/primitive combination, so 1000 prims * 1000 points = 1 000 000 records, even if all the prims are coming from one file. We tried packing the alembics to a single prim, and rayserver instancer, but no big change - it would be cool if it can be smarter about it

Thanks

[bdancer]

> it would be cool if it can be smarter about it

Rayserver instancer writes one transform per-instance and the whole list is zipped - not sure if we could be "smarter"...

[glacierise]

A record for one file name instead of a record for each prim?

[bdancer]

> A record for one file name instead of a record for each prim?

I don't understand what's that mean - could you please explain a bit deeply?

[GoodbyeKansas]

I can try cause I am guessing it's similar to something we ran into. They might have a tree where leaves are scattered out and then you scatter out that tree in an additional step. So you get this weird nested situation where you still want all instances of the same leaf to just be instances of the same instance but it starts to choke and get heavy instead.
I think in our situation it was bricks in houses. Same brick used in multiple houses but instancing and memory usage still turned into chaos (pun intended). I'll see if I can get someone to maybe clean our scene up a little so we can send it over.

USD should in theory solve some of this as it figures out what is actually the same thing during the composition step as long as you have planned out your stuff nicely. But that we haven't fully tested in production yet.

-- Erik

[glacierise]

Yeah it does seem that solving all that group of problems leads to USD - we'll be testing the waters there soon