Bump map is included in color texture(height map of black and white), but I think that normal is not included
But i can generate normal from color texture
Is this a blender specific feature
Well it is working as intended since your map is grayscale image, but might not work as intended if there was color in it, since there would have to be a colorspace conversion done. Non-color data basically says that there is no conversion to be done. I don’t know if leaving this as color creates a small performance hit or not.
I don’t think it’s working as intended because all intentions seem deliberately broken. BW/Color Data fed directly into a normal simply means normals will get “some” data, off course it will. The data won’t be normalized nor predictable, and possibly even produce illegal normals. The mangled normal data is then driving displacement, why?
That being said, all data can be present in an image as long as you know how to use the channels. I could use R bits 0-1 for metallic and R bits 2-5 for aniso direction and R bits 6-7 for Blue colors if I wanted for maximum efficiency. But I would have to split, extract, and utilize the information myself. Image is just a way to store 3 or 4 channels of (usually 8bit) data (excluding special formats).
1 Like
thanks for comment
This object can be baked as normal
But is it physically incorrect?
When sculpting,i need make small detail like this picture
Blender will crash if polygons are increased too much
Bump map is not bad, but normal is ideal
Is there a way or tutorial to convert bump maps to normal?
thanks for comment.
i can bake this object as normal
It seemed to me that there was not a problem
However, I do not know whether it is physically correct
Then bake it, but use the normal map as intended; image map (non color data) → normal map → shader normal input socket.
Normal maps are physically incorrect by nature, but that has nothing to do with the mess in post #1 
You’re perfectly ok to fake normals this way, but it won’t create geometry.
If you use procedurals to generate bump, and the procedurals are not so complex it kills the performance, I would use that as bump instead of (or in addition to) normal maps.
1 Like
thanks for comment
I am trying to make a texture for game
So, it must be a normal map for game
If normal is physically incorrect in the first place, I think that this method can be used
You want the grayscale image plugged into the “height” socket, not the normal socket. You could use the normal socket to do things like add a bump on top of a normal map, but you don’t need to use it.
2 Likes
Always remember that a “color” is a 3-tuple (R,G,B) or a 4-tuple (R,G,B,A), and a “normal map’s” vectors are numerically the same. Therefore, an image-file can be used to store a normal-map and it sometimes is. Likewise, Blender’s node system will allow you to link these two sources of data together because they are numerically compatible … whether or not it is nonsensical is up to your discretion.
Note: “the fly in this ointment” is the compression that normally takes place with “image” files. That’s why your files should be MultiLayer OpenEXR or, as the case may be, OpenEXR, this being an intermediate-file format that is specifically designed for the loss-less storage of digital data. Industrial Light & Magic created the original format, and Blender Foundation(!) added the “multi-layer” enhancement.
thanks
It means that RGB is compatible with XYZ
I set this way
It works well and i can also bake as normal
If you want to examine and conclude that everything “is well”, replace the diffuse with a glossy sharp shader under some environment. Plugging blue (vector) normal into grey (float) displacement may appear to work as intended (because the channel may have info that modifies the displacement), but it doesn’t sound right at all.
Is RBG compatible with XYZ? Yes, afaik at least.
Is XYZ compatible with RBG? Not always. In some cases RGB “type calculations and modifications” doesn’t like negative values much, even when set proper later in the chain.
1 Like
… and, CarlG, as I noted above, "compression, in image-files, is not your friend in an application such as this, where you are relying on the image-file to accurately store what is actually “a file of digital 3-tuples, not an actual image.” Most image-file codecs will compress the data in a “lossy” way that won’t be noticeable to the eye in the case of an image, but that will cause your normals to “go wonky” if you look closely. (In some cases it looks like someone “scratched the bumps.” In other cases, the bumps are flattened, or simply wrong, because the “colors” have been averaged. (Read: “lost forever.”)
This is specifically why I recommended OpenEXR, which will capture “any arbitrary digital data-stream that you have need to deal with,” always accurately and in a lossless way. What comes out of the file will always be exactly what you put into it.
MultiLayer OpenEXR not only captures the data, but identifies what it is to Blender and other compatible applications … and it can, as the name implies, store several “layers” of such information together in just one file.
thanks for comment.
I do not know if it’s really normal
I have no details
Also, since blender can not print string values of nodes