I have spent the last two days with Claude trying to use a Texture3D with POPs to no avail.
Claude prepared the following detailed summary of our difficulties. I thought this would be a simple exercise but everything we have tried has failed to map a randomly selected layer to each POP within the geometry! Furthermore - there are no Snippets for the Texture#D which might provide a clue. A simple example toe would be much appreciated!
_________________________________________
Phong MAT Multi-Texturing stuck on Layer 0 of a Texture3D, despite correct W coordinate data
Setup:
Texture3D TOP, Depth 16, “3D Texture” mode (not 2D Array), built via a Pre Fill script that populates the cache from a rotating 2D source.
POP-based geometry (multiple objects via Copy POP), each carrying a per-point 3-component Tex attribute.
Phong MAT, Multi-Texturing On, Texture 1 = the Texture3D TOP, POP Texture Coord Attribute = Tex, Filter = Nearest, Extend U/V/W = Repeat, GLSL Expression field empty.
Tex(2) is computed as (layerIndex + 0.5) / 16 (layer-centered, not boundary-aligned), fed from a quantized noise value.
Symptom:
Every object always renders using Layer 0 of the texture, regardless of Tex(2)'s actual value. Forcing Tex(2) to different constants (0.03, 0.5, 0.9) via a Math Combine POP produces zero change in the actual Render TOP output.
What’s been verified as correct, independently:
Texture3D content: confirmed via a small GLSL TOP (texture(sTD3DInputs[0], vec3(vUV.st, uLayerW))) that scrubbing uLayerW from 0 to 1 correctly cycles through all 16 distinct layer images.
Tex(2) data: confirmed via DAT Text at the last POP node before the Geometry COMP — Tex(2) genuinely varies per-object with correct, layer-centered values, no negatives, good spread across all 16 levels.
Material is live: confirmed by setting the Phong’s base RGB to solid red — the entire render output turned red as expected.
Field is read: typing an invalid attribute name into POP Texture Coord Attribute produces a red error, confirming the field is parsed/validated.
Multi-Texturing is engaged: toggling it off produces a flat white sphere (no texture); toggling it on produces a real texture pattern — just always the same one (Layer 0).
What hasn’t helped:
Changing Tex(2)'s value (confirmed reaching the Geo correctly via DAT).
Toggling Filter between Nearest/Mipmap Linear.
Confirming Extend W = Repeat.
Rechecking POP Texture Coord Attribute is exactly Tex.
Question: What else determines whether Multi-Texturing’s W coordinate is actually used for depth/layer selection versus defaulting to slice 0? Is there a setting elsewhere (Geometry COMP, Render TOP, or a Multi-Texturing sub-setting) that could override or ignore the W component even when U/V are read correctly?
if you have a simple reproducible example, that would help understanding your issue fully but attached here an example where a rectangle is copied 3 times and the third component of the point Texture attribute is assigned via a Lookup Channel POP.
Maybe this already helps but please let me know how this setup differs from your work and also what TouchDesigner build you are currently using.
actually, I’m currently using the primitive id as a lookup index which in a case of many primitives per object would fail. But since you are using the Copy POP, you can make use of the internal dimension attribute where the number of copies is appended as a new dimension component.
In the above example, instead of using _PrimI as the lookup index, you can also use _DimI[1] - depending on your geometry, this might be already enough.
Thanks so much snout for your speedy reply. So you are using the Color Map param whereas I/we were using the Multi-Texturing feature in the Phong. Using Color Map seems counter-intuitive i.e. smells funny for anyone but ‘snout’? So the Tex(2) attribute is telling the Phong to reference the Texture 3D layer via the Color Map param? (I am using build 33070).
I copied my Sphere POP from my network and replaced your Rectangle POP in your gratefully supplied network. Now I get a single texture on all three objects. Argh!
Multitexturing is used when you want to use the Phong Mat to use more than one texture and supply a simple GLSL Expression to composite them in the material itself. Otherwise the Color Map is absolutely fine to receive and process 3D Textures or 2D Texture Arrays.
2 points: In the file I used the primitive id which for a rectangle would be a single primitive per rectangle while a sphere is usually build from many primitives. The second post then pointed to the dimension attribute and now with using a sphere, the Texture attribute is actually part of the Vertex attribute class (for a primitive by default it’s a point attribute) so you would have to switch the Attribute Class parameter of the Lookup Channel POP to process Vertex attributes and things start working.
I’m still struggling to get this to work using your method. When I use a Grid on the second input of the Copy POP I get this > I don’t get a different texture on each copy - which has been the problem for the last 2 days - even though methods have been very different.
since you are now using a copy template, the dimension attribute is not useful anymore, instead on the Copy POP’s “Template” page, select “Vertex” from the TemplateId Attribute parameter and use the now available TemplateId vertex attribute in the Lookup Channel POP.
Ok - I’ve got it working and these are my findings (excuse ones that might be obvious)
the PHONG MAT >> RGB Page wants point (not vector) attributes. Everything revolves around the Color page > Multi-texturing is for GLSL implementations.
By default Sphere POPS and their like create a Tex attribute that can be either of class Vertex or Point. For this purpose the Tex attribute needs to be of class point and Tex(0) and Tex(1) will contain spacial (UV) data that will be used for the 3D texture coords. A Math Combine POP needs to massage these points so they reference the coordinate at the middle of a ‘texture square’ - i.e add half the width of a square - remembering the layers are 0 based.
Tex(2) needs to be filled with normalised values specifying the lookup index for the texture layer. The source of these values could be anything that produces a normalised value like TemplateId/number of textures.
the result should be a Tex attribute with spacial data in the first two dimensions and the layer lookup index in the 3rd dimension. Tex is then entered into all the Coord Attribute fields in the Phong.
It took me a while to get to this point (not vertex).
why you would have to massage the first two components of your texture coordinates is not clear from your description above.
What values go into the third component of the Texture attribute is dependent on what mode the Texture 3D TOP is filled with (refer to Texture 3D TOP - TouchDesigner Documentation ):
2D Texture Array will require integer based access to layers. No blending between layers
3D Texture is normalized access across all layers and allows for blending between the layers
A MAT does not care in what class you specify the texture coordinates. These can be of the point or vertex class where vertex texture attributes take precedence over point texture attributes. What class you choose depends on your particular task.
You might want to texture a four sided tube. The tube has 8 points, 4 points around each ring. The ring is then P0 -> P1, P1 -> P2, P2 -> P3, and P3 -> P0. When attaching point texture coordinates to such a tube, the last face (P3 -> P0) would interpolate between the 0.75 -> 0.0 basically going backwards through your map:
A vertex is a face corner, so in the case of the tube, every side has 4 individual vertices, none of them shared with other faces. Middle mouse clicking on a POP will often reveal this difference. The tube in this example has 8 points but 16 vertices. So now applying the texture coordinates on the vertex class will mean that per side you are now looking at V0 -> V1, V4 -> V5, V8 -> V9, and V12 -> V13. All individual, all with their unique texture attributes:
Thanks snout for your detailed response. My reference to massaging the data referred to adjusting Text(0&1) UV values to reference the middle of the texture and not the boundaries gathered from the geometry. The biggest issue was that I fell into the trap of only looking a the Point class of Tex with the monitoring DAT. There was also a Vector version I was unaware of which had a single value for Text(2) across all points - and the Phong looked at the vector version first - and didn’t use the Point version. Given your explanation I should probably be using Vectors rather than Points given that my geometry is spheres and cubes.
