Hey, we've been having some issues with Knald at times when baking very
noises meshes, most of the maps come out fine, but the Curvature and
Concavity maps always have really ugly artefacts that make those maps
useless. Baking the same meshes with xN gives good results.
Hey, we've been having some issues with Knald at times when baking very
noises meshes, most of the maps come out fine, but the Curvature and
Concavity maps always have really ugly artefacts that make those maps
useless. Baking the same meshes with xN gives good results.
Anyone come across this before? Any solutions?
Hi!
At first glance I would say that this is due to artifacts due to decimation. Often after decimation, faces can become distorted and overlap themselves and this is a limitation of the decimation process rather than something Knald is specifically doing. As we bake real/accurate curvature/concavity from the high poly source, Knald will pick up any errors in the mesh such as this. Having said that you can fix these errors in your 3D application by selecting the affected verts and performing a small relax on them or perhaps a small relax on the whole mesh. When I get back to my main workstation I will post an example image.
Yeah indeed, the artist was decimating to have a smaller file size, was helpful when iterating with xNormal, as it reloads the hipoly each time. Since Knald keeps the hipoly loaded it seems when baking, there's no real need to do it, so we'll just keep the full ~10mil point obj files for bakes from now on. Was just surprised xN didn't have that issue, but I guess the curvature and concavity algos aren't exactly the same.
Is there a beta out with SubMesh support? I really need this, I don't see a way around it with the models I have created. I have several(6) 4k models that have their own UV space that intersect.
EDIT: Sorry for adding yet another SubMesh comment. v_v
It would be really handy if you can tag sub-meshes which are to be excluded of contributing to an AO bake on a per-texture set basis. Dynamic objects (which can move/rotate) should generally not affect other geometry AO wise, but depending on the shape, may in some cases receive AO from neighboring geometry. This is not easily solvable with name matching like with normal bakes. It requires some sort of object tag system.
Of course you can make separate high res meshes only to be used for AO baking, but this is labor intensive as one project might require several unique meshes for each texture set. Anything to automate this process would be of great help.
It would be great if there is an option to make both an averaged and a non-averaged bake. This is to get rid of skewing, which is an ongoing saga. Keep in mind that I can't add support geometry to my models because they are all CAD models with explicit normals. Modifying the mesh in any way will mess up those normals. Re-creating the normals using smoothing groups is no fun and in some cases nearly impossible.
I realized that a skewmesh isn't going to help either because the normal map is not the only map suffering from skewing. This applies to all maps, most notably the ID map and AO map.
When the high poly has a chamfered edge and the low poly has a hard edge at the same location, an averaged bake gives you black lines on those edges. No skewing occurs though. A non-averaged bake gives you nice edges, but any details on top will be skewed. One way to solve this (apart from a skew mesh) is to blend the two normal maps in such a way that you get best of both wolds. This can be automated in Substance Designer, and there is a great tutorial here: https://www.youtube.com/watch?v=sGC2X6Qazvs
But unfortunately Knald can't bake a non-averaged normal map so the blending technique described in the video won't work. Any change adding this feature? Of course if you can make that super secret anti skewing projection method work, I'll be happy to wait for that though.
Is there a beta out with SubMesh support? I really need this, I don't see a way around it with the models I have created. I have several(6) 4k models that have their own UV space that intersect.
EDIT: Sorry for adding yet another SubMesh comment. v_v
Hi! Unfortunately we dont currently have a beta release ready for public release. However we are continuously working on Knald as as soon as we have something ready for public consumption we will post news of it here
It would be really handy if you can tag sub-meshes which are to be excluded of contributing to an AO bake on a per-texture set basis. Dynamic objects (which can move/rotate) should generally not affect other geometry AO wise, but depending on the shape, may in some cases receive AO from neighboring geometry. This is not easily solvable with name matching like with normal bakes. It requires some sort of object tag system.
Of course you can make separate high res meshes only to be used for AO baking, but this is labor intensive as one project might require several unique meshes for each texture set. Anything to automate this process would be of great help.
It would be great if there is an option to make both an averaged and a non-averaged bake. This is to get rid of skewing, which is an ongoing saga. Keep in mind that I can't add support geometry to my models because they are all CAD models with explicit normals. Modifying the mesh in any way will mess up those normals. Re-creating the normals using smoothing groups is no fun and in some cases nearly impossible.
I realized that a skewmesh isn't going to help either because the normal map is not the only map suffering from skewing. This applies to all maps, most notably the ID map and AO map.
When the high poly has a chamfered edge and the low poly has a hard edge at the same location, an averaged bake gives you black lines on those edges. No skewing occurs though. A non-averaged bake gives you nice edges, but any details on top will be skewed. One way to solve this (apart from a skew mesh) is to blend the two normal maps in such a way that you get best of both wolds. This can be automated in Substance Designer, and there is a great tutorial here: https://www.youtube.com/watch?v=sGC2X6Qazvs
But unfortunately Knald can't bake a non-averaged normal map so the blending technique described in the video won't work. Any change adding this feature? Of course if you can make that super secret anti skewing projection method work, I'll be happy to wait for that though.
I've added the AO request to the user wish list, though regarding the anti-skew blending in the video it is a little more complicated. Blending normal maps is generally more complicated than showing in the video as they contain encoded data (in the form of colour values) that represents vector information (It's best to think of a normal map as mathematical data encoded into a texture rather than like something like albedo or AO for example). By replacing this data with information from another normal map using a simple lerp your are altering the vector information to something that no longer matches the underlying low poly mesh, which can cause issues and rendering errors. Also if we did this it would double the amount of memory Knald requires when baking as we would need to bake each map twice.
Generally I think it would be preferable to use a method to fix skewing that is mathematically correct and maintains our current overall high level of efficiency
As always though, thanks for the suggestions. It's always nice to hear them
We made a short video tutorial on baking for everyone to check out
In this short video we show how to bake an asset
quickly & efficiently with the outstanding quality that Knald has
become known for. All in a fraction of the time of other baking
software.
We generate eleven 4k*2k bakes with 16xAA (Supersampling) from booting Knald to final export in 160 seconds.
Textures baked: -Ambient Occlusion -Concavity -Convexity -Curvature -Derivative -Height -Material ID -Object Space Normals -Tangent Space Normals -Transmission -Vertex Colors
Knald is awesome! Super high quality tool! From what I have tried so far it isn't possible to bake source albedo textures from high to lowpoly (when dealing with photogrammetry meshes, this is a must). Are there any plans to implement this functionality? Knald is incredibly fast and high quality for every other map type, baking albedo from high to low is the only thing keeping xNormal installed for me! (If I was being stupid and it is in fact possible, my apologies)
Knald is awesome! Super high quality tool! From what I have tried so far it isn't possible to bake source albedo textures from high to lowpoly (when dealing with photogrammetry meshes, this is a must). Are there any plans to implement this functionality? Knald is incredibly fast and high quality for every other map type, baking albedo from high to low is the only thing keeping xNormal installed for me! (If I was being stupid and it is in fact possible, my apologies)
Have exactly same problem. Moreover the photogrammetry is capable to produce super hi -res meshes and looks like Knald is able to cope with only about 90 mil at max. While I recently did baked from in total 400 mil polys hi-res in Xnormal. Took forever to bake and I hate Xnormal for that.
Edit 2: Er. Ah. Ray distribution. Unadjusted. It's not a checkbox but... problem solved! Ignore this post.
So I have a cage I've generated using the projection modifier in 3ds Max. I have some pretty steep edges that I've chosen to break, so there is an open edge in the cage. Knald seems to ignore this mesh or weld the vertices which are open in 3ds Max. (see edit)
Needless to say this is a little disappointing since I'm using a combination of maps baked in a bunch of different software and I suspect there will be distortion between the Knald bakes and others since it isn't using the same cage, not to mention ray missing that comes from the incorrect cage.
Is this a user error or is it not supported (yet, surely)?
Edit: So I reimported with a more ridiculous push on the open edge and it seems as if the open edge is actually retained but the cage itself is being manhandled into the wrong position. It seems like Knald is trying to correct the cage; pushing the vertices on the open edge to where they'd be if there was no open edge. Is there any way to prevent Knald from changing the cage at all? The cage results in perfect bakes in 3ds Max, and I want the same results in Knald of course. Perhaps there could be a hotfix with a small checkbox which disables the offending behaviour?
Sorry for the late replies everyone. My thread notifications are up the shoot again it seems. We can always be contacted via support [at] knaldtech.com if people need urgent help and your question hasn't been answered on here.
Knald is awesome! Super high quality tool! From what I have tried so far it isn't possible to bake source albedo textures from high to lowpoly (when dealing with photogrammetry meshes, this is a must). Are there any plans to implement this functionality? Knald is incredibly fast and high quality for every other map type, baking albedo from high to low is the only thing keeping xNormal installed for me! (If I was being stupid and it is in fact possible, my apologies)
Thanks for the kind words! Currently we support the baking of vertex colours from the HP only, but having it from a texture is on our list
Have exactly same problem. Moreover the photogrammetry is capable to produce super hi -res meshes and looks like Knald is able to cope with only about 90 mil at max. While I recently did baked from in total 400 mil polys hi-res in Xnormal. Took forever to bake and I hate Xnormal for that.
We are planning on increasing the max polycount of imported meshes. For now I can only suggest decimation, but hopefully you wont have to wait too long for the ability to load more tris into Knald
Edit 2: Er. Ah. Ray distribution. Unadjusted. It's not a checkbox but... problem solved! Ignore this post.
So I have a cage I've generated using the projection modifier in 3ds Max. I have some pretty steep edges that I've chosen to break, so there is an open edge in the cage. Knald seems to ignore this mesh or weld the vertices which are open in 3ds Max. (see edit)
Needless to say this is a little disappointing since I'm using a combination of maps baked in a bunch of different software and I suspect there will be distortion between the Knald bakes and others since it isn't using the same cage, not to mention ray missing that comes from the incorrect cage.
Is this a user error or is it not supported (yet, surely)?
Edit: So I reimported with a more ridiculous push on the open edge and it seems as if the open edge is actually retained but the cage itself is being manhandled into the wrong position. It seems like Knald is trying to correct the cage; pushing the vertices on the open edge to where they'd be if there was no open edge. Is there any way to prevent Knald from changing the cage at all? The cage results in perfect bakes in 3ds Max, and I want the same results in Knald of course. Perhaps there could be a hotfix with a small checkbox which disables the offending behaviour?
@metalliandy, I think it was the wiki, but the first time I skimmed through I didn't associate the phrase "ray distribution" with what was happening with my cage mesh. Of course, one follows from the other but I think I was looking for "cage settings" or something like that. I think some of my confusion arose from the fact that the cage didn't update when I chose unadjusted, so I probably assumed it wasn't relevant until I reread the wiki.
Also, could I ask that the little box which shows the progress bar isn't always on top? As fast as Knald is (and boy is it fast, well done sir), there is always something else to do while you wait!
Great to hear! If the option to bake from a masked mesh (mesh + opacity mask input) also ever becomes included I'll be extremely happy! I honestly haven't got cleaner bakes anywhere else, but unfortunately do a lot of billboard foliage baking, and baking from an already masked mesh is essential there!
When I export single channel curvature maps the midpoint grey value is 50% as a Grayscale document but converts to 149 as an RGB document. Is there a particular reason Knald exports as a Grayscale file? Could we get an option to export as RGB with the right neutral color? Or maybe I am missing something here?
@metalliandy, I think it was the wiki, but the first time I skimmed through I didn't associate the phrase "ray distribution" with what was happening with my cage mesh. Of course, one follows from the other but I think I was looking for "cage settings" or something like that. I think some of my confusion arose from the fact that the cage didn't update when I chose unadjusted, so I probably assumed it wasn't relevant until I reread the wiki.
Also, could I ask that the little box which shows the progress bar isn't always on top? As fast as Knald is (and boy is it fast, well done sir), there is always something else to do while you wait!
Ok, cool. Thanks for the info I will see if we can do something about the progress bar popup. I'm not sure if it will be possible though, but I will try.
Great to hear! If the option to bake from a masked mesh (mesh + opacity mask input) also ever becomes included I'll be extremely happy! I honestly haven't got cleaner bakes anywhere else, but unfortunately do a lot of billboard foliage baking, and baking from an already masked mesh is essential there!
Noted! Thanks for the kind words We are very proud of the work we have done with our baker and it's awesome when people feel strongly enough about it that they post nice comments
When I export single channel curvature maps the midpoint grey value is 50% as a Grayscale document but converts to 149 as an RGB document. Is there a particular reason Knald exports as a Grayscale file? Could we get an option to export as RGB with the right neutral color? Or maybe I am missing something here?
Can you post an example of what you mean (pictures or the textures would be great) please? What are you converting the curvature in? We export as a single channel texture because the file contains single channel data only and RGB files are much larger on disk without storing any additional information. Would perhaps have an option for this in the future though.
Here is an example of my curvature maps, in Photoshop. Maybe They don't get color managed properly as greyscale?
Thanks for the reply!
So the problem only appears after you convert the image to RGB inside Photoshop? It sounds like a problem within Photoshop colour management rather than something that Knald would be in control of.
Can you post a screenshot of your Photoshop colour settings please? Edit Menu> colour settings
Thanks for your help, I found that in the Photoshop Color Settings changing this fixes it: Gray: Dot Gain 20% to Gray: Gray Gamma 2.2
I think the dot gain 20% is the default setting? This problem would be avoided if the image was RGB as it would go through the sRGB profile instead.
Glad you found the solution. Depending on your settings I was going to suggest changing the grey profile to Gamma 2.2
Yes, the problem could be circumvented by expanding single channel textures to RGB but as I mentioned before the problem with this is that it would force an unnecessary file increase to all single channel files we export for no additional information or quality boost. A single channel TGA saved in Photoshop is 4mb vs an RGB TGA is 12mb (16mb with alpha).
That said, we do sympathise with your situation and we may be able to add an option to expect single channel textures to RGB at some point in the future.
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 ?
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 ?
Hi! We didn't add the cube initially because the resolution would be incredibly high. Knald tessellates primitives at a ratio of 2 triangles per pixel on the imported texture at level 7, so a cube would require 6* the resolution of the plane primitive (as the cube consists of 6 faces). The numbers soon become pretty mind blowing:
it's impossible to have an fbx file with more than 1 meshes contained in it? I'm exporting all 4 meshes into a single FBX file, but in Knald, I only see the top mesh. here is this export in maya's outliner: and in substance designer:
it's impossible to have an fbx file with more than 1 meshes contained in it? I'm exporting all 4 meshes into a single FBX file, but in Knald, I only see the top mesh. here is this export in maya's outliner: and in substance designer:
Hi!
Currently we don't support submeshes and only read the first mesh in the tree, but it is something we will be supporting in a future update for sure. The best way to get around this is to either merge all the meshes together on export (either in Maya or via FBX flags) or export them as individual meshes which you can load all at the same time in Knald.
The best way to get around this is to either merge all the meshes together on export (either in Maya or via FBX flags) or export them as individual meshes which you can load all at the same time in Knald.
Hope that helps!
Thanks @metalliandy .I've tried your suggestion, exporting as individual meshes, but in Knald, I can't seem to load multiple meshes for the low poly? only lets me do it for the high polys.
Is there any way of baking for a second uv channel? Or a specific uv channel? At the moment i am copy pasting channels around in max and then moving them back after which can be a pain.
Best baker for me! Big Big thanks entire knald team. I spend so less time and have stunning quality with everything that I bake with knald! Cant wait what you bring in the next update)
The best way to get around this is to either merge all the meshes together on export (either in Maya or via FBX flags) or export them as individual meshes which you can load all at the same time in Knald.
Hope that helps!
Thanks @metalliandy .I've tried your suggestion, exporting as individual meshes, but in Knald, I can't seem to load multiple meshes for the low poly? only lets me do it for the high polys.
Multiple low poly meshes is on the list for a future update.
Is there any way of baking for a second uv channel? Or a specific uv channel? At the moment i am copy pasting channels around in max and then moving them back after which can be a pain.
Not currently, but it's something we want to add in the future for sure.
Best baker for me! Big Big thanks entire knald team. I spend so less time and have stunning quality with everything that I bake with knald! Cant wait what you bring in the next update)
Thanks for the kind words! Always nice to see a happy face
Just got a license for myself, tried to access the documentation on the website and I am getting an Insecure connection warning using Firefox and Chrome.
Just got a license for myself, tried to access the documentation on the website and I am getting an Insecure connection warning using Firefox and Chrome.
Thanks for letting us know! I will have a look and see what the issue is.
Just got a license for myself, tried to access the documentation on the website and I am getting an Insecure connection warning using Firefox and Chrome.
Everything should be fixed now. Thanks for the heads up!
Hello. First of all thanks for amazing software) I don't know is it a right place to ask for some future features request but i'll put it here if you don't mind) First one is: could be great to have an opportunity to bake diffuse\albedo texture from importing a texture to lopoly\highpoly mesh (+ simple control for tiling). Second one: Could be nice to bake lightmaps inside Knald - i think it's simple but really usefull feature for many users. Thanks and sorry for my english language)
Hello. First of all thanks for amazing software) I don't know is it a right place to ask for some future features request but i'll put it here if you don't mind) First one is: could be great to have an opportunity to bake diffuse\albedo texture from importing a texture to lopoly\highpoly mesh (+ simple control for tiling). Second one: Could be nice to bake lightmaps inside Knald - i think it's simple but really usefull festure for many users. Thanks and sorry for my english language)
Hi EGGO, Thanks for the suggestions! I will add them to the user wish list
Knald is an amazing software, I've been enjoying it so far. Super fast with awesome baking results, easy to learn and intuitive. (: I Hope we can get the feature to load multiple low poly meshes soonish though.
Knald is an amazing software, I've been enjoying it so far. Super fast with awesome baking results, easy to learn and intuitive. (: I Hope we can get the feature to load multiple low poly meshes soonish though.
Thanks! Always nice to see a happy face The multiple low poly mesh is on our planned list of features for release over the coming months.
New build ahoy! After six months of working behind the scenes we are happy to release Knald 1.2!
This release is huge with massive upgrades to the mesh loading system (read below for details), including support for baking Bent Normals, support for the Stanford .PLY file format, additional options for occluder weighting for Ambient Occlusion, support for unnormalized height maps in the Baker, a new light theme and more!
Mesh Loading Improvements: Due to popular demand, and part of a forthcoming series of upgrades in this area over the coming months, we have increased the amount of triangles that Knald can handle up to a limit of 350m triangles (both in the baker and in the viewport) and have hugely optimised the speed in which Knald can load meshes; with the speed up being between 100-550% faster.
We have also added a novel way for the user to tailor mesh loading and bake times to better suit their own personal workflows and specific mesh densities. We call this Bake Balancing.
Bake Balancing: Balances execution time between High Poly processing (import) and baking time.
This enables the user to choose faster High Poly mesh loading at the expense of extended baking time, reduced baking time at the expense of extended High Poly mesh loading speed or strike a balance between the two extremes in various increments.
-3: Knald prioritizes an increased High Poly initialization speed over baking time.
0: Knald will try to strike a balance between High Poly initialization speed and baking time.
+3: Knald prioritizes a reduced baking time over High Poly initialization speed.
Note: High Poly import happens once only, even if subsequent bakes are performed using the same High Poly data. Knald will only reprocess the meshes if the source data is modified (either by loading a new high poly mesh or by editing the existing meshes externally).
Bent Normals Support:
A common frustration with image based lighting in realtime graphics is the misprediction of specular peaks due to lack of self-occlusion. During the course Advances in Real-Time Rendering in Games at Siggraph 2016 several speakers stated the importance of using bent normals combined with ambient occlusion to alleviate this problem in a practical way within the context of real-time graphics in order to achieve the next tier of realism. Bent normal maps are able to do this because uniform AO combined with the bent normal defines a visibility cone which can be used to perform specular masking in a shader, with the bent normal itself representing the central direction of the visibility cone and the uniform AO representing the percentage of the visible (unoccluded) hemisphere.
On a more artistic note bent normals can also serve as extremely useful
texture masks for more stylized workflows, such as those found within
the MOBA community. Of course, bent normal generation within Knald is blazingly fast too
Cosine, Uniform Clamped & Uniform Unclamped Bent Normals with associated magnitudes below.
New Occluder Weighting Choices for AO
We have added two additional choices (for a total of three) that change the way in which AO is generated. These new settings provide very distinct and separate results which can be useful for photogrammetry workflows in addition to texture masks in more stylized art.
Cosine: Each sample is weighted by it’s cosine to the normal.
Uniform Clamped: A uniform weighting of visible directions gives the percentage of visible surface area on the hemisphere.
Uniform Unclamped: Corresponds to projection of visibility onto the first spherical harmonic band L=0.
Added support for Tangent & Object Space Bent Normal Maps in the Baker with various options to control occluder weighting (Cosine, Uniform Clamped & Uniform Unclamped) and how the magnitude is stored via normalization.
Improved the mesh loader to support mesh files with a triangle count of 350 million.
Improved mesh loading speeds by up to 550%.
Improved the mesh loader to support user adjustable bake balancing, which balances execution time between High Poly processing (import) and baking time based upon a slider value.
Improved the mesh loader to support mesh files over 4GB in size.
Added support for .ply Polygon File Format/Stanford Triangle Format.
Added support for unnormalized height maps in the Baker.
Added support for various options to control occluder weighting for baked Ambient Occlusion (Cosine, Uniform Clamped & Uniform Unclamped).
Added support for various options to control occluder weighting for Mesh Ambient Occlusion (Cosine, Uniform Clamped & Uniform Unclamped).
Added support for the reporting of various statistics for Height Maps in the Baker on (Min, Mid & Max for both normalized & unnormalized).
Add support for the display of high poly vertex & triangle counts in the status bar while the Baker is loaded.
Updated .kpbr with new presets (Brass #2, Rhodium, Tin, Tungsten + Concrete 1+2).
Added an the option to use a cube primitive in the 3d preview.
Added new Light theme for Knald via a dropdown option in the Preferences Tab.
Added support for palletized PNG files.
Added support for collapsible groups in the 3d preview.
Updated the Dark theme so that ghosted/disabled GUI items are lighter for better legibility.
Miscellaneous improvements to the load/save system.
Miscellaneous tweaks to .kpbr to improve preview material aesthetics.
Updated tooltips.
Miscellaneous improvements and optimizations.
Bug fixes
Fixed an issue where .ksf files did not correctly restore bake settings when the Baker was not initialized.
Fixed an issue where the 3d preview or main window are off screen after startup on some occasions.
Fixed an issue where Knald failed to process loaded images or bake correctly on some occasions.
Fixed an issue where the Material ID default initial value was shown as black in the color picker.
Fixed an issue in the Baker where expected ray hits would occasionally fail along triangle edges in some situations.
Fixed an issue where under some circumstances the Material ID color schemes were not initialized correctly resulting in a black color picker.
Fixed an issue where Flip Green was saved in an incorrect state in some situations.
Fixed an issue where the Image AO scale slider incorrectly forced the regeneration of Mesh AO when moved.
Fixed an issue where OS Normals, Vertex Colors & Material ID were not checked by default in export settings even though they were baked.
Fixed an issue where baker size ratios were not maintained correctly for non-square sizes.
Fixed an issue where some palletized/indexed PNG files were not supported correctly.
Fixed an issue where some PNG with an alpha channel were not supported correctly.
Fixed an issue where greyscale PNG files of less than 8bits per pixel were not supported correctly.
Fixed an issue where some custom suffixes were not saved correctly after restarting Knald.
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 & please do continue sending us suggestions & posting everything you can!
Nice to see the improvements but sad to see that there is still no support for sub meshes and ID map from material color.
Thanks for the feedback! The changes we have made in the 1.2 release are, in part, building toward multiple improvements in regards to how meshes are loaded/processed within Knald over the coming months. As it's quite involved to make all the improvements we are planning, we thought that people would prefer to have the current changes when they were ready rather than wait another couple of months and have everything all at once
hello, I have an issue when using Knald 1.20, the baked maps are seem fine, but the 3D view got bug like this, I'm using Nvidia Driver 375.70 (work perfectly with knald 1.1), i've tried another meshes, triangle or quads still got problem like this, my models are all exported from 3Ds max (obj files).
hello, I have an issue when using Knald 1.20, the baked maps are seem fine, but the 3D view got bug like this, I'm using Nvidia Driver 375.70 (work perfectly with knald 1.1), i've tried another meshes, triangle or quads still got problem like this, my models are all exported from 3Ds max (obj files).
Hi!
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
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!
Replies
Anyone come across this before? Any solutions?At first glance I would say that this is due to artifacts due to decimation. Often after decimation, faces can become distorted and overlap themselves and this is a limitation of the decimation process rather than something Knald is specifically doing. As we bake real/accurate curvature/concavity from the high poly source, Knald will pick up any errors in the mesh such as this. Having said that you can fix these errors in your 3D application by selecting the affected verts and performing a small relax on them or perhaps a small relax on the whole mesh. When I get back to my main workstation I will post an example image.
Hope that helps!
Was just surprised xN didn't have that issue, but I guess the curvature and concavity algos aren't exactly the same.
Thanks for the help!
is there something specific you are looking for?
EDIT: Sorry for adding yet another SubMesh comment. v_v
It would be really handy if you can tag sub-meshes which are to be excluded of contributing to an AO bake on a per-texture set basis. Dynamic objects (which can move/rotate) should generally not affect other geometry AO wise, but depending on the shape, may in some cases receive AO from neighboring geometry. This is not easily solvable with name matching like with normal bakes. It requires some sort of object tag system.
Of course you can make separate high res meshes only to be used for AO baking, but this is labor intensive as one project might require several unique meshes for each texture set. Anything to automate this process would be of great help.
I realized that a skewmesh isn't going to help either because the normal map is not the only map suffering from skewing. This applies to all maps, most notably the ID map and AO map.
When the high poly has a chamfered edge and the low poly has a hard edge at the same location, an averaged bake gives you black lines on those edges. No skewing occurs though. A non-averaged bake gives you nice edges, but any details on top will be skewed. One way to solve this (apart from a skew mesh) is to blend the two normal maps in such a way that you get best of both wolds. This can be automated in Substance Designer, and there is a great tutorial here:
But unfortunately Knald can't bake a non-averaged normal map so the blending technique described in the video won't work. Any change adding this feature? Of course if you can make that super secret anti skewing projection method work, I'll be happy to wait for that though.
Unfortunately we dont currently have a beta release ready for public release. However we are continuously working on Knald as as soon as we have something ready for public consumption we will post news of it here
I've added the AO request to the user wish list, though regarding the anti-skew blending in the video it is a little more complicated.
Blending normal maps is generally more complicated than showing in the video as they contain encoded data (in the form of colour values) that represents vector information (It's best to think of a normal map as mathematical data encoded into a texture rather than like something like albedo or AO for example). By replacing this data with information from another normal map using a simple lerp your are altering the vector information to something that no longer matches the underlying low poly mesh, which can cause issues and rendering errors.
Also if we did this it would double the amount of memory Knald requires when baking as we would need to bake each map twice.
Generally I think it would be preferable to use a method to fix skewing that is mathematically correct and maintains our current overall high level of efficiency
As always though, thanks for the suggestions. It's always nice to hear them
Hey everyone!
We made a short video tutorial on baking for everyone to check out
In this short video we show how to bake an asset quickly & efficiently with the outstanding quality that Knald has become known for. All in a fraction of the time of other baking software.
We generate eleven 4k*2k bakes with 16xAA (Supersampling) from booting Knald to final export in 160 seconds.
Textures baked:
-Ambient Occlusion
-Concavity
-Convexity
-Curvature
-Derivative
-Height
-Material ID
-Object Space Normals
-Tangent Space Normals
-Transmission
-Vertex Colors
Enjoy!
So I have a cage I've generated using the projection modifier in 3ds Max. I have some pretty steep edges that I've chosen to break, so there is an open edge in the cage. Knald seems to ignore this mesh or weld the vertices which are open in 3ds Max. (see edit)
Needless to say this is a little disappointing since I'm using a combination of maps baked in a bunch of different software and I suspect there will be distortion between the Knald bakes and others since it isn't using the same cage, not to mention ray missing that comes from the incorrect cage.
Is this a user error or is it not supported (yet, surely)?
Edit: So I reimported with a more ridiculous push on the open edge and it seems as if the open edge is actually retained but the cage itself is being manhandled into the wrong position. It seems like Knald is trying to correct the cage; pushing the vertices on the open edge to where they'd be if there was no open edge. Is there any way to prevent Knald from changing the cage at all? The cage results in perfect bakes in 3ds Max, and I want the same results in Knald of course.
Perhaps there could be a hotfix with a small checkbox which disables the offending behaviour?
Thanks for the kind words! Currently we support the baking of vertex colours from the HP only, but having it from a texture is on our list
We are planning on increasing the max polycount of imported meshes. For now I can only suggest decimation, but hopefully you wont have to wait too long for the ability to load more tris into Knald
Knald doesnt support name matching yet, but it's on our list for a future update for sure
Glad you found the solution
May I ask how you found the solution? The documentation and tooltips can often explain much of this kind of thing so it's always a good idea to check those if you are having trouble too.
https://docs.knaldtech.com/doku.php?id=the_baker_knald_1.1#ray_projection_settings
Also, could I ask that the little box which shows the progress bar isn't always on top? As fast as Knald is (and boy is it fast, well done sir), there is always something else to do while you wait!
I will see if we can do something about the progress bar popup. I'm not sure if it will be possible though, but I will try.
Noted!
Thanks for the kind words
Thanks!
Can you post an example of what you mean (pictures or the textures would be great) please? What are you converting the curvature in?
We export as a single channel texture because the file contains single channel data only and RGB files are much larger on disk without storing any additional information.
Would perhaps have an option for this in the future though.
Awesome, thanks for the kind words!
Glad you are so happy with Knald
So the problem only appears after you convert the image to RGB inside Photoshop? It sounds like a problem within Photoshop colour management rather than something that Knald would be in control of.
Can you post a screenshot of your Photoshop colour settings please? Edit Menu> colour settings
Cheers!
Gray: Dot Gain 20%
to
Gray: Gray Gamma 2.2
I think the dot gain 20% is the default setting? This problem would be avoided if the image was RGB as it would go through the sRGB profile instead.
Yes, the problem could be circumvented by expanding single channel textures to RGB but as I mentioned before the problem with this is that it would force an unnecessary file increase to all single channel files we export for no additional information or quality boost. A single channel TGA saved in Photoshop is 4mb vs an RGB TGA is 12mb (16mb with alpha).
That said, we do sympathise with your situation and we may be able to add an option to expect single channel textures to RGB at some point in the future.
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 didn't add the cube initially because the resolution would be incredibly high. Knald tessellates primitives at a ratio of 2 triangles per pixel on the imported texture at level 7, so a cube would require 6* the resolution of the plane primitive (as the cube consists of 6 faces). The numbers soon become pretty mind blowing:
We will look into adding in the future however.
I'm exporting all 4 meshes into a single FBX file, but in Knald, I only see the top mesh.
here is this export in maya's outliner:
and in substance designer:
Currently we don't support submeshes and only read the first mesh in the tree, but it is something we will be supporting in a future update for sure.
The best way to get around this is to either merge all the meshes together on export (either in Maya or via FBX flags) or export them as individual meshes which you can load all at the same time in Knald.
Hope that helps!
Or a specific uv channel?
At the moment i am copy pasting channels around in max and then moving them back after which can be a pain.
Not currently, but it's something we want to add in the future for sure.
Thanks for the kind words! Always nice to see a happy face
Just got a license for myself, tried to access the documentation on the website and I am getting an Insecure connection warning using Firefox and Chrome.
I will have a look and see what the issue is.
Cheers!
First one is: could be great to have an opportunity to bake diffuse\albedo texture from importing a texture to lopoly\highpoly mesh (+ simple control for tiling).
Second one: Could be nice to bake lightmaps inside Knald - i think it's simple but really usefull feature for many users.
Thanks and sorry for my english language)
Thanks for the suggestions! I will add them to the user wish list
Your English is fine too!
I Hope we can get the feature to load multiple low poly meshes soonish though.
The multiple low poly mesh is on our planned list of features for release over the coming months.
New build ahoy! After six months of working behind the scenes we are happy to release Knald 1.2!
This release is huge with massive upgrades to the mesh loading system (read below for details), including support for baking Bent Normals, support for the Stanford .PLY file format, additional options for occluder weighting for Ambient Occlusion, support for unnormalized height maps in the Baker, a new light theme and more!
Mesh Loading Improvements:
Due to popular demand, and part of a forthcoming series of upgrades in this area over the coming months, we have increased the amount of triangles that Knald can handle up to a limit of 350m triangles (both in the baker and in the viewport) and have hugely optimised the speed in which Knald can load meshes; with the speed up being between 100-550% faster.
We have also added a novel way for the user to tailor mesh loading and bake times to better suit their own personal workflows and specific mesh densities. We call this Bake Balancing.
Bake Balancing:
Balances execution time between High Poly processing (import) and baking time.
This enables the user to choose faster High Poly mesh loading at the expense of extended baking time, reduced baking time at the expense of extended High Poly mesh loading speed or strike a balance between the two extremes in various increments.
Note: High Poly import happens once only, even if subsequent bakes are performed using the same High Poly data. Knald will only reprocess the meshes if the source data is modified (either by loading a new high poly mesh or by editing the existing meshes externally).
Bent Normals Support:
A common frustration with image based lighting in realtime graphics is the misprediction of specular peaks due to lack of self-occlusion.
During the course Advances in Real-Time Rendering in Games at Siggraph 2016 several speakers stated the importance of using bent normals combined with ambient occlusion to alleviate this problem in a practical way within the context of real-time graphics in order to achieve the next tier of realism.
Bent normal maps are able to do this because uniform AO combined with the bent normal defines a visibility cone which can be used to perform specular masking in a shader, with the bent normal itself representing the central direction of the visibility cone and the uniform AO representing the percentage of the visible (unoccluded) hemisphere.
On a more artistic note bent normals can also serve as extremely useful texture masks for more stylized workflows, such as those found within the MOBA community.
Of course, bent normal generation within Knald is blazingly fast too
Cosine, Uniform Clamped & Uniform Unclamped Bent Normals with associated magnitudes below.
New Occluder Weighting Choices for AO
We have added two additional choices (for a total of three) that change the way in which AO is generated. These new settings provide very distinct and separate results which can be useful for photogrammetry workflows in addition to texture masks in more stylized art.
Cosine, Uniform Clamped & Uniform Unclamped Ambient Occlusion
What’s changed since Knald 1.1.2?
Build Number: 20161113001 – November 16th, 2016.New Features, Improvements and Optimizations
Bug fixes
You can grab the new build from your account & can find build notes here: https://www.knaldtech.com/knald-update-build20161113001/
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 & please do continue sending us suggestions & posting everything you can!
PS, restart your pc if the installer hangs at the end, don't freak out like I did
The changes we have made in the 1.2 release are, in part, building toward multiple improvements in regards to how meshes are loaded/processed within Knald over the coming months. As it's quite involved to make all the improvements we are planning, we thought that people would prefer to have the current changes when they were ready rather than wait another couple of months and have everything all at once
Thanks!
I'm using Nvidia Driver 375.70 (work perfectly with knald 1.1),
i've tried another meshes, triangle or quads still got problem like this,
my models are all exported from 3Ds max (obj files).
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!
Looking forward to test this out!
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!