First, I am not able to post the file yet since it is at work, but I may be able to later when I get some time to replicate the issue from my home computer. Hoping it is something simple I am overlooking.

Description of set up: pretty basic set up scattering points as a source for a POP network (justborn), then copy to points using an i@variant wrangle to randomly select 4 alembic variations from lookdev, then feeding that into a vellum cloth set up. This is a set up for money flying out of a car with 4 dollar denominations.

The variations are using the same shader set up from lookdev, each with offset UVs that access the next tile (udim) one for each bill denomination. When I check each variation at this point the uvs are displaying correctly in the uv viewport. When merged, I can see all 4 offset uv sets correctly. Next, Each variation is packed with the uv attribute transfered, fed in to the copy to points with the piece attribute enabled.

After the copy to points I am unpacking, and doing another check. This is where the problem starts. when I check the uvs at this point there is one tile missing (the 3rd). After exporting to Alembic that same tile is missing in Maya, so every third dollar bill is missing the uvs.

Test #1. thinking there was a problem with the i@variant method, I decided to test with a foreach with a switch node instead. The result was the exact same problem.

Test #2. I decided to use just one geometry variation and then use a uv transform to access the other tiles: same problem

Test #3 I decided to test using groups, assigning each variation to a group thinking that I could blast them away and/or provide lighting with the group info so they could apply separate materials based on those groups.

I got a really weird result: similar to the missing 3rd uv tile, the 3rd group was empty. Even more weird was if I added a 5th group then the 4th group was empty but the 5th group contained data. So I thought that I could just provide groups 1, 2, 3, and 5. Except that when I checked uv tiles were there but they not match the input and were shifting around tiles randomly.

I was thinking that it was a changing ptnum issue, but I already had an @id=@ptnum; wrangle but that didn't work.

Now I am thinking it is a detail attribute thing since it is uvs per copy that I am trying to preserve, but not 100% sure how to go about that, or if I am on the correct path here. Any advice would be much appreciated.

- variant method should work fine
- alternatively since you are unpacking anyway for export you can also just copy a single geo and transfer variant attrib to copies and offset uvs based on that after unpack (which will save you from creating vatiant geos)
- or you can also just copy id from points and then generate variants and offset uvs after final unpack using this id (giving you full control over amount of variants)

- but it'll be easier with the file as it sounds like you may be missing just very tiny detail

Hey Tomas, thanks for the quick reply. Going to test some of your ideas today and report back.

Cheers

So I think I figured it out. It was really simple as you said. In my variant wrangle I had i@variant = int(rand(@ptnum)*4);
I should have replaced the @ptnum with @id so i@variant = int(rand(@id)*4);

It was your suggestion to transfer the variant attr that got me looking into the values in the geo spreadsheet, where I noticed they were changing despite having set the id = ptnum, so then I noticed I was still using ptnum. Thanks