height map for normal input sharp edges












1












$begingroup$


So I have generated this simple height map to test my add on:
enter image description here



That's the node setup and the result that I am having in Blender:
enter image description here



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:
enter image description here






height-map







share|improve this question











$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
    12 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
    12 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
    12 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
    11 hours ago








  • 1




    $begingroup$
    will do it soon. Thank you again
    $endgroup$
    – SerhiiPoklonskyi
    11 hours ago
















1












$begingroup$


So I have generated this simple height map to test my add on:
enter image description here



That's the node setup and the result that I am having in Blender:
enter image description here



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:
enter image description here






height-map







share|improve this question











$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
    12 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
    12 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
    12 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
    11 hours ago








  • 1




    $begingroup$
    will do it soon. Thank you again
    $endgroup$
    – SerhiiPoklonskyi
    11 hours ago














1












1








1





$begingroup$


So I have generated this simple height map to test my add on:
enter image description here



That's the node setup and the result that I am having in Blender:
enter image description here



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:
enter image description here






height-map







share|improve this question











$endgroup$




So I have generated this simple height map to test my add on:
enter image description here



That's the node setup and the result that I am having in Blender:
enter image description here



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:
enter image description here






height-map




height-map






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 12 hours ago







SerhiiPoklonskyi

















asked 12 hours ago









SerhiiPoklonskyiSerhiiPoklonskyi

566




566








  • 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
    12 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
    12 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
    12 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
    11 hours ago








  • 1




    $begingroup$
    will do it soon. Thank you again
    $endgroup$
    – SerhiiPoklonskyi
    11 hours ago














  • 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
    12 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
    12 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
    12 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
    11 hours ago








  • 1




    $begingroup$
    will do it soon. Thank you again
    $endgroup$
    – SerhiiPoklonskyi
    11 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
12 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
12 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
12 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
12 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
12 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
12 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
11 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
11 hours ago






1




1




$begingroup$
will do it soon. Thank you again
$endgroup$
– SerhiiPoklonskyi
11 hours ago




$begingroup$
will do it soon. Thank you again
$endgroup$
– SerhiiPoklonskyi
11 hours ago










1 Answer
1






active

oldest

votes


















3












$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.






share|improve this answer











$endgroup$













  • $begingroup$
    If you want the images to be part of the file you have to "Pack" them. Then you don't need to reload anything. Read: when shoudl I pack an image into the file? and blender.stackexchange.com/questions/1336/…
    $endgroup$
    – cegaton
    5 hours ago












  • $begingroup$
    @ SerhiiPoklonskyi please keep the anwser on topic. To share other information, you can ask a question and answer it as well, so that others can find it easier instead of thinking: I need to find out how to reload an image, should I do a search for height maps or sharp edges?
    $endgroup$
    – cegaton
    4 hours ago












  • $begingroup$
    sorry, deleted the edit
    $endgroup$
    – SerhiiPoklonskyi
    4 hours ago











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
});


}
});














draft saved

draft discarded


















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









3












$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.






share|improve this answer











$endgroup$













  • $begingroup$
    If you want the images to be part of the file you have to "Pack" them. Then you don't need to reload anything. Read: when shoudl I pack an image into the file? and blender.stackexchange.com/questions/1336/…
    $endgroup$
    – cegaton
    5 hours ago












  • $begingroup$
    @ SerhiiPoklonskyi please keep the anwser on topic. To share other information, you can ask a question and answer it as well, so that others can find it easier instead of thinking: I need to find out how to reload an image, should I do a search for height maps or sharp edges?
    $endgroup$
    – cegaton
    4 hours ago












  • $begingroup$
    sorry, deleted the edit
    $endgroup$
    – SerhiiPoklonskyi
    4 hours ago
















3












$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.






share|improve this answer











$endgroup$













  • $begingroup$
    If you want the images to be part of the file you have to "Pack" them. Then you don't need to reload anything. Read: when shoudl I pack an image into the file? and blender.stackexchange.com/questions/1336/…
    $endgroup$
    – cegaton
    5 hours ago












  • $begingroup$
    @ SerhiiPoklonskyi please keep the anwser on topic. To share other information, you can ask a question and answer it as well, so that others can find it easier instead of thinking: I need to find out how to reload an image, should I do a search for height maps or sharp edges?
    $endgroup$
    – cegaton
    4 hours ago












  • $begingroup$
    sorry, deleted the edit
    $endgroup$
    – SerhiiPoklonskyi
    4 hours ago














3












3








3





$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.






share|improve this answer











$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.







share|improve this answer














share|improve this answer



share|improve this answer








edited 4 hours ago

























answered 10 hours ago









SerhiiPoklonskyiSerhiiPoklonskyi

566




