Since the default coordinate space for textures has vec2(0.5) at the center, I’m wondering if it makes sense to default the “Lookup Offset” parameter to (0.5,0.5,0.0).
I’m not very deep into it yet, but I’ve been consistently setting this value to account for this offset in my testing, and it seemed worth mentioning.
Hey Florian,
We need to share a comprehensive example for Lookup Texture POP if we haven’t, I think the “Pixel Centered Sampling Location” toggle should do that, I’ll double check.
Hi Vincent,
Oh, ok. My impression was that this toggle is used to center the lookup UV so that you don’t wind up inadvertently sampling an interpolated value.
Regardless, it’s not a big deal. I just wanted to provide some potentially relevant workflow feedback.
My impression was that this toggle is used to center the lookup UV so that you don’t wind up inadvertently sampling an interpolated value
oh but isn’t that what you wanted to accomplish with the .5 offset? See attached
LookupTexturePOP.1.toe (3.8 KB)
Otherwise not sure I understand your use case
Hi Vincent,
I don’t think I did a good job describing the issue.
It looks to me like the lookuptexPOP is sampling from the texture using the P values. This totally makes sense, but it also means that by default you wind up with a shifted and wrapped sample for a unit sized and positioned piece of geo.
Having spent more time with POPs, I suppose it be more idiomatic to forgo the lookuptexPOP altogether and just use a TOPtoPOP to load the colors into some native size geometry and then a math mix to copy the data over to a new circle attribute.
The grid is much lower res and would probably wind up being more performant, but I suppose this can also be handled by scaling the input texture.
lookupTexOffsetDemo.toe (8.0 KB)
Oh I see, indeed I misunderstood your point.
The lookup tex POP has P(0) P(1) as the default lookup attributes (meaning the first two components of P, so x and y), but so with the default grid, that means they go from -0.5 to 0.5.
The default texture coordinates for the grid go from 0 to 1, so that will get you the result you’re looking for without an offset. Also that way they’re independent from the Grid position.
In SOPs the texture coordinates attribute was uv, in POPs they are the Tex attribute by default.
Maybe it makes sense to update the defaults for that one, will circle back! There used to a requirement that all POPs have P attribute, which is why it’s used as the default usually, but that’s not the case anymore.
Let me know if that makes sense!
Totally makes sense.
It seems like the presence of no attributeId can be taken for granted. Certainly not all input POPs will have a Tex attribute, but maybe it does make sense here since the OP is specifically oriented towards textures.
On the other hand, P is the default attribute in lots of other OPs (ie: noise and so on). Some amount of contextual awareness is required for working with attributes (ie: what attributes are currently in my network and what sort of ranges do they have). My impression is that more POPs will have a P attribute than a Tex.
Frankly, I’d be inclined to leave it as it currently is and let more feedback accumulate. It seems like my use case is only showing part of the picture here.
Generally use indexes that are 0-1 to feed into Lookup Texture POP, similarly for Lookup Channel and Lookup Attribute POPs. Lots of attributes default that way, like Tex and everything that comes out of the Normalize POP and Field POP.
We may put a re-range input in there in the future. Being stingy now.
