| Message |
 |
- Date: 2011-03-30 18:50
- Sender: Ton Roosendaal
- Hi,
We had a lot of bugreports open in the tracker because of bad normals coming from textures. The code used was totally wrong and got fixed in places. Then we decided to not further fix the code, but add new bump methods, these are much more correct and behave better.
Unfortunately the bug fixes also change the appearance in cases. It was impossible to have all cases supported 100% the same.
I also gave up on trying to have our current shader/light system improved. Too many people have worked on it, and each fix we do immediately gives errors in other cases. The work as we've done in the past months will all we do on 2.5, it will render for 2.5 the same now.
The differences in the material nodes i don't see though, what is it?
|
- Date: 2011-03-30 23:22
- Sender: pistol ioan
- Last one in svn r35900 Blender SVN 2.56.5 Win32 with Normal Voronoi texture does not appear Voronoi
In blender-2.56-beta version windows64 Voronoi with Normal-appearing and is still perfect
We hand blend file added for better observation and another two pictures with hand hand
|
- Date: 2011-03-31 00:17
- Sender: Morten Mikkelsen
- pistol. The normal map is a recording of a captured field of vectors. In order to correctly reverse/decode this field your normal maps need to go before the bump maps on the material. It has always been a problem to mix bump and normal maps. For instance in 2.56+ compatible bump, just like default bump, accumulates contributions
without mixing in contributions from normal maps. So if you did:
(compatible/default method)
slot 0: Bump Map 1 slot 1: normal map slot 2: bump map 2
Then bump map 2 will accumulate and distorts/deletes the effect of the normal map.
I have a solution in mind that will allow people to mix any number of bump and normal maps freely without breaking compatibility with the normal map baker but I don't think it's a good idea to bring it in until after 2.57 because it will change slightly the effect of normal maps which are not the first normal map and it will also change the impact of the normal map factor when it's not set to 1.0.
|
|
- Date: 2011-04-01 13:13
- Sender: Ton Roosendaal
- The new hand.blend I cannot use really as reference, it renders far too slow and uses too many features stacked on top of each other.
It would be much more helpful if artists first cleanup and simplify examples, back to a state that shows precisely where the issue is. - no composite needed? remove it - is the ramp shader needed? remove it - is AO needed? etc etc
It is impossible to see what you actually want or expect... too many variables involved.
|
|
- Date: 2011-04-01 16:23
- Sender: Ton Roosendaal
- Thanks for the new file, that makes it much more clear :)
Will assign this to brecht now.
|
- Date: 2011-04-01 18:13
- Sender: Brecht Van Lommel
- The last file actually shows a different problem, with sss + normal maps, which I've fixed now. The problem in the original file appears to be, that first having a bump map, and then a normal map in the stack, ignores the bump map. Flipping the order gets the same render as before.
|
- Date: 2011-04-01 18:17
- Sender: Ton Roosendaal
- Thanks for the fix Brecht!
I suggest to accept the regression for mixing bumps with normal maps, this has been in undefined state anyway. Better to stay away from this code now and keep it work as it is.
|