Texture and normal map baker
- Thread starter Myagi
- Start date
lardbros
Not so newbie member
Time to dust off this thread a bit
New version is available with a minor addition. For LW10 or later there are some new options for which color spaces to save baked images in.
Awesome... I love this plugin... and will try your latest version, been getting crashes with an object, and need to see if it's the ambient occlusion node that's causing it...
I wish Newtek would do something neater (like your plugin) as a native solution!!
But while we still wait... yours is a perfect solution!! Having fun with this at home for some CryEngine tests!
lardbros
Not so newbie member
Hi there Myagi!
The model was from here:
http://files.designburo.nl/lw//modules/TDMDownloads/singlefile.php?lid=244
And it's probably user error... I know what I'm meant to be doing but was trying something different with this model.
I was going to try and bake the diffuse map onto itself, rather than just use a low-poly object. It seems to crash every time using 11.0.3
Thanks for taking a look.
I tried numerous things to get it working, deleting all AO nodes. Turning off all nodal textures...
I'll be very interested to see what the issue actually turns out to be.
Thanks!
The model was from here:
http://files.designburo.nl/lw//modules/TDMDownloads/singlefile.php?lid=244
And it's probably user error... I know what I'm meant to be doing but was trying something different with this model.
I was going to try and bake the diffuse map onto itself, rather than just use a low-poly object. It seems to crash every time using 11.0.3
Thanks for taking a look.
I tried numerous things to get it working, deleting all AO nodes. Turning off all nodal textures...
I'll be very interested to see what the issue actually turns out to be.
Thanks!
Myagi
New member
Even when something is a user error it should ideally not lead to a crash, with the exceptions of nodes/shaders which the baker doesn't have any control over. Baking onto self should work, it was a feature added some version(s) ago.
In this case it's a double whammy.
1) A bug for a circumstance I missed. When baking onto self and the mesh contains non-UV mapped polys mixed with mapped polys. If you hide the non-UV polys the current version will be able to deal with it, until I fixed it and put up a new version.
2) The Amb Occlusion node will also crash, if multithreading is enabled in the baker (i.e. set to something other than 1 Thread). At least it does with the DP Kit version I still have, which admittedly is quite old, so maybe that issue has been fixed.
Note that unfortunately even if the Amb Occlusion doesn't crash, you won't actually get any AO applied from it, because that node relies on Layout functionality to produce results. If you want AO you could let the baker generate an "Occlusion/Dirt Map" instead.
In this case it's a double whammy.
1) A bug for a circumstance I missed. When baking onto self and the mesh contains non-UV mapped polys mixed with mapped polys. If you hide the non-UV polys the current version will be able to deal with it, until I fixed it and put up a new version.
2) The Amb Occlusion node will also crash, if multithreading is enabled in the baker (i.e. set to something other than 1 Thread). At least it does with the DP Kit version I still have, which admittedly is quite old, so maybe that issue has been fixed.
Note that unfortunately even if the Amb Occlusion doesn't crash, you won't actually get any AO applied from it, because that node relies on Layout functionality to produce results. If you want AO you could let the baker generate an "Occlusion/Dirt Map" instead.
lardbros
Not so newbie member
Ahhh.... I see! Cool... I never thought it might have been polys that weren't mapped I removed all amb occ nodes anyway as I wasn't interested in baking them. I presumed they wouldn't work too.
Well, thanks for the work around, and I'm glad I could help in some little way to improve your plugin! Thanks myagi!
I removed all amb occ nodes anyway as I wasn't interested in baking them. I presumed they wouldn't work too. Well, thanks for the work around, and I'm glad I could help in some little way to improve your plugin! Thanks myagi!
Just my specs, even if this node is not usable here,
I can't see any multithreading problem in this node,
it involves of course LW Raytracing functions,
but they are tested before any evaluation,
they should be explicitly set to NULL
if they are not available in the baker context.
In DPKit11, this node includes nodal unified
sampling functions, so only compatible with LW11 SDK.
Denis.
Myagi
New member
Edit: I'm an idiot! Forget everything I said. I should RTFM myself When you're using an Image node (among others) that uses a UV Map then you have to use the PB_Node counterpart instead to make it fully baker compatible.
That's odd. It does consistenly crashes when have more than 1 thread, but works fine with 1 thread or if I disable the nodes. I'll have to test some more.
I should clarify that I didn't mean that the node in general would have a problem with multithreading, it obviously works fine in Layout when rendering MT. I was thinking more that it maybe was some issue running in Modeler, because it doesn't expect any MT there.
When you're using an Image node (among others) that uses a UV Map then you have to use the PB_Node counterpart instead to make it fully baker compatible.That's odd. It does consistenly crashes when have more than 1 thread, but works fine with 1 thread or if I disable the nodes. I'll have to test some more.
I should clarify that I didn't mean that the node in general would have a problem with multithreading, it obviously works fine in Layout when rendering MT. I was thinking more that it maybe was some issue running in Modeler, because it doesn't expect any MT there.
Last edited:
When I said 'compatible' I meaned for separate evaluations
no shared global data or similar unsafe things.
Denis.
lardbros
Not so newbie member
Edit: I'm an idiot! Forget everything I said. I should RTFM myself
That's odd. It does consistenly crashes when have more than 1 thread, but works fine with 1 thread or if I disable the nodes. I'll have to test some more.
I should clarify that I didn't mean that the node in general would have a problem with multithreading, it obviously works fine in Layout when rendering MT. I was thinking more that it maybe was some issue running in Modeler, because it doesn't expect any MT there.
Sorry Myagi, I'm unsure who this post it for? Is it for me to fix the crashing or for Dpont?
Myagi
New member
It's for you (/users). When you have nodes that access a UV map, like for example Image and NormalMap set to "Mapping: UV Map", then you have to use the PB_Image, PB_NormalMap etc. nodes instead. The built-in nodes don't properly support UV evaluation in Modeler which leads to a crash, at least prior to LW11.
(The other issue with non-UV mapped polys still stands, I'll put up a new version with that fix soon.)
(The other issue with non-UV mapped polys still stands, I'll put up a new version with that fix soon.)
Last edited:
lardbros
Not so newbie member
Cool.... thanks for such a quick fix!!!
Myagi
New member
I briefly looked at the dDo web page and a youtube video to try to get an idea of what it is. Do I understand it right that what you're looking for is that initial map where different details on an object have different colors so dDo can automatically detect them? Let's for example say the object is a car key with a plastic handle, so the metal part of the key would get one color and the plastic handle another?
I'm not sure how the baker would automatically identify different parts of the mesh. I think it would need the user to assign materials (preferably) to the different parts so that the baker knows what belongs together and what doesn't. In the key example above one would assign one material to the metal polys and one to the plastic polys. If that's done, and you just want to avoid having to set the Color for each material (so you could just leave them all the default grey), then I suppose it might be possible to add some random material color function to the baker.
Could you elaborate a bit more of what kind of functionality you had in mind?
I'm not sure how the baker would automatically identify different parts of the mesh. I think it would need the user to assign materials (preferably) to the different parts so that the baker knows what belongs together and what doesn't. In the key example above one would assign one material to the metal polys and one to the plastic polys. If that's done, and you just want to avoid having to set the Color for each material (so you could just leave them all the default grey), then I suppose it might be possible to add some random material color function to the baker.
Could you elaborate a bit more of what kind of functionality you had in mind?
geo_n
New member
Yes your car key example is correct. dDo would then be able to identify the parts of the car key via colors to use as masks to apply textures in dDo.
So if pbtexture was able to assign random colors via surface id and fill the whole uvisland completely with these colors and export this colormap out would be the best and fastest.
I've tried surface baker and surface id in layout and so far its not fast as a workflow and the colormaps aren't anti aliased.
So if pbtexture was able to assign random colors via surface id and fill the whole uvisland completely with these colors and export this colormap out would be the best and fastest.
I've tried surface baker and surface id in layout and so far its not fast as a workflow and the colormaps aren't anti aliased.
geo_n
New member
As a first step yes. I tried Random Surfacer v0.9 but its extremely buggy.
http://cohen-plugs.tripod.com/outdated.htm#nlm
Second step would be exporting the color map without tolerance so all polys are completely filled which somehow baking can have errors and the resulting colormap needs to be fixed in photoshop a bit. So I don't know if pbtexture can simply export out the colormap from the mesh.
What I do now is fill the mesh with random colors in 3dcoat which is quite time consuming but you get perfect filled colormaps.
http://cohen-plugs.tripod.com/outdated.htm#nlm
Second step would be exporting the color map without tolerance so all polys are completely filled which somehow baking can have errors and the resulting colormap needs to be fixed in photoshop a bit. So I don't know if pbtexture can simply export out the colormap from the mesh.
What I do now is fill the mesh with random colors in 3dcoat which is quite time consuming but you get perfect filled colormaps.
Myagi
New member
I think the baker should do pretty ok. There are two scenarios.
If you're baking a hipoly object to lowpoly. If the trace distances are tweaked for the object, then there shouldn't be any unfilled holes in poly interiors. But if there is, if you set Border Pixels high enough it should fill up potential holes (but first holes should be attempted to be fixed by increasing trace distances).
The second scenario is if you only have one mesh that you simply want to bake out material color from, then you can use the baker's bake onto self functionality (where you have no BG layer selected). In that case it will more or less render out the polys directly and there should never be any missed areas.
I'll have a look if I can't just throw together a simple script that randmoize material color for all materials used in the selected layer.
If you're baking a hipoly object to lowpoly. If the trace distances are tweaked for the object, then there shouldn't be any unfilled holes in poly interiors. But if there is, if you set Border Pixels high enough it should fill up potential holes (but first holes should be attempted to be fixed by increasing trace distances).
The second scenario is if you only have one mesh that you simply want to bake out material color from, then you can use the baker's bake onto self functionality (where you have no BG layer selected). In that case it will more or less render out the polys directly and there should never be any missed areas.
I'll have a look if I can't just throw together a simple script that randmoize material color for all materials used in the selected layer.