I’m new to the forums, read my introductions here if you like: My introduction post
So first shader, first problem - first post, here goes!
I’ve been playing around with some basic HLSL and I’ve figured out how to apply textures to shaders - not very complicated I was pleasantly surprised to find out. And I’m using 3ds max to preview my shaders, very nice! But there was one problem - the UVs was all messed up! :?: But when I applied the same texture with a standard material it showed up perfectly, no problem with the UV channel or anything. So I worked around with the UVW unwrap a little and I found a solution to the problem. I offset the all the UVs downwards by one UV-space and the texture fitted like a glove! Observe though that it ONLY worked if I moved them downwards, no other direction worked. Here is an image that illustrate the problem as well as the solution.
So, it isn’t really a problem here I guess since I did find a solution. But I would like to know why this is happening - any suggestions?
I don’t know what quadrant in Max is UV positive, but a texture sampler, when faced with “AddressU = Clamp” will behave much as you show there when it hits values that are not from zero to one. You can think of it as inside any tex2d() it is taking your address and calling saturate() on it, if it is set to clamp.
Also worthy of note, is that traditionally in Computer Graphics, Positive along the vertical is generally downward. Positive along the horizontal is to the right, so the image you show makes perfect sense as your offset UVs are in the traditional positive location. Hopefully a Max specialist can come in and clarify exactly what data Max is shooting out to your shader, because by convention it looks like where your texture is should be UV Positive. You could try adding 1 to V in the vertex shader to confirm this. =/ .
Max’s UV’s in the V direction are offset by 1 (it is a bug, nothing more nothing less). You need to add (or subtract? I think it is add) one to your V, so like this in your vertex shader:
In.texcoord.y += 1
Then you should get the proper results with your UV’s in the regular 0 to 1 space.
Thanks mates, very interesting. For How long has that Max bug been around? Sounds like something worth fixing over at Autodesk :p: Thanks for clearing that out Rob.
And thanks Lithium for that texture wrapping trick and the link, I’m going to need that later :):
Viewcube etc. renders using Clamped and so your shader will inherit this - you need to turn it off. Or explicitly set “wrap” in all your shaders, otherwise tiling will not work.
[QUOTE=Nanne;3033]Thanks mates, very interesting. For How long has that Max bug been around? Sounds like something worth fixing over at Autodesk :p: Thanks for clearing that out Rob.
And thanks Lithium for that texture wrapping trick and the link, I’m going to need that later :):
Cheers![/QUOTE]
If they fixed it, it would break backwards compatibility for any shader (especially with the Viewcube clamp behaviour in new versions). So it is a bug everyone will have to live with.
[QUOTE=Rob Galanakis;3035]If they fixed it, it would break backwards compatibility for any shader (especially with the Viewcube clamp behaviour in new versions). So it is a bug everyone will have to live with.[/QUOTE]
[QUOTE=Rob Galanakis;3035]If they fixed it, it would break backwards compatibility for any shader (especially with the Viewcube clamp behaviour in new versions). So it is a bug everyone will have to live with.[/QUOTE]
I think they should fix the UV offset 99% of shaders that don’t use clamp will work, just as they do without the offset. Which is why a lot of people didnt know about it until the viewcube came along and thus a lot of shaders are written assuming its correct. There is the odd shader that might use UVs for other reasons, but not many.
What they do with the viewcube shader is legitimate, setting clamping state. Its just annoying because many shaders don’t set these states, but its easy for people to add.
They could add another set of ParamIDs for the fix if they don’t want to upset anyone.