3d texture bug (077 & 088)

According to this topic sample of a limit sop with texturew - #2 by Jarrett
this is the method to correctly lookup a single frame in a 3dtexture

(N / NUMBEROFFRAMES ) + ((1/NUMBEROFFRAMES)/2) but depending on the size of the 3dtex, sending an index of e.g. “0” thru this formula will not always give you the slice “0”

The workaround is to use this formula

((N-(NUMBEROFFRAMES-2))/NUMBEROFFRAMES)+((1/NUMBEROFFRAMES)/2)

Bug, or wrong formula in the topic linked?

You can see both cases in the attached file, left side broken, right side working
bugReport.toe (8.17 KB)

PS: the file attached in the linked topic sample of a limit sop with texturew - #2 by Jarrett crashes touch 088

I see what’s broken, the POffset that is calculated in the Texture 3D is wrong.
However this brings up an interesting issue. When doing regular ‘fill one slice per frame’ playback with the Texture 3D, coordinate ‘0 + POffset’ is supposed to refer to the newest slice, which could be any slice. When using pre-fill you are expecting 0 + POffset to be the first frame (so, POffset == 0), which is a reasonable expectation.
The tricky case is if you were to create an identical looking Texture 3D by manually using the ‘On’ slider, you’d end up with different results since POffset would be different in this case (referring to the ‘newest’ slice, not the ‘first’ slice.
I.e With Pre-fill of 0, 1, 2, 3, 4, you want coordinate 0 to refer to the frame with data ‘0’,
but if this was filled using the On parameter, coordinate 0 would refer to the newest frame, which is the frame with data ‘4’.

Any thoughts on how you’d want this reconciled from a user standpoint?

Maybe a parameter that controls the POffset behavior?

For now I’ve committed a fix to both 077 and 088 that will have it be consistent, where coordinate 0/1 is the ‘newest’ slice. Regardless of if you are using Pre-Fill or On.