I'm pulling my hair out over an issue that all of the Cycles documentation states shouldn't be there.

I'm simply trying to tile a texture over a standard one-sided square.

My node set up is: Texture Coordinate (UV)-> Mapping(Point)-> ImageTexture(Color)-> DiffuseBDSF(BDSF)-> CyclesSurface

A very standard setup. With all node values set to default, I get the 512x512 texture I'm using mapped to the square just fine.

The problem is when I want to shrink the texture on the square, and have it tile. For example, shrink the texture by 2x2. All of the docs I've seen state that I simply have to set Mapping to Vector Type=Point, and then set Scale to 2,2,1.

This certainly does shrink the texture as desired...but it doesn't tile it across the whole one-sided square. Instead, I just end up with:

In all of the examples I've seen, the image should tile. In fact, there's a lot of discussion about how NOT to make the image tile, but it should by default.

Is this a weirdness in Poser Cycles, or am I doing something wrong?

does it render all right?

Nope. The render appears the same as the previews -- one little square in the corner, no tiling.

It just seems weird that in every Blender Cycles discussion about this, it's all "what you need to do is change the scale and the image automatically tiles", but Poser Cycles doesn't do it.

Let me look into this. I'll get back to you tomorrow.

Didn't seem to be related to another problem. So let's get this out there and find out ...how can we fix this. I'm looking around and extending this question to others.

In the mapping node, choose scale, enter the value which is inverse of the tiling factor you need. For example, if you want your image to be tiling at half the size, use 2,2,2,. if you want it tiling at a quarter the size, use 4,4,4, etc

(Scratches head again)

Why are you using Vector Mapping instead of Texture (decrease scale value should tile) or Point (increase scale value should tile)? I mean, if it works, it works, but it's just odd that this Vector mapping isn't mentioned ANYWHERE. Did you stumble across this solution? Or is it documented?

Anyway, let me run off and check if this works in a quick test. Thank you for your answer.

/confused frown

No dice.

At this point your best bet is to file a report with SmithMicro.

I've done that. Crossing fingers; hopefully I'll have something to report back here.

I'll keep a look out for an answer as well.

Scharmers posted at 3:10AM Fri, 10 June 2016 - #4271972

Shouldn't the values be 2, 2, 2?

seachnasaigh posted at 9:01AM Fri, 10 June 2016 - #4272014

Shouldn't the values be 2, 2, 2?

On a Flat projection, Z value is ignored.

Why are you avoiding the legacy Image_Map node? If it is because you think it doesn't work in SuperFly, here's news: it works fine in SuperFly.

bagginsbill posted at 5:08PM Tue, 14 June 2016 - #4272446

Why are you avoiding the legacy Image_Map node? If it is because you think it doesn't work in SuperFly, here's news: it works fine in SuperFly.

So... does that legacy node replace the trio of TC/mapping/ImageTexture?

Scharmers posted at 8:39PM Tue, 14 June 2016 - #4272516

So... does that legacy node replace the trio of TC/mapping/ImageTexture?

Yes if you intend to use the TC + mapping to do UV-mapped tiling. Of course the TC + mapping is capable of so much more, but 90% of its use cases are not something you'll need and so it's kind of overkill. It's like any situation where you could use three nodes instead of one, but specifically what you're doing doesn't call for it.

Note also that if you need to coordinate the scaling of a color map, and a corresponding normal or bump map, and a corresponding specular or roughness map, all in the same shader, it could be a less work to use the Image_Map and a single number node to run the scales on all of them at once, or it could be OK to use the combo you're using. I haven't really worked out which is the less-work approach.