2023.12230+ Win11 Nvidia 4090
When using 3D textures and texture instancing the resulting textures are inconsistent with the input texture and are wrong.
Somehow an in-between frame is shown and information seems to be retained as well (see the extra concentric circle that should not be there).
Super simple example:
3dtexinstance.tox (1.5 KB)
Changing the Step Size of 3D Texture TOP changes the size of the phantom concentric circle.
Setting the Extend W to Hold solves the issue, however I still find this behavior to be odd (given it’s also the default).
Related:
Seem to be cracking on the issue though: I was using a CHOP for Texture Coord OP. When using a 32 bit float TOP Ramp instead, the output is as expected.
When texturing a 3d texture, a W coordinate of 0 means 50% the first slice, and 50% the last slice. You can think of just like sampling as a U of 0, which is at the left edge of the leftmost pixel. When you use Repeat for the extend, it will blend with the neighbor pixel (the last slice for W, the rightmost pixel for U).
Thanks @malcolm , what is the blending operation in this case? Trying to understand how the in-between frames seen in my gif, and the extra concentric circle comes to be.
The blending is just a linear interpolation between the layers, depending on what the W coordinate is and how close it is to the ‘center’ of the layer. A W=0 will be a 50/50 blend
I see, thanks for taking the time to answer, and I don’t know if this is a bugreport any more but I have made an observation regarding Mipmap filtering and 3d texture instancing that might be interesting.
I’m porting an older comp of mine that used replicated layers to now using 3D textures so a lot of discrepancies coming up.
I have reduced the issue to the following:
Mipmap Linear
Linear or Nearest there is no difference howeverHere is a tox to reproduce the above (used 2023.11880, but same in experimental):
3dtexinstancingbug_questionmark.tox (2.7 KB)
This might seem mundane, but I started noticing differences in the porting of said component. Left is separate TOPs as instance textures, right is equivalent 3D texture — double checked and the 3D texture slices have no difference to the separate ones, so my port looks to be correct. However when rendered it doesn’t yield the same results, even though having the same geo/render settings with Mipmap filtering (which has a nice smoothing effect seen on the left image).
So either Mipmaps are not supposed to work with 3D texture instancing, or I’ve found a bug.
In my opinion the two cases shown in my reduced example/tox should be equivalent.
3D textures provide mipmapping between the layers as well, so you should expect to get different results than with a 2D texture array or instancing 2D textures, since those will only mipmap within one layer. You may want to use a 2D Texture Array here instead.
In this example I’m also curious why you are using instance texturing, since you are only specifying a single 3D texture. You should just be able to use normal texturing in this case (while still providing per-instance coordinates that differentiate the geometry)
Thanks a lot, that solves my question!
My example file was arbitrary, in the actual thing I’m developing I want to keep things as flexible as possible, like reordering textures. EDIT: now I realize what you mean, not needing to specify Instance textures, but still able to reorder via texture coords!
Will include the option as either 2D texture array or 3D textures (it’s one big GLSL 3d texture) for a trade-off between smooth mipmaps and lerping, as I quite like both.
I call this layer separation - “exploding” a texture to different threshold bands
