height map for normal input sharp edgesheight map brings weird resultalternatives for operator's report() function?Get same bump from a photo to a modelheight map brings weird resultCreate height bitmap from meshGenerating height map of group of objectsHeight Map to Mesh conversion considering TransparencyIs there a way to “clip” or “clamp” the height of a normal, so that bumps go to a certain height and then abruptly flatten, as if chopped off?Bump map height still the sameHeight Map: how to deleted unwanted faces?Height Map Using Vertex World Height (Z) as RGB ValueIs it possible to use height maps from substance designer in Blender and how?
Multi tool use
lightning-datatable row number error
Why is it that I can sometimes guess the next note?
height map for normal input sharp edges
Can I sign legal documents with a smiley face?
C++ debug of nlohmann json using GDB
Are the IPv6 address space and IPv4 address space completely disjoint?
Fear of getting stuck on one programming language / technology that is not used in my country
2.8 Why are collections grayed out? How can I open them?
Electoral considerations aside, what are potential benefits, for the US, of policy changes proposed by the tweet recognizing Golan annexation?
Open a doc from terminal, but not by its name
Terse Method to Swap Lowest for Highest?
How should I respond when I lied about my education and the company finds out through background check?
Loading commands from file
New brakes for 90s road bike
copy and scale one figure (wheel)
Is aluminum electrical wire used on aircraft?
Can Legal Documents Be Siged In Non-Standard Pen Colors?
Problem with TransformedDistribution
What should you do if you miss a job interview (deliberately)?
Closed-form expression for certain product
Registration and login script
Why is so much work done on numerical verification of the Riemann Hypothesis?
Added a new user on Ubuntu, set password not working?
What does chmod -u do?
height map for normal input sharp edges
height map brings weird resultalternatives for operator's report() function?Get same bump from a photo to a modelheight map brings weird resultCreate height bitmap from meshGenerating height map of group of objectsHeight Map to Mesh conversion considering TransparencyIs there a way to “clip” or “clamp” the height of a normal, so that bumps go to a certain height and then abruptly flatten, as if chopped off?Bump map height still the sameHeight Map: how to deleted unwanted faces?Height Map Using Vertex World Height (Z) as RGB ValueIs it possible to use height maps from substance designer in Blender and how?
$begingroup$
So I have generated this simple height map to test my add on:
That's the node setup and the result that I am having in Blender:
What is happening here (basically, that's a theory, I did not analyze the actual pixel values programmatically): Blender Bump node is interpreting each slightest variation in the pixel value (say, 0.985 white and 0.99 white) as variation in height. What you have as a result are the ugly cutoffs. By the way, a similar question with the same problem, unsolved: height map brings weird result
Now, if I do converting in CrazyBump, I have the opportunity to ignore small details, and, if I convert with CrazyBump, the map is displayed correctly in blender. By their nature, any height map, even 16K will not be absolutely smooth because the set of possible heights is a set of discrete values, it will never be smooth. The task of an algo would be to produce smooth normals from this. And this is what Bump node obviously does not do. Any suggestions? (using other software does not work, I want to achieve it specifically in the node editor of Blender, for any BW map)
and just to prove the point: if I twick the small details all the way up in CrazyBump, I will get essentially what the BumpNode in Blender is doing: overexaggerating non-significant value variations:
height-map
asked 4 hours ago
SerhiiPoklonskyiSerhiiPoklonskyi
464
$endgroup$
add a comment |
$begingroup$
So I have generated this simple height map to test my add on:
That's the node setup and the result that I am having in Blender:
What is happening here (basically, that's a theory, I did not analyze the actual pixel values programmatically): Blender Bump node is interpreting each slightest variation in the pixel value (say, 0.985 white and 0.99 white) as variation in height. What you have as a result are the ugly cutoffs. By the way, a similar question with the same problem, unsolved: height map brings weird result
Now, if I do converting in CrazyBump, I have the opportunity to ignore small details, and, if I convert with CrazyBump, the map is displayed correctly in blender. By their nature, any height map, even 16K will not be absolutely smooth because the set of possible heights is a set of discrete values, it will never be smooth. The task of an algo would be to produce smooth normals from this. And this is what Bump node obviously does not do. Any suggestions? (using other software does not work, I want to achieve it specifically in the node editor of Blender, for any BW map)
and just to prove the point: if I twick the small details all the way up in CrazyBump, I will get essentially what the BumpNode in Blender is doing: overexaggerating non-significant value variations:
height-map
asked 4 hours ago
SerhiiPoklonskyiSerhiiPoklonskyi
464
$endgroup$
1
$begingroup$
It might have to do with the bit depth of the height map. 8 bit images are not enough to resolve subtle gradation. Try using images in a higher bit depth. Also, images used for bumps and normals should not be interpreted as color, but as Non-Color-Data (linear)
$endgroup$
– cegaton
4 hours ago
$begingroup$
@cegaton thanks for responding. bpy.data.images['...'].depth tells me it's 32 bit depth (is this the right indicator?). Also, changing to non-color does not affect the result. take a look at the last illustration: CrazyBump can algorithmically ignore or exaggerate those cuttoffs by setting its degree of attention to fine details
$endgroup$
– SerhiiPoklonskyi
4 hours ago
2
$begingroup$
32 bit is 8bit per channel+Alpha (8 bit x 4). Try creating the image as a 16 bit per channel file. Non-color data should always be used for bump and height maps to avoid the distortion caused by the 2.2 gamma curve used in image encoded in sRGB. You might get better results using a displace modifer and subsurf than using displacement in the material or shader.
$endgroup$
– cegaton
4 hours ago
$begingroup$
@cegaton holy Jesus! it has solved the problem! marry me, cegaton! I totally agree with you with regard to displacement but my idea was to combine individual alpha elements to produce reliefs and cravings easily. now it will work thanks to you. if you so wish, post an answer for others, probably with a bit of explanation on depth and how it affects the result
$endgroup$
– SerhiiPoklonskyi
3 hours ago
1
$begingroup$
will do it soon. Thank you again
$endgroup$
– SerhiiPoklonskyi
3 hours ago
add a comment |
$begingroup$
So I have generated this simple height map to test my add on:
That's the node setup and the result that I am having in Blender:
What is happening here (basically, that's a theory, I did not analyze the actual pixel values programmatically): Blender Bump node is interpreting each slightest variation in the pixel value (say, 0.985 white and 0.99 white) as variation in height. What you have as a result are the ugly cutoffs. By the way, a similar question with the same problem, unsolved: height map brings weird result
Now, if I do converting in CrazyBump, I have the opportunity to ignore small details, and, if I convert with CrazyBump, the map is displayed correctly in blender. By their nature, any height map, even 16K will not be absolutely smooth because the set of possible heights is a set of discrete values, it will never be smooth. The task of an algo would be to produce smooth normals from this. And this is what Bump node obviously does not do. Any suggestions? (using other software does not work, I want to achieve it specifically in the node editor of Blender, for any BW map)
and just to prove the point: if I twick the small details all the way up in CrazyBump, I will get essentially what the BumpNode in Blender is doing: overexaggerating non-significant value variations:
height-map
asked 4 hours ago
SerhiiPoklonskyiSerhiiPoklonskyi
464
$endgroup$
So I have generated this simple height map to test my add on:
That's the node setup and the result that I am having in Blender:
What is happening here (basically, that's a theory, I did not analyze the actual pixel values programmatically): Blender Bump node is interpreting each slightest variation in the pixel value (say, 0.985 white and 0.99 white) as variation in height. What you have as a result are the ugly cutoffs. By the way, a similar question with the same problem, unsolved: height map brings weird result
Now, if I do converting in CrazyBump, I have the opportunity to ignore small details, and, if I convert with CrazyBump, the map is displayed correctly in blender. By their nature, any height map, even 16K will not be absolutely smooth because the set of possible heights is a set of discrete values, it will never be smooth. The task of an algo would be to produce smooth normals from this. And this is what Bump node obviously does not do. Any suggestions? (using other software does not work, I want to achieve it specifically in the node editor of Blender, for any BW map)
and just to prove the point: if I twick the small details all the way up in CrazyBump, I will get essentially what the BumpNode in Blender is doing: overexaggerating non-significant value variations:
height-map
height-map
asked 4 hours ago
SerhiiPoklonskyiSerhiiPoklonskyi
464
asked 4 hours ago
SerhiiPoklonskyiSerhiiPoklonskyi
464
edited 4 hours ago
SerhiiPoklonskyi
asked 4 hours ago
SerhiiPoklonskyiSerhiiPoklonskyi
464
asked 4 hours ago
SerhiiPoklonskyiSerhiiPoklonskyi
464
asked 4 hours ago
SerhiiPoklonskyiSerhiiPoklonskyi
464
464
1
$begingroup$
It might have to do with the bit depth of the height map. 8 bit images are not enough to resolve subtle gradation. Try using images in a higher bit depth. Also, images used for bumps and normals should not be interpreted as color, but as Non-Color-Data (linear)
$endgroup$
– cegaton
4 hours ago
$begingroup$
@cegaton thanks for responding. bpy.data.images['...'].depth tells me it's 32 bit depth (is this the right indicator?). Also, changing to non-color does not affect the result. take a look at the last illustration: CrazyBump can algorithmically ignore or exaggerate those cuttoffs by setting its degree of attention to fine details
$endgroup$
– SerhiiPoklonskyi
4 hours ago
2
$begingroup$
32 bit is 8bit per channel+Alpha (8 bit x 4). Try creating the image as a 16 bit per channel file. Non-color data should always be used for bump and height maps to avoid the distortion caused by the 2.2 gamma curve used in image encoded in sRGB. You might get better results using a displace modifer and subsurf than using displacement in the material or shader.
$endgroup$
– cegaton
4 hours ago
$begingroup$
@cegaton holy Jesus! it has solved the problem! marry me, cegaton! I totally agree with you with regard to displacement but my idea was to combine individual alpha elements to produce reliefs and cravings easily. now it will work thanks to you. if you so wish, post an answer for others, probably with a bit of explanation on depth and how it affects the result
$endgroup$
– SerhiiPoklonskyi
3 hours ago
1
$begingroup$
will do it soon. Thank you again
$endgroup$
– SerhiiPoklonskyi
3 hours ago
add a comment |
1
$begingroup$
It might have to do with the bit depth of the height map. 8 bit images are not enough to resolve subtle gradation. Try using images in a higher bit depth. Also, images used for bumps and normals should not be interpreted as color, but as Non-Color-Data (linear)
$endgroup$
– cegaton
4 hours ago
$begingroup$
@cegaton thanks for responding. bpy.data.images['...'].depth tells me it's 32 bit depth (is this the right indicator?). Also, changing to non-color does not affect the result. take a look at the last illustration: CrazyBump can algorithmically ignore or exaggerate those cuttoffs by setting its degree of attention to fine details
$endgroup$
– SerhiiPoklonskyi
4 hours ago
2
$begingroup$
32 bit is 8bit per channel+Alpha (8 bit x 4). Try creating the image as a 16 bit per channel file. Non-color data should always be used for bump and height maps to avoid the distortion caused by the 2.2 gamma curve used in image encoded in sRGB. You might get better results using a displace modifer and subsurf than using displacement in the material or shader.
$endgroup$
– cegaton
4 hours ago
$begingroup$
@cegaton holy Jesus! it has solved the problem! marry me, cegaton! I totally agree with you with regard to displacement but my idea was to combine individual alpha elements to produce reliefs and cravings easily. now it will work thanks to you. if you so wish, post an answer for others, probably with a bit of explanation on depth and how it affects the result
$endgroup$
– SerhiiPoklonskyi
3 hours ago
1
$begingroup$
will do it soon. Thank you again
$endgroup$
– SerhiiPoklonskyi
3 hours ago
1
1
$begingroup$
It might have to do with the bit depth of the height map. 8 bit images are not enough to resolve subtle gradation. Try using images in a higher bit depth. Also, images used for bumps and normals should not be interpreted as color, but as Non-Color-Data (linear)
$endgroup$
– cegaton
4 hours ago
$begingroup$
It might have to do with the bit depth of the height map. 8 bit images are not enough to resolve subtle gradation. Try using images in a higher bit depth. Also, images used for bumps and normals should not be interpreted as color, but as Non-Color-Data (linear)
$endgroup$
– cegaton
4 hours ago
$begingroup$
@cegaton thanks for responding. bpy.data.images['...'].depth tells me it's 32 bit depth (is this the right indicator?). Also, changing to non-color does not affect the result. take a look at the last illustration: CrazyBump can algorithmically ignore or exaggerate those cuttoffs by setting its degree of attention to fine details
$endgroup$
– SerhiiPoklonskyi
4 hours ago
$begingroup$
@cegaton thanks for responding. bpy.data.images['...'].depth tells me it's 32 bit depth (is this the right indicator?). Also, changing to non-color does not affect the result. take a look at the last illustration: CrazyBump can algorithmically ignore or exaggerate those cuttoffs by setting its degree of attention to fine details
$endgroup$
– SerhiiPoklonskyi
4 hours ago
2
2
$begingroup$
32 bit is 8bit per channel+Alpha (8 bit x 4). Try creating the image as a 16 bit per channel file. Non-color data should always be used for bump and height maps to avoid the distortion caused by the 2.2 gamma curve used in image encoded in sRGB. You might get better results using a displace modifer and subsurf than using displacement in the material or shader.
$endgroup$
– cegaton
4 hours ago
$begingroup$
32 bit is 8bit per channel+Alpha (8 bit x 4). Try creating the image as a 16 bit per channel file. Non-color data should always be used for bump and height maps to avoid the distortion caused by the 2.2 gamma curve used in image encoded in sRGB. You might get better results using a displace modifer and subsurf than using displacement in the material or shader.
$endgroup$
– cegaton
4 hours ago
$begingroup$
@cegaton holy Jesus! it has solved the problem! marry me, cegaton! I totally agree with you with regard to displacement but my idea was to combine individual alpha elements to produce reliefs and cravings easily. now it will work thanks to you. if you so wish, post an answer for others, probably with a bit of explanation on depth and how it affects the result
$endgroup$
– SerhiiPoklonskyi
3 hours ago
$begingroup$
@cegaton holy Jesus! it has solved the problem! marry me, cegaton! I totally agree with you with regard to displacement but my idea was to combine individual alpha elements to produce reliefs and cravings easily. now it will work thanks to you. if you so wish, post an answer for others, probably with a bit of explanation on depth and how it affects the result
$endgroup$
– SerhiiPoklonskyi
3 hours ago
1
1
$begingroup$
will do it soon. Thank you again
$endgroup$
– SerhiiPoklonskyi
3 hours ago
$begingroup$
will do it soon. Thank you again
$endgroup$
– SerhiiPoklonskyi
3 hours ago
add a comment |
1 Answer
1
active
oldest
votes
$begingroup$
short answer: as @cegaton has pointed out, save your image with 16 bits depth. If you are baking like me, this has to be done before bake, because resaving later does not generate information lost while baking.
Go to 'Save as' dialog, there in the lower left corner choose 16 bits depth.
A (not so) technical explanation: if you are not familiar, depth is the number of bits used to store the pixel color. With 8 bits, you store 2^8 = 256 color values at maximum, with 16 bits that's 2^16 = 65536 possible colors. What was happening in my case is the following: for the different height values in the geometry that I was baking, an approximation was generated to store the height. In other words, for heights x-0.01, x, x+0.01s, it would simply put x, because it has no bits to store all the three. Hence the flat areas in your image, where the color gets 'simplified'. For my 8 bits image, I did for learning purposes:
len(set(bpy.data.images['My8BitImg.png'].pixels))
This has returned 256, while
len(set(bpy.data.images['My16BitImg.png'].pixels))
has returned 42891 in my case.
answered 2 hours ago
SerhiiPoklonskyiSerhiiPoklonskyi
464
$endgroup$
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
return StackExchange.using("mathjaxEditing", function ()
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix)
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["$", "$"], ["\\(","\\)"]]);
);
);
, "mathjax-editing");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "502"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fblender.stackexchange.com%2fquestions%2f135103%2fheight-map-for-normal-input-sharp-edges%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
$begingroup$
short answer: as @cegaton has pointed out, save your image with 16 bits depth. If you are baking like me, this has to be done before bake, because resaving later does not generate information lost while baking.
Go to 'Save as' dialog, there in the lower left corner choose 16 bits depth.
A (not so) technical explanation: if you are not familiar, depth is the number of bits used to store the pixel color. With 8 bits, you store 2^8 = 256 color values at maximum, with 16 bits that's 2^16 = 65536 possible colors. What was happening in my case is the following: for the different height values in the geometry that I was baking, an approximation was generated to store the height. In other words, for heights x-0.01, x, x+0.01s, it would simply put x, because it has no bits to store all the three. Hence the flat areas in your image, where the color gets 'simplified'. For my 8 bits image, I did for learning purposes:
len(set(bpy.data.images['My8BitImg.png'].pixels))
This has returned 256, while
len(set(bpy.data.images['My16BitImg.png'].pixels))
has returned 42891 in my case.
answered 2 hours ago
SerhiiPoklonskyiSerhiiPoklonskyi
464
$endgroup$
add a comment |
$begingroup$
short answer: as @cegaton has pointed out, save your image with 16 bits depth. If you are baking like me, this has to be done before bake, because resaving later does not generate information lost while baking.
Go to 'Save as' dialog, there in the lower left corner choose 16 bits depth.
A (not so) technical explanation: if you are not familiar, depth is the number of bits used to store the pixel color. With 8 bits, you store 2^8 = 256 color values at maximum, with 16 bits that's 2^16 = 65536 possible colors. What was happening in my case is the following: for the different height values in the geometry that I was baking, an approximation was generated to store the height. In other words, for heights x-0.01, x, x+0.01s, it would simply put x, because it has no bits to store all the three. Hence the flat areas in your image, where the color gets 'simplified'. For my 8 bits image, I did for learning purposes:
len(set(bpy.data.images['My8BitImg.png'].pixels))
This has returned 256, while
len(set(bpy.data.images['My16BitImg.png'].pixels))
has returned 42891 in my case.
answered 2 hours ago
SerhiiPoklonskyiSerhiiPoklonskyi
464
$endgroup$
add a comment |
$begingroup$
short answer: as @cegaton has pointed out, save your image with 16 bits depth. If you are baking like me, this has to be done before bake, because resaving later does not generate information lost while baking.
Go to 'Save as' dialog, there in the lower left corner choose 16 bits depth.
A (not so) technical explanation: if you are not familiar, depth is the number of bits used to store the pixel color. With 8 bits, you store 2^8 = 256 color values at maximum, with 16 bits that's 2^16 = 65536 possible colors. What was happening in my case is the following: for the different height values in the geometry that I was baking, an approximation was generated to store the height. In other words, for heights x-0.01, x, x+0.01s, it would simply put x, because it has no bits to store all the three. Hence the flat areas in your image, where the color gets 'simplified'. For my 8 bits image, I did for learning purposes:
len(set(bpy.data.images['My8BitImg.png'].pixels))
This has returned 256, while
len(set(bpy.data.images['My16BitImg.png'].pixels))
has returned 42891 in my case.
answered 2 hours ago
SerhiiPoklonskyiSerhiiPoklonskyi
464
$endgroup$
short answer: as @cegaton has pointed out, save your image with 16 bits depth. If you are baking like me, this has to be done before bake, because resaving later does not generate information lost while baking.
Go to 'Save as' dialog, there in the lower left corner choose 16 bits depth.
A (not so) technical explanation: if you are not familiar, depth is the number of bits used to store the pixel color. With 8 bits, you store 2^8 = 256 color values at maximum, with 16 bits that's 2^16 = 65536 possible colors. What was happening in my case is the following: for the different height values in the geometry that I was baking, an approximation was generated to store the height. In other words, for heights x-0.01, x, x+0.01s, it would simply put x, because it has no bits to store all the three. Hence the flat areas in your image, where the color gets 'simplified'. For my 8 bits image, I did for learning purposes:
len(set(bpy.data.images['My8BitImg.png'].pixels))
This has returned 256, while
len(set(bpy.data.images['My16BitImg.png'].pixels))
has returned 42891 in my case.
answered 2 hours ago
SerhiiPoklonskyiSerhiiPoklonskyi
464
answered 2 hours ago
SerhiiPoklonskyiSerhiiPoklonskyi
464
answered 2 hours ago
SerhiiPoklonskyiSerhiiPoklonskyi
464
answered 2 hours ago
SerhiiPoklonskyiSerhiiPoklonskyi
464
464
add a comment |
add a comment |
Thanks for contributing an answer to Blender Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fblender.stackexchange.com%2fquestions%2f135103%2fheight-map-for-normal-input-sharp-edges%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
pYFJR5aFe11y,MafTr0,oMiMfbK2 EAF3330zO2NlVJVt8U zzLN97,rU454cr7A9U5
1
$begingroup$
It might have to do with the bit depth of the height map. 8 bit images are not enough to resolve subtle gradation. Try using images in a higher bit depth. Also, images used for bumps and normals should not be interpreted as color, but as Non-Color-Data (linear)
$endgroup$
– cegaton
4 hours ago
$begingroup$
@cegaton thanks for responding. bpy.data.images['...'].depth tells me it's 32 bit depth (is this the right indicator?). Also, changing to non-color does not affect the result. take a look at the last illustration: CrazyBump can algorithmically ignore or exaggerate those cuttoffs by setting its degree of attention to fine details
$endgroup$
– SerhiiPoklonskyi
4 hours ago
2
$begingroup$
32 bit is 8bit per channel+Alpha (8 bit x 4). Try creating the image as a 16 bit per channel file. Non-color data should always be used for bump and height maps to avoid the distortion caused by the 2.2 gamma curve used in image encoded in sRGB. You might get better results using a displace modifer and subsurf than using displacement in the material or shader.
$endgroup$
– cegaton
4 hours ago
$begingroup$
@cegaton holy Jesus! it has solved the problem! marry me, cegaton! I totally agree with you with regard to displacement but my idea was to combine individual alpha elements to produce reliefs and cravings easily. now it will work thanks to you. if you so wish, post an answer for others, probably with a bit of explanation on depth and how it affects the result
$endgroup$
– SerhiiPoklonskyi
3 hours ago
1
$begingroup$
will do it soon. Thank you again
$endgroup$
– SerhiiPoklonskyi
3 hours ago