Home Technical Talk

Blender Procedural Baking

Chrismartinartist
polycounter lvl 3
Offline / Send Message
Chrismartinartist polycounter lvl 3

Hello, I am having an issue with baking a procedural texture down in Blender, for reference this has been my standard workflow for a while now without issue but for some reason this time the Normal map is producing really ugly harsh results - like there's a setting wrong somewhere. Normally it's the opposite issue with the baked Normal map appearing slightly too weak if anything. The version above is also after trying to water down and weaken the problem by changing colour stops in the ramp.

Above pictures 1 & 2, are a furnitue model with the full procedural material on it, the damage (yellowish exposed wood) parts of the model do all come from the same colour ramp as the base colour, and what I *think* is the issue is the position of the colour stops, the one at 0.590 and 0.595 are very close together so I'm wondering it it's that, but again, even removing 0.590 and moving 0.595 further right picture 3 above was the best result I could get.

It almost looks like I've baked it without changing it to non-colour but I have done this several times to check, and on 3 other models with the same material. The more you zoom in on the baked version the worse the effect looks.

Does anyone know what the issue is (I suspect the placement of stops on the ramps - but changing those makes the result really flat), and more importantly how I can get the baked result to look more like the first image. The goal is to bake everything to the 4 PBR maps, which I've done without issue this way dozens of times.

Thank you for your help.

Replies

  • okidoki
    Options
    Offline / Send Message
    okidoki polycounter lvl 2
    I see no normal map node here at all using any normal map texture and you are using some texture to produce a normal with the bump node and this after the use of an color ramp.. very disturbing.. :wink:

  • gnoop
    Options
    Offline / Send Message
    gnoop polycounter
    I  can admit  I  am not perfectly sure  I understand your issue .   if the color ramp is too  inconvenient you could use curve node.  it's perhaps a bit easier to  tweak since you can enlarge it and tweak the curve nodes very  precisely .      Also I would first   construct a complete single  height  input   for a single bump node.  Easier to control IMO.  Lots of blending  variants with math node.      Still your approach( blending two normals input together)  is totally possible too but I rather use it to blend in normal map baked in Cycles  for edge rounding (bevel node).    it's just  we have no idea what math is used  in this blending. Help doesn't detail it.  



    I usually use position input so any object copy would get slightly  different look .  Also AO shouldn't be multiplied to color   for  modern  PBR. it's just Evee  doesn't have an input  for it and in Cycles it's all automatic and not necessary .    

    If you mean your normal maps are too rough  I would  add some  hdr background first  and set  the lighting  and exposure  physically accurate  first.  then you can just adjust strength .
    My quick try in 7z .

    ps. All that said  Blender noice node  lacks some   features  based on blur  like slope blur  or loops  and require a tremendous amount  of workarounds to invent something close.     While it may be convenient to quickly do  automatic textures   they never reach same  level of realism Substance Designer  could provide  if we speak procedural materials.        I  wish Blender could do any sort of blur  or distance  fade  procedurally .    its node system is  so much more convenient than one in Substance Designer.

    ps2.  sometimes your noise or any kind of  node could produce an output beyond  0-1 range  .    it may confuse  color rump  my guess since  I suspect it works in 0-1  .  
    Also when you construct your shader  it might be helpful to connect  output node directly to  the node   you want to preview to figure out whats happening.  like color ramp , math or curve node .      It works  with 3d viewport  in  material preview mode  and  view transform /Agx / contrast  preset off in color management .     if the  math in negative range or beyond  0-1   you could use Map range  node  before  output to sort of normalize output  for preview .     Sometimes it helps  to figure out whats happening  in each stage of node flow.




  • Chrismartinartist
    Options
    Offline / Send Message
    Chrismartinartist polycounter lvl 3
    Thank you for your replies.

    The issue is I can't get the baked version to look like the procedural. 

    My workflow is usually to: use Bevel Shaders for a high to low bake, to get  the Normal Map for all the edge highlights. Then I procedurally texture the low poly by adding in bump nodes connected to the original baked Normal Map, and with any new stuff going through the height on the bump node (i.e. scratches, surface imperfections), then I re-bake it for the final Normal Map which combines both the edges Normal Map, with the procedural bump into one Normal Map. Most of moy more recent works have used this technique and have been working fairly well (I think!)
    If there's a better way of doing this (I don't have access to Substance) then I don't know it, but would be grateful to hear.

    With anything I make, I need to bake it down to a set of 4x pbr maps 99% of the time, as what I'm making is intended as game assets, and I often show it on Sketchfab too. My understanding is that I need an Albedo,, Metalness, Roughness, and Normal Map for that, any additional maps may not be supported.

    When you say multiplying an AO map over the base colour is wrong because cycles does it anyway, I'm not sure I follow. If I don't use AO in cycles (procedurally or baked) it doesn't seem to get any AO from what I can see, in viewport or render.

    I didn't know Normal maps are in the 0-1 range, or that a Curve node would be a good thing to use here.

    Are there better procedural workflows in Blender?
  • gnoop
    Options
    Offline / Send Message
    gnoop polycounter
    I meant that AO is usually  done as a separate texture or texture channel.  Because  you  shouldn't see any AO  on pixels  illuminated by direct sun light  for example , only in shades . So it's not included into base color  texture usually.     Cycles , same  as any ray tracer in general doesn't need AO  because same effect occurs by  ray tracing naturally . Thus Blender materials doesn't have AO  input.     They are OSL  shaders designed for Cycles  and when you use Evee  Blender uses sort of OSL to GLSL  real-time translator.   You still can  bake AO into color  if you want but usually it's not necessary.

       Normal map input  in Blender  needs  -1 to 1 range  and it's what  normal map  node does ,    turning  0-1  normal map into  -1to 1   .    But in the textures   normal maps should be indeed  in 0-1 range  and  texture baker bakes it that way anyway.  So you don't need to care too much about it.        When you save  baked  normal map image  be sure you  use   non-color in save image dialog . Otherwise it  would apply  sRGB gamma on top of it .   Or just save everything as exrs .  

    Be aware also that when you bake bevel shader  in Cycles into a normal map  and then apply  this very same  normal map  to normal input  of your shader  it never looks same rounded   until you switch to Evee .   it's a known limitation  in all ray tracers,   not only Cycles.     Not sure  if you mean this difference in the look  of materials   but in typical  game  your rounded edges will be fine.   It's just ray tracers do it  differently .
Sign In or Register to comment.