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
    7 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
    7 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
    7 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
    7 hours ago








  • 1




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








  • 1




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







SerhiiPoklonskyi

















asked 7 hours ago









SerhiiPoklonskyiSerhiiPoklonskyi

465




465








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








  • 1




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








  • 1




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






1




1




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




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










1 Answer
1






active

oldest

votes


















2












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



IMPORTANT EDIT. maybe that's a well known fact but I feel obligued to let others know: Blender does not reload images when you 'Save as'. ...which means that when you save it with the new depth, it will have the new depth there on the hard drive but not in Blender. ...so that you have to reload it, and now it will be okay. To sum up: create new image ---> save with new depth ---> reload ---> can use now. Again, maybe that's well known but IMHO that's super weird behavior and I spent last 5 hours to figure out what was going on. cheers






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
    18 mins 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









2












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



IMPORTANT EDIT. maybe that's a well known fact but I feel obligued to let others know: Blender does not reload images when you 'Save as'. ...which means that when you save it with the new depth, it will have the new depth there on the hard drive but not in Blender. ...so that you have to reload it, and now it will be okay. To sum up: create new image ---> save with new depth ---> reload ---> can use now. Again, maybe that's well known but IMHO that's super weird behavior and I spent last 5 hours to figure out what was going on. cheers






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
    18 mins ago


















2












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



IMPORTANT EDIT. maybe that's a well known fact but I feel obligued to let others know: Blender does not reload images when you 'Save as'. ...which means that when you save it with the new depth, it will have the new depth there on the hard drive but not in Blender. ...so that you have to reload it, and now it will be okay. To sum up: create new image ---> save with new depth ---> reload ---> can use now. Again, maybe that's well known but IMHO that's super weird behavior and I spent last 5 hours to figure out what was going on. cheers






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
    18 mins ago
















2












2








2





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



IMPORTANT EDIT. maybe that's a well known fact but I feel obligued to let others know: Blender does not reload images when you 'Save as'. ...which means that when you save it with the new depth, it will have the new depth there on the hard drive but not in Blender. ...so that you have to reload it, and now it will be okay. To sum up: create new image ---> save with new depth ---> reload ---> can use now. Again, maybe that's well known but IMHO that's super weird behavior and I spent last 5 hours to figure out what was going on. cheers






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.



IMPORTANT EDIT. maybe that's a well known fact but I feel obligued to let others know: Blender does not reload images when you 'Save as'. ...which means that when you save it with the new depth, it will have the new depth there on the hard drive but not in Blender. ...so that you have to reload it, and now it will be okay. To sum up: create new image ---> save with new depth ---> reload ---> can use now. Again, maybe that's well known but IMHO that's super weird behavior and I spent last 5 hours to figure out what was going on. cheers







share|improve this answer














share|improve this answer



share|improve this answer








edited 28 mins ago

























answered 5 hours ago









SerhiiPoklonskyiSerhiiPoklonskyi

465




465












  • $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
    18 mins 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
    18 mins 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
18 mins 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
18 mins 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

GameSpot

Image
body.skin-minerva .mw-parser-output table.infobox caption{text-align:center} GameSpot 戰地風雲：惡名昭彰2在Gamespot的評論 网站类型 新聞 持有者 CBS 创始人 Pete Deemer Vince Broady Jon Epstein 网站 http://www.gamespot.com/ 注册 Optional (free and paid) 推出时间 1996年5月1日 [1] GameSpot （中国大陆：游戏基地），於1996年5月由Pete Deemer和Vince Broady創立，是一個提供新聞、評論、預告片、下載及其他的相關資訊的電子遊戲網站。GameSpot被一間後來被CNET收購的企業ZDNet所收購。根據Alexa，GameSpot.com是200個網路擁擠最嚴重的網站之一。 除了由GameSpot員工創作的內容，網站還允許用戶寫評論、網誌、之後在網路論壇分享。一些在CNET旗下的GameFAQs分享。 2004年， GameSpot被Spike TV的觀眾選上「電子遊戲賞節目」贏得「最傑出遊戲網站。 [2] 其他的遊戲網站還有IGN、1UP.com、GameSpy是它最大的競爭對手。2008年，根據Compete.com的統計，「gamespot.com」吸引了最少6000萬人的點擊率。 [3] GameSpot的主頁鏈結了到最近新聞、評論、預告、和一些有關遊戲機的入口：Wii、任天堂DS、電腦遊戲、Xbox 360、PSP、PlayStation 2、PlayStation 3。它還有一列「最受歡迎遊戲名單」，還有給用戶快速獲得遊戲資訊的搜尋器。GameSpot 還包括一些小範圍的遊戲機：任天堂64、GameCube、Game Boy Color、Game Boy Advance、Xbox、PlayStation、SEGA Saturn、Dreamcast、Neo Geo Pocket Color、N-Gage、手機遊戲。 目录 1 歷史 1.1 國際歷史 1.2 著名的員工 2 評論和分...
Read more

日野市

Image
body.skin-minerva .mw-parser-output table.infobox caption{text-align:center} 日野市 日野市 日文轉寫  • 日文 日野市  • 平假名 ひのし  • 罗马字 Hino-shi 金剛寺（關東三十六不動尊靈場第9號）的不動堂 市旗 徽章 日野市在東京都的位置 日野市 日野市在日本的位置 坐标： 35°40′17″N 139°23′42″E  /  35.6714°N 139.395°E  / 35.6714; 139.395 国家   日本 地方 關東地方 都道府縣 東京都 接鄰行政區 府中市、國立市、立川市、昭島市、八王子市、多摩市 政府  • 市長 大坪冬彦 面积  •  总计 27.53 平方公里（10.63 平方英里） 人口 （2014年12月1日）  • 總計 183,323  • 密度 6,660/平方公里（17,200/平方英里） 象徵  • 市樹 樫  • 市花 菊花  • 市鳥 普通翠鳥 时区 日本標準時間 （UTC+9） 地方公共團體編號 13212-8 邮政编码 〒 191-8686 市役所地址 日野市神明一丁目12番1號 電話號碼 +81-42-585-1111 法人編號 1000020132128 網站 http://www.city.hino.lg.jp/ 人口：日野市官方網頁 日野市 （日语： 日野市 ／ ひのし   Hino shi   * / ? ）為一位于東京都（不含島嶼部分）中央地帶的城市。從東京站乘坐中央線特別快速列車45分鐘即可到該市。面積27.53km²。1963年（昭和38年）11月3日，該市開始實行市制，為全日本第559個市。汽車企業日野自動車的總部位於這裡。 往東京都特別區部的通勤率為20.9%，往八王子市的通勤率為12.0%（平成22年國勢調査）。 目录 1 概要 ...
Read more

Tu-95轟炸機

Image
body.skin-minerva .mw-parser-output table.infobox caption{text-align:center} 图-95 Ту–95 北约代号：熊（Bear） 一架在安格斯空军基地的图-95MS 概觀 類型 战略轰炸机 代號 北约代号： Bear （熊） 乘員 7名 駕駛員2名，機尾炮手1名，其他人員4名 首飛 1952年11月12日 服役 1956年 設計 圖波列夫設計局 產量 超过500架 現況 现役 主要用戶   蘇聯   俄羅斯 衍生機型 图-114、图-119、Tu-95 技术数据 長度 49.50米（162呎5吋） 翼展 51.10米（167呎8吋） 高度 12.12米（39呎9吋） 翼面積 310平方米（3,330平方呎） 空重 90,000公斤（198,000磅） 最大起飛重量 188,000公斤（414,500磅） 發動機 4具库兹涅佐夫NK-12MV型渦輪螺旋槳發動機 功率 4×11,000千瓦（14,800馬力） 性能數據 最大速度 925公里／時（500節，575哩／時） 爬升率 10米／秒（2,000呎／分） 最大升限 12,000米（39,000呎） 最大航程 15,000公里（8,100海浬，9,400哩） 翼負荷 606公斤／平方米（124磅／平方呎） 推重比 235 W／公斤（0.143馬力／磅） 武器装备 機炮 1具/2具AM-23型23公釐雷達控制機砲（機尾） 飛彈 空对地导弹： Kh-20、Kh-22 Kh-26、Kh-55 炸彈 60枚FAB-250炸彈，或 30枚FAB-500炸彈。 其他 载弹量（包括飞弹）：最多15,000公斤（33,000磅） Tu-95熊式MR型機 图-95 （俄语： Ту–95 ， 英语： Tu-95 ），北約代號： Bear （ 熊 ），是蘇聯圖波列夫設計局所研製，是全世界唯一服役的大型四渦輪螺旋槳發動機...
Read more