Sorry you are having problems. This isn't something we have been able to reproduce as of yet. Could you please try performing a clean installation of the latest GPU driver using the directions in the following link please? https://docs.knaldtech.com/doku.php?id=clean_driver_installation_1.1
Could you also try deleting the Knald.ini from %username%\AppData\Roaming\Knald Technologies to see if that helps too?
If the above dont work then could you please send over a mesh that is causing the problem for you so we can take a look? Also please send over a copy of the settings you are using for the bake please (a screenshot of the baker tab should be enough). Send the meshes and information to support@knaldtech.com
Cheers!
After i try performing a clean installation of the latest GPU driver, the issue has gone. Thank you very much!
My only request to further improve Knald would be Bake base texture (any color or greyscale input maps (preferably multiple at once to avoid having to restart the bake for each map type) , and also the ability to correctly bake base tangent space normal maps (that are applied to a highpoly) to a lowpoly model- this would allow a fairly detailed but not insanely highres tree to be baked down to a planar billboard/atlas and retain both the broad geo normals and the detailed normal map from the input scan texture ).
I know you mentioned the base texture stuff was in the works before, so will continue to look forward to it! Thanks for the awesome product, really is a joy to use and get such nice quality results quickly with!
Thanks for the kind words! I will make sure to add your requests to our user wish list. It's always great to get specific feedback like this
A note about bent normals : I just wanted to point out that when many artists mention that they want a "bent normals" bake, what they actually want is an object-space bake - because the Y channel of such a bake contains top-down lighting information, which is indeed very useful in order to simulate dust deposit or even "painted-in " lighting.
The confusion comes from Xnormal which only has one render output slot for normal (forcing the user to either choose tangent or object space, with no ability to render both at the same time). Users then realized that the "bent normals" output slot produces ... an object space bake. What logically followed is that users understandably started to choose "bent normals" as their bake output in order to get an object space bake for the sake of not having to run the bake two times.
This was a bit of side note but I thought I'd mention it in order to avoid any confusion between you and your user base regarding this feature. As a matter of fact, even though I've heard of their application as you describe it, I don't think I have ever run into any real-time engine actually using bent normals as an input, whereas 100% of the artists I ever talked to equate "bent normals" to "that odd colored bake with top down lighting in the y channel".
In short - if I am not mistaken, when programmers or a persons involved in offline rendering think of bent normals, my understanding is that they think of this (= normal data modified in such a way so that reflections don't appear in unwanted places, like nostrils, thanks to a "bending down" of the normals in these areas) :
Whereas when artists ask for a baker to support "bent normals" output, what they actually want is this (which is simply an object space bake ) :
At the end of the day words are just labels and what really matters is the way we use these tools, but I just hope this clarifies things a little and avoids confusion.
A note about bent normals : I just wanted to point out that when many artists mention that they want a "bent normals" bake, what they actually want is an object-space bake - because the Y channel of such a bake contains top-down lighting information, which is indeed very useful in order to simulate dust deposit or even "painted-in " lighting.
The confusion comes from Xnormal which only has one render output slot for normal (forcing the user to either choose tangent or object space, with no ability to render both at the same time). Users then realized that the "bent normals" output slot produces ... an object space bake. What logically followed is that users understandably started to choose "bent normals" as their bake output in order to get an object space bake for the sake of not having to run the bake two times.
This was a bit of side note but I thought I'd mention it in order to avoid any confusion between you and your user base regarding this feature. As a matter of fact, even though I've heard of their application as you describe it, I don't think I have ever run into any real-time engine actually using bent normals as an input, whereas 100% of the artists I ever talked to equate "bent normals" to "that odd colored bake with top down lighting in the y channel".
In short - if I am not mistaken, when programmers or a persons involved in offline rendering think of bent normals, my understanding is that they think of this (= normal data modified in such a way so that reflections don't appear in unwanted places, like nostrils, thanks to a "bending down" of the normals in these areas) :
Whereas when artists ask for a baker to support "bent normals" output, what they actually want is this (which is simply an object space bake ) :
At the end of the day words are just labels and what really matters is the way we use these tools, but I just hope this clarifies things a little and avoids confusion.
Hi Pior,
Thanks for the feedback.
While it is true, and somewhat unfortunate, that many artists use the term Bent normals as a misnomer for OS normals, we have to try our best to name our bake targets as accurately as possible (along with everything else in Knald) so that we do not propagate misinformation. Hopefully the more prevalent these maps become, the more artists will understand the difference between the two targets and start to use the correct terminology for them. People can already bake OS normals in Knald as a separate target, which is named correctly lucky for us!
Interestingly I thought it might be worth mentioning that there is absolutely no difference between Bent Normals in realtime and offline rendering (as fundamentally a normal from a normal map represents a direction perpendicular to the surface whereas bent normal direction represents a primary line of sight). In their natural/native textbook state they are what you see in Knald when you disable normalization rather than the Renderman example linked above (which is simply a remapping of the original data).
It's actually very easy to remap the data to match the Renderman example too:
Export Bent Normal map "normalized"
Invert the Magnitude (contained in the Alpha channel of the exported texture) in Photoshop.
Create a 128, 128, 128 base colour layer and place it below the Bent Normal Layer
Assign the inverted Magnitude as a mask on the Bent Normal layer.
It's probably also worth mentioning that we were petitioned to add these primarily for realtime use too. The course Advances in Real-Time Rendering in Games at Siggraph 2016 show that they have started to gain prominence in this regard, so I think we will end up seeing them more in the future for this purpose.
In regards to them being useful for masking in MOBA texturing, we suggested this only because they produce interesting results in the magnitude and the green channel because of the way bent normals work, rather than any confusion in the terminology or anything like that.
Thanks again for the post, Pior. It's nice to clear this type of thing up so everyone is reading from the same page, so to speak.
I tried to find more information about bent normals and there is surprisingly little information about that. Even in the Siggraph link you provided there is no information about bent normals. Also, there is not a single shader that I am aware of which can use this for realtime rendering.
I appreciate the forward looking attitude though. Very much. Do you know how I can get this to work in Unity?
I tried to find more information about bent normals and there is surprisingly little information about that. Even in the Siggraph link you provided there is no information about bent normals. Also, there is not a single shader that I am aware of which can use this for realtime rendering.
I appreciate the forward looking attitude though. Very much. Do you know how I can get this to work in Unity?
Hi BitBarrel,
There is quite a bit of information if you dig into the Siggraph 2016 papers
I am investigating the trial today. You guys are thinking every single low level detail possible but there is not a single cube in 3d previewer. Yeah, a simple cube would be nice, wouldnt it ?
We added the cube primitive for you in 1.2.0! Enjoy
Hello, i'd love to know if we have any option to change the size of edge padding? that'd be great!
Hi! Currently there is no way to have anything other than 0 or 100% dilation. It's not really something that we are looking at changing as it's the best option on a technical level as it guarantees no seams when mipped.
May I ask why you want something less than 100%?
Hello, i'd love to know if we have any option to change the size of edge padding? that'd be great!
Hi! Currently there is no way to have anything other than 0 or 100% dilation. It's not really something that we are looking at changing as it's the best option on a technical level as it guarantees no seams when mipped.
May I ask why you want something less than 100%?
ah, because sometimes when I bake several objects ( gun's parts for the example), then combine all the maps that I've baked into one map, some maps that didn't have alpha chanel like AO or carvity to select, and I have to use the alpha chanel of normal map and expand the seam when combine them
I'm having a problem getting Concavity, Convexity and Curvature maps to bake properly. I have a high poly sculpt from Zbrush and I'm trying to bake it to a plane with Knald. When I try this, all the maps bake out as solid black or white, but all the other maps (Normal, AO, etc) are fine. When I do the same bake with xNormal, the Concavity, Convexity and Curvature maps all come out fine. Anyone have any input on what I'm doing wrong?
Hello, i'd love to know if we have any option to change the size of edge padding? that'd be great!
Hi! Currently there is no way to have anything other than 0 or 100% dilation. It's not really something that we are looking at changing as it's the best option on a technical level as it guarantees no seams when mipped.
May I ask why you want something less than 100%?
ah, because sometimes when I bake several objects ( gun's parts for the example), then combine all the maps that I've baked into one map, some maps that didn't have alpha chanel like AO or carvity to select, and I have to use the alpha chanel of normal map and expand the seam when combine them
Thanks for the feedback. I can't make any promises but I will see what I can do.
I'm having a problem getting Concavity, Convexity and Curvature maps to bake properly. I have a high poly sculpt from Zbrush and I'm trying to bake it to a plane with Knald. When I try this, all the maps bake out as solid black or white, but all the other maps (Normal, AO, etc) are fine. When I do the same bake with xNormal, the Concavity, Convexity and Curvature maps all come out fine. Anyone have any input on what I'm doing wrong?
Thanks!
It's hard to debug situations like this without seeing the meshes. Is there any chance you could send them to be so I can try to reproduce this please?
It's hard to debug situations like this without seeing the meshes. Is there any chance you could send them to be so I can try to reproduce this please?
It's hard to debug situations like this without seeing the meshes. Is there any chance you could send them to be so I can try to reproduce this please?
No problem! The reason you are not seeing the smoothing is because the high poly mesh has lots of smoothing groups/hard edges or is exported as faceted. Removing this smoothing fixes the issue.
Below I just exported the mesh with a single smoothing group and everything baked as expected.
No problem! The reason you are not seeing the smoothing is because the high poly mesh has lots of smoothing groups/hard edges or is exported as faceted. Removing this smoothing fixes the issue.
Below I just exported the mesh with a single smoothing group and everything baked as expected.
Hope that helps!
Thanks a lot! That OBJ was exported directly from Zbrush. When I use the export feature in Zbrush, it doesn't actually give me any export options. How would I go about resolving this? Would I have to bring it into Blender and re-export or something?
No problem! The reason you are not seeing the smoothing is because the high poly mesh has lots of smoothing groups/hard edges or is exported as faceted. Removing this smoothing fixes the issue.
Below I just exported the mesh with a single smoothing group and everything baked as expected.
Hope that helps!
Thanks a lot! That OBJ was exported directly from Zbrush. When I use the export feature in Zbrush, it doesn't actually give me any export options. How would I go about resolving this? Would I have to bring it into Blender and re-export or something?
I can't think of any reason of the top of my head that would cause the vertex normals to go crazy like that. It's not something I have experienced first hand when exporting directly from ZBrush. That said importing into blender and re-exporting would fix the issue as long as your export settings are correct.
I can't think of any reason of the top of my head that would cause the vertex normals to go crazy like that. It's not something I have experienced first hand when exporting directly from ZBrush. That said importing into blender and re-exporting would fix the issue as long as your export settings are correct.
I've tried re-exporting the High Poly from Blender a number of times with a number different options now (Re-calculating normals, smooth/sharp shading, smooth groups on/off, etc) and I'm still getting wonky results. How did you manage to get the result you did?
New build ahoy! Since the 1.2.0 release of Knald we have been hard at work fixing a few bugs and adding a few miscellaneous under the hood improvements. Time for the Knald 1.2.1 Hotfix release!
What’s changed since Knald 1.2.0?
New Features, Improvements and Optimizations
Miscellaneous improvements and optimizations.
Bug fixes
Fixed an issue where some meshes would cause an optimization error during baking.
Fixed an issue where IMG AO doesn’t show correctly if Normal & AO were baked and then the integrator is updated.
Fixed an issue where Mesh AO doesn’t show correctly after switching between the AO & Transmission tabs.
Fixed an issue where the AO group would not show if Normal, Transmission & AO were baked and then the integrator is updated.
Fixed an issue where the Mesh AO activation checkbox appears inverted relative to UI after integration.
Fixed an issue where the Baker Height & Width spinboxes could get out of sync.
Fixed an issue where the Bake button doesn’t revert to the correct pre-process state after loading a .ksf
Once again we would like to thank everyone for the invaluable feedback we have received since the last release. Don't forget to check out the awesome Flipped Normals tutorial (Creating Characters for Games) by Gavin Goulden https://flippednormals.com/tutorial/creating-characters-games/ & please do continue sending us suggestions & posting everything you can!
Social Media
Don't forget you can follow us on Social media via the following accounts on Facebook & Twitter!
I have another question. Even though I have dilation checked (and rebaked) and the texture preview window shows dilation, when I export, my Tangent Normals, OS Bent Normals and height maps don't get dilated.
If I choose to bake out the TS Bent Normals it looks the same as the Tangent Normal Map only with dilation. The problem is, the TS Bent Normal map doesn't seem to be affected by the Bump Scale value in the Normal settings.
What format are you exporting as? PNG can have issues where programs always import it with the alpha channel as transparent pixels, which might be why you are seeing
the transparent pixels and no dilation/bleed. Windows explorer also displays the alpha as transparency because it is the most efficient way to show that
there are 4 channels present in the image.
Hope that helps!
Bent normals are not controlled by the regular "bump scale" slider as they are baked using a different process.
While they do contain directional data similar to that of normal maps,
they are actually more similar to Ambient Occlusion maps as they include
a form of occlusion data via the bent normal (i.e. the occlusion value
of the mean ray/weighted average that does not intersect with the high
poly mesh after hemisphere sampling) which represents the weighted
average of all unoccluded directions. When you export the occlusion data is stored within the Alpha channel by default (which you might not be able to see very well if you are using png), but you can also view it as grey pixels by unchecking the "normalisation" checkbox in the bent normal tab.
Can you please try exporting as Tiff? I find that it's a much better format to work with.
I was exporting as PNG, which just don't seem to export with dilation. I exported as TIFF and at first glance the maps didn't have dilation, but after opening them in Photoshop, I was able to remove the Alpha channel which was masking the bleed. Problem solved! Thanks again!
I'll have to read more on Bent Normals. Thanks for the info!
I've been having issues with the Knald license after the last update. I'm getting a Fatal Error. 'Error in licence authentication. Please try again later or contact support.' Any known issue causing this?
Common reasons for this error could be one of the following:
You have activated Knald too many times and need to free up an activation via the website (https://www.knaldtech.com/licenses/ >View & Manage Keys> Reset.)
You are using a demo key with a Studio or Freelancer build
If you try all those and you still cant get up and running please contact support (support@knaldtech.com) & I'm sure we will be able to get you up and running again.
Hey @metalliandy Excuse me if someone has asked this before but I want to know if there's a workaround to my following issue. So I tend to get my AO maps from Knald after I get the normal maps from Substance. Now iIl usually have multiple texture sets to my model. To get proper AO map from Knald I have to make specific mesh for EACH texture set where I have moved the other texture sets' UV islands out of the way. I do that because I need the AO for the UVs that I'm currently baking but at the same time I need it to get information from the rest of the mesh. Not sure if I'm explaining things properly. My question is, is there an option bake AO to a specific texture set and not to all of them?
Sorry for the confusion and thnanks for your time!
@DanaosC Currently we dont have the ability for the user to pick which UVs they want to bake to, but it is something that has been requested and is most definitely on our TODO list. Hopefully soon
Hi, i have downloaded the demo but i can't bake, i use the Blender Monkey has high poly and a plane for the low. When i click Bake it's always empty. I have UVs for the low poly and it works on other software. I have a GTX 1070 and the latest driver at the time i am writting.
Thank you it bakes but now i have a weird error. The empty area arround Suzanne is generating a weird texture like if it was an edge padding, but even with padding i should get nothing since everything is baked inside the UV plane.
Also what is the best blend type to combine the concavity and convexity textures ?
@Linko That's not a error It's because you dont have anything behind Suzanne and they rays haven't hit anything. When this happens Knald dilates to make ray misses less problematic for the end user. Hope that helps!
@metalliandy: in Blender Cycles when the rays hits nothing we get an alpha arround the model and it's also directly displayed in the 3D viewport, it makes it easier to then export to Unity and get fake 3D models like billboards. Blender Cycles baking result:
@Linko Indeed, I'm very familiar with the Baker in Blender. The reason we dilate for ray misses is we dont want holes in the mesh where rays didn't hit. By using dilation Knald fills such holes which 99% of the time is the correct choice for users. Having said that, you can get the exact same result in Knald by selecting "Soft Alpha from HP" in the preferences tab and exporting as png. You will have to copy the alpha channel over when exporting single channel textures however as we only export alpha with RGB textures.
I've been having some problems with AO recently. I always seem to get these annoying pixel spots on my AO maps. I have tried everything to get rid of them. Any input on what's going on?
@metalliandy Nevermind! I figured it out. Going through the smoothing steps you mentioned before fixed this as well. Not sure what the relation is, but problem solved.
I'm a new user to Knald, and have a question. Is there a feature in Knald similar to the 'Match by Mesh Name' feature in Substance Painter? Meaning, can I have a mesh with separate sub-meshes that do not affect each other/ e.g. only cast Occlusion on themselves (self-occlusion), but not onto the other objects?
Why is it that I can load several high res meshes into Knald, but only 1 low res mesh?
Hi @wilson66 Sorry for the late reply, For some reason I haven't been getting forum notifications for this thread or only getting them sporadically. Yes, we do plan on adding the ability to have multiple low poly meshes and it's very high on our todo list. Hopefully people won't have to wait too long
Yes, we do plan on adding the ability to have multiple low poly meshes and it's very high on our todo list. Hopefully people won't have to wait too long
Thanks for your answer, thats very nice to hear! Its a feature I use in Substance Painter all the time, so it would be great to have it in Knald.
Yes, we do plan on adding the ability to have multiple low poly meshes and it's very high on our todo list. Hopefully people won't have to wait too long
Thanks for your answer, thats very nice to hear! Its a feature I use in Substance Painter all the time, so it would be great to have it in Knald.
I have a two questions about AO baking and especially the concavity and convexity. Are those maps generated from the normal map by default ? If yes that would explain why the baking is so fast, but i am not a fan of generated textures from another, it is better to bake from the high poly to avoid artefacts and visible seams especially for a curvature no? I have discovered that Substance does almost all his bake from the normal map.
What is the difference between a cavity and curvature, i thought a cavity was generated from a normal map (more artefacts and errors) and a curvature from the high poly, but i think i am wrong. ^^
Baking in Knald is so fast because it uses the GPU to generate the maps (in comparison to most other solutions using the CPU), not because it uses normal maps to generate AO. You can generate AO without any NM created prior!
Substance Painter also uses the high poly mesh (assuming that you linked one in the High Definition Meshes section of the Baking window), it does not exclusively use the NM.
Cavity maps represent just the cavities, while curvature maps represent both cavities and convexities. Both can be generated using the high poly mesh in both applications.
I have a two questions about AO baking
and especially the concavity and convexity. Are those maps generated
from the normal map by default ? If yes that would explain why the
baking is so fast, but i am not a fan of generated textures from
another, it is better to bake from the high poly to avoid artefacts and
visible seams especially for a curvature no? I have discovered that
Substance does almost all his bake from the normal map.
What is
the difference between a cavity and curvature, i thought a cavity was
generated from a normal map (more artefacts and errors) and a curvature
from the high poly, but i think i am wrong. ^^
All the maps in the baker are generated from the High Poly as It's the only way to get superior results. This includes AO, Cavity/Convexity & Curvature. As @wilson66 said, Cavity represents cavities or 'valleys', Convexity represents the convex areas or 'peaks' and Curvature is a combination of both Cavity and Convexity.
Y, that the reason i cant use Knald for AO bakes. It looks not correct in any of the new modes.
AO is baked from the High Poly within the baker and not generated from a normal map. I'm not sure why the AO wouldn't look correct though. Which new modes do you mean? Can you post an example of where it looks wrong please?
@wilson66 The NM will allways be generated - just check youre bakes.
This is correct actually. We always bake Normal, Height, Derivative and OS/TS Normal on every bake even if they are not selected as bake target. That said, we still don't use any images to generate any bakes within the baker
Hey Andy, seems i didnt completed all test with the new Version. I get just wrong AO with mirrored UV's - also with 16xAA in this case. So i have to build 2 LP (like in old days )
Replies
Thanks for the kind words!
I will make sure to add your requests to our user wish list. It's always great to get specific feedback like this
The confusion comes from Xnormal which only has one render output slot for normal (forcing the user to either choose tangent or object space, with no ability to render both at the same time). Users then realized that the "bent normals" output slot produces ... an object space bake. What logically followed is that users understandably started to choose "bent normals" as their bake output in order to get an object space bake for the sake of not having to run the bake two times.
This was a bit of side note but I thought I'd mention it in order to avoid any confusion between you and your user base regarding this feature. As a matter of fact, even though I've heard of their application as you describe it, I don't think I have ever run into any real-time engine actually using bent normals as an input, whereas 100% of the artists I ever talked to equate "bent normals" to "that odd colored bake with top down lighting in the y channel".
In short - if I am not mistaken, when programmers or a persons involved in offline rendering think of bent normals, my understanding is that they think of this (= normal data modified in such a way so that reflections don't appear in unwanted places, like nostrils, thanks to a "bending down" of the normals in these areas) :
Whereas when artists ask for a baker to support "bent normals" output, what they actually want is this (which is simply an object space bake ) :
At the end of the day words are just labels and what really matters is the way we use these tools, but I just hope this clarifies things a little and avoids confusion.
Thanks for the feedback.
While it is true, and somewhat unfortunate, that many artists use the term Bent normals as a misnomer for OS normals, we have to try our best to name our bake targets as accurately as possible (along with everything else in Knald) so that we do not propagate misinformation. Hopefully the more prevalent these maps become, the more artists will understand the difference between the two targets and start to use the correct terminology for them. People can already bake OS normals in Knald as a separate target, which is named correctly lucky for us!
Interestingly I thought it might be worth mentioning that there is absolutely no difference between Bent Normals in realtime and offline rendering (as fundamentally a normal from a normal map represents a direction perpendicular to the surface whereas bent normal direction represents a primary line of sight). In their natural/native textbook state they are what you see in Knald when you disable normalization rather than the Renderman example linked above (which is simply a remapping of the original data).
It's actually very easy to remap the data to match the Renderman example too:
It's probably also worth mentioning that we were petitioned to add these primarily for realtime use too. The course Advances in Real-Time Rendering in Games at Siggraph 2016 show that they have started to gain prominence in this regard, so I think we will end up seeing them more in the future for this purpose.
In regards to them being useful for masking in MOBA texturing, we suggested this only because they produce interesting results in the magnitude and the green channel because of the way bent normals work, rather than any confusion in the terminology or anything like that.
Thanks again for the post, Pior. It's nice to clear this type of thing up so everyone is reading from the same page, so to speak.
I appreciate the forward looking attitude though. Very much. Do you know how I can get this to work in Unity?
There is quite a bit of information if you dig into the Siggraph 2016 papers
Deferred Lighting in Uncharted 4 - slides 32-42
Practical Real-Time Strategies for Accurate Indirect Occlusion - pages 112-161
Currently people are writing their own shaders for internal use and there is no reason why such a shader wouldn't work within Unity,
Hope that helps!
We added the cube primitive for you in 1.2.0!
Enjoy
Currently there is no way to have anything other than 0 or 100% dilation. It's not really something that we are looking at changing as it's the best option on a technical level as it guarantees no seams when mipped. May I ask why you want something less than 100%?
I'm having a problem getting Concavity, Convexity and Curvature maps to bake properly. I have a high poly sculpt from Zbrush and I'm trying to bake it to a plane with Knald. When I try this, all the maps bake out as solid black or white, but all the other maps (Normal, AO, etc) are fine. When I do the same bake with xNormal, the Concavity, Convexity and Curvature maps all come out fine. Anyone have any input on what I'm doing wrong?
Thanks!
It's hard to debug situations like this without seeing the meshes. Is there any chance you could send them to be so I can try to reproduce this please?
Here they are:
https://drive.google.com/open?id=0B2RuD4Cn54aGM1ExYlZudXJ5OWs
Thanks for the quick reply!
Below I just exported the mesh with a single smoothing group and everything baked as expected.
Hope that helps!
Thanks again for the insight!
To remove the wonky vertex normals you can do one of the following:
Hope that helps!
New build ahoy! Since the 1.2.0 release of Knald we have been hard at work fixing a few bugs and adding a few miscellaneous under the hood improvements. Time for the Knald 1.2.1 Hotfix release!
What’s changed since Knald 1.2.0?
New Features, Improvements and Optimizations
Bug fixes
You can grab the new build from your account on https://www.knaldtech.com/ and can find the build notes here: https://www.knaldtech.com/knald-update-build20161207001/
Once again we would like to thank everyone for the invaluable feedback we have received since the last release. Don't forget to check out the awesome Flipped Normals tutorial (Creating Characters for Games) by Gavin Goulden https://flippednormals.com/tutorial/creating-characters-games/ & please do continue sending us suggestions & posting everything you can!
Social Media
Don't forget you can follow us on Social media via the following accounts on Facebook & Twitter!
Thanks for the help!
I have another question.
Even though I have dilation checked (and rebaked) and the texture preview window shows dilation, when I export, my Tangent Normals, OS Bent Normals and height maps don't get dilated.
If I choose to bake out the TS Bent Normals it looks the same as the Tangent Normal Map only with dilation. The problem is, the TS Bent Normal map doesn't seem to be affected by the Bump Scale value in the Normal settings.
How do I get these maps to dilate on export?
Thanks again!
What format are you exporting as? PNG can have issues where programs always import it with the alpha channel as transparent pixels, which might be why you are seeing the transparent pixels and no dilation/bleed. Windows explorer also displays the alpha as transparency because it is the most efficient way to show that there are 4 channels present in the image. Hope that helps!
Bent normals are not controlled by the regular "bump scale" slider as they are baked using a different process. While they do contain directional data similar to that of normal maps, they are actually more similar to Ambient Occlusion maps as they include a form of occlusion data via the bent normal (i.e. the occlusion value of the mean ray/weighted average that does not intersect with the high poly mesh after hemisphere sampling) which represents the weighted average of all unoccluded directions. When you export the occlusion data is stored within the Alpha channel by default (which you might not be able to see very well if you are using png), but you can also view it as grey pixels by unchecking the "normalisation" checkbox in the bent normal tab.
Can you please try exporting as Tiff? I find that it's a much better format to work with.
Thanks for the quick reply!
I was exporting as PNG, which just don't seem to export with dilation. I exported as TIFF and at first glance the maps didn't have dilation, but after opening them in Photoshop, I was able to remove the Alpha channel which was masking the bleed. Problem solved! Thanks again!
I'll have to read more on Bent Normals. Thanks for the info!
I've been having issues with the Knald license after the last update. I'm getting a Fatal Error. 'Error in licence authentication. Please try again later or contact support.' Any known issue causing this?
Thanks
Sorry you are having problems.
Common reasons for this error could be one of the following:
If you try all those and you still cant get up and running please contact support (support@knaldtech.com) & I'm sure we will be able to get you up and running again.
Excuse me if someone has asked this before but I want to know if there's a workaround to my following issue.
So I tend to get my AO maps from Knald after I get the normal maps from Substance. Now iIl usually have multiple texture sets to my model.
To get proper AO map from Knald I have to make specific mesh for EACH texture set where I have moved the other texture sets' UV islands out of the way. I do that because I need the AO for the UVs that I'm currently baking but at the same time I need it to get information from the rest of the mesh.
Not sure if I'm explaining things properly. My question is, is there an option bake AO to a specific texture set and not to all of them?
Sorry for the confusion and thnanks for your time!
https://docs.knaldtech.com/doku.php?id=the_baker_knald_1.2#ray_projection_settings
Hope that helps!
Also what is the best blend type to combine the concavity and convexity textures ?
It's because you dont have anything behind Suzanne and they rays haven't hit anything. When this happens Knald dilates to make ray misses less problematic for the end user.
Hope that helps!
Blender Cycles baking result:
The reason we dilate for ray misses is we dont want holes in the mesh where rays didn't hit. By using dilation Knald fills such holes which 99% of the time is the correct choice for users. Having said that, you can get the exact same result in Knald by selecting "Soft Alpha from HP" in the preferences tab and exporting as png. You will have to copy the alpha channel over when exporting single channel textures however as we only export alpha with RGB textures.
Hope that helps!
Cheers!
Nevermind! I figured it out. Going through the smoothing steps you mentioned before fixed this as well. Not sure what the relation is, but problem solved.
Thanks again!
Why is it that I can load several high res meshes into Knald, but only 1 low res mesh?
Sorry for the late reply, For some reason I haven't been getting forum notifications for this thread or only getting them sporadically.
Yes, we do plan on adding the ability to have multiple low poly meshes and it's very high on our todo list. Hopefully people won't have to wait too long
I have a two questions about AO baking and especially the concavity and convexity. Are those maps generated from the normal map by default ? If yes that would explain why the baking is so fast, but i am not a fan of generated textures from another, it is better to bake from the high poly to avoid artefacts and visible seams especially for a curvature no? I have discovered that Substance does almost all his bake from the normal map.
What is the difference between a cavity and curvature, i thought a cavity was generated from a normal map (more artefacts and errors) and a curvature from the high poly, but i think i am wrong. ^^
Substance Painter also uses the high poly mesh (assuming that you linked one in the High Definition Meshes section of the Baking window), it does not exclusively use the NM.
Cavity maps represent just the cavities, while curvature maps represent both cavities and convexities. Both can be generated using the high poly mesh in both applications.
The NM will allways be generated - just check youre bakes.
As @wilson66 said, Cavity represents cavities or 'valleys', Convexity represents the convex areas or 'peaks' and Curvature is a combination of both Cavity and Convexity.
AO is baked from the High Poly within the baker and not generated from a normal map. I'm not sure why the AO wouldn't look correct though. Which new modes do you mean? Can you post an example of where it looks wrong please?
This is correct actually. We always bake Normal, Height, Derivative and OS/TS Normal on every bake even if they are not selected as bake target. That said, we still don't use any images to generate any bakes within the baker