566












  • $begingroup$
    If you want the images to be part of the file you have to "Pack" them. Then you don't need to reload anything. Read: when shoudl I pack an image into the file? and blender.stackexchange.com/questions/1336/…
    $endgroup$
    – cegaton
    5 hours ago












  • $begingroup$
    @ SerhiiPoklonskyi please keep the anwser on topic. To share other information, you can ask a question and answer it as well, so that others can find it easier instead of thinking: I need to find out how to reload an image, should I do a search for height maps or sharp edges?
    $endgroup$
    – cegaton
    4 hours ago












  • $begingroup$
    sorry, deleted the edit
    $endgroup$
    – SerhiiPoklonskyi
    4 hours ago


















  • $begingroup$
    If you want the images to be part of the file you have to "Pack" them. Then you don't need to reload anything. Read: when shoudl I pack an image into the file? and blender.stackexchange.com/questions/1336/…
    $endgroup$
    – cegaton
    5 hours ago












  • $begingroup$
    @ SerhiiPoklonskyi please keep the anwser on topic. To share other information, you can ask a question and answer it as well, so that others can find it easier instead of thinking: I need to find out how to reload an image, should I do a search for height maps or sharp edges?
    $endgroup$
    – cegaton
    4 hours ago












  • $begingroup$
    sorry, deleted the edit
    $endgroup$
    – SerhiiPoklonskyi
    4 hours ago
















$begingroup$
If you want the images to be part of the file you have to "Pack" them. Then you don't need to reload anything. Read: when shoudl I pack an image into the file? and blender.stackexchange.com/questions/1336/…
$endgroup$
– cegaton
5 hours ago






$begingroup$
If you want the images to be part of the file you have to "Pack" them. Then you don't need to reload anything. Read: when shoudl I pack an image into the file? and blender.stackexchange.com/questions/1336/…
$endgroup$
– cegaton
5 hours ago














$begingroup$
@ SerhiiPoklonskyi please keep the anwser on topic. To share other information, you can ask a question and answer it as well, so that others can find it easier instead of thinking: I need to find out how to reload an image, should I do a search for height maps or sharp edges?
$endgroup$
– cegaton
4 hours ago






$begingroup$
@ SerhiiPoklonskyi please keep the anwser on topic. To share other information, you can ask a question and answer it as well, so that others can find it easier instead of thinking: I need to find out how to reload an image, should I do a search for height maps or sharp edges?
$endgroup$
– cegaton
4 hours ago














$begingroup$
sorry, deleted the edit
$endgroup$
– SerhiiPoklonskyi
4 hours ago




$begingroup$
sorry, deleted the edit
$endgroup$
– SerhiiPoklonskyi
4 hours ago


















draft saved

draft discarded




















































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.




draft saved


draft discarded














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





















































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







-

Popular posts from this blog

How to make a Squid Proxy server?

Image
1 I want to set up squid proxy server for monitoring user activity in a network and Internet Web URL filtering for user. I also want to configure the user login, user log, user access group, and block unwanted web sites in my network. Please help me and guide me the full process to do this. server proxy squid share | improve this question edited Jul 31 '12 at 14:45 Jorge Castro 37.1k 107 422 617 asked Jul 31 '12 at 5:16 Goivind Tiwari Goivind Tiwari ...
Read more

Is this a new Fibonacci Identity?

Image
6 1 $begingroup$ I have found the following Fibonacci Identity (and proved it). If $F_n$ denotes the nth Fibonacci Number, we have the following identity begin{equation} F_{n-r+h}F_{n+k+g+1} - F_{n-r+g}F_{n+k+h+1} = (-1)^{n+r+h+1} F_{g-h}F_{k+r+1} end{equation} where $F_1 = F_2 = 1$ , $r leq n$ , $h leq g$ , and $n, g, k in mathbb{N}$ . It is not too hard to show that this identity subsumes Cassini's Identity, Catalan's Identity, Vajda's Idenity, and d'Ocagne's identity to name a few. I have done a pretty thorough literature review, and I have not found anything like this, but I am still wondering if anyone has seen this identity before? I found this by accident after noticing some patterns in some analysis work I was doing, so if this is already known I would be curious to see w...
Read more

19世紀

Image
この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。 出典を追加して記事の信頼性向上にご協力ください。 （ 2012年3月 ） 千年紀: 2千年紀 世紀: 18世紀 - 19世紀 - 20世紀 十年紀: 1800年代 1810年代 1820年代 1830年代 1840年代 1850年代 1860年代 1870年代 1880年代 1890年代 19世紀に君臨した大英帝国。 19世紀 （じゅうきゅうせいき）は、西暦1801年から西暦1900年までの100年間を指す世紀。 目次 1 19世紀の歴史 1.1 国民国家の成立 1.2 帝国主義の興隆 1.3 列強の植民地争奪戦 2 できごと 2.1 1800年代 2.2 1810年代 2.3 1820年代 2.4 1830年代 2.5 1840年代 2.6 1850年代 2.7 1860年代 2.8 1870年代 2.9 1880年代 2.10 1890年代 2.11 1900年代 3 文化 3.1 文学 3.2 音楽 3.3 思想 3.4 科学 3.5 技術 4 人物 4.1 ヨーロッパ 4.1.1 政治家・王族 4.1.1.1 フランス 4.1.1.2 オーストリア＝ハンガリー 4.1.1.3 ロシア 4.1.1.4 イギリス 4.1.1.5 ドイツ（プロイセンほかドイツ領邦を含む） 4.1.1.6 北欧 4.1.1.7 イタリア 4.1.1.8 スペイン 4.1.1.9 ベルギー 4.1.1.10 ギリシア 4.1.2 軍人 4.1.3 実業家 4.1.4 科学と技術 4.1.5 思想と哲学・人文諸学 4.1.6 宗教 4.1.7 文学 4.1.8 美術 4.1.9 音楽 4.1.10 社会事業家 4.1.11 探検家・旅行家 4.1.12 料...
Read more