One small suggestion, would it be possible to add a "Shut down when finished" checkbox? I often left things baking over night and it'd be really helpful to have XNormal shutdown my PC when it's done.
1 .Baking models by only hitting matching Material Id's/naming conventions is my wish for xnormal in the same way 3DS Max does it.
This would eliminate the need for cages all together.
For example xnooraml "isolates" each model part and if it mat id and name matches the high poly that is in the same place it bakes that also taking into account shadows from surrounding objects.
2. Increase AA for bakes 8x or more, knald just recently did this for its software.This owuld be great for normal maps that bake fast anyways.
3. Another wish, xnormal automatically creates a bowl and or flat plane based upon user choice that takes into account the model scale upon the bowls creation. A box with flat walls and open top would also be nice.
4. Can xnormal be programmed to only load 1 lp 1 hp and cage at a time and bake that instead of loading all at once at the begggining ? I know the software has to go through the models and see if theu match and have any errors.
Thank you for making this software for all of us and alot people appreciate your efforts for all of us.
I`ve modeled a model in zbrush with some subtools .. i polygrouped every subtool and then unwrapped the whole model . then i used xnormal to bake the whole model at once , the results were bad ... so i tried baking normals for each subtool alone and the results were good ... the problem here is that now i have different png files for every subtool`s normal map and i need them to be merged for the weapon model.
I would also like to see the option to bake Tangent normal map and World Space map seperately without having xnormal reload the project files.Have it as a seperate map bake in the map list.
Hi, I have a problem with the ObjSpace converter. I have assets baked in Maya with a normal map that doesn't work with Unity. The solution is always rebake the highpoly in xNormal with Unity TangentBasis Calculator and Triangulator.
So if I want to use Handplane is because I want to save time.. so I need to convert the Maya tangent Normal maps to object space normal maps and use Handplane.
My question is: How can I get the ObjectSpace Normal map without the HighPoly mesh? Because if I have to rebake the Highpoly again... is not worth it to use Handplane.. I just use xNormal to bake the proper tangent space normal map. I was thinking if I can do it in Maya but I cannot find a way of doing it. Maybe I can load the Maya TB Calculator and the Maya Triangulator in Xnormal but.. where can I find them?
HI guys, thought I'd just ask here rather than starting a new thread, just trying to get this baked with a synced MikkTspace with UE4/toolbag 2 and am getting faceting on my model. All one smoothing group, exported without tangents/binormals baked with xnormal with the compute binormals ticked in tspace, then imported into UE4/toolbag with "input normals" ticked and mikktsapce ticked in toolbag.
Same issue in both programs, I've tried every combination of exports and fixes, help!
Did you trianglate the mesh before you baked and imported it? Do you have Marmoset Toolbag by chance? You could try to use it to see if it's an issue with the mesh+normal map or an issue with UE4.
Hey guys!
I've got the following question: Does the polypaint information (ZBrush) of the Highpoly get lost, as soon as I import it to 3ds max and then export it again? Because I've exported my sculpt from ZBrush even with preserve polypaint on, then imported it to 3ds max for building the LP and then exported it from 3ds max again for baking in Xnormal. And as soon as I want to bake highpoly's vertex colours (ignore per vertex colour in HP slot unchecked), I get a white canvas. I guess if I just use the HP exported from ZBrush for baking, it will work, I'm just curious if the white canvas has something to do with exporting the HP from 3dsmax.
I have a question ... im baking lots of meshes(subtools) of one model .. and for baking normal maps i have to bake each subtools separately from the others to get best results .. the problem is that i have to watch xnormal bake each subtool one by one in order to check and uncheck the subtools to be baked and rename the output map manually is there any plugin or any way to do that automatically ? i just wanna leave the pc over night to bake because im baking 63 subtools at 4k.
Tripl3M: try searching the forums for batch and xnormal. I'm sure that I have seen a similar question before, although I am not sure if there was a satisfactory solution. You might find something that helps you.
Hey guys!
I've got the following question: Does the polypaint information (ZBrush) of the Highpoly get lost, as soon as I import it to 3ds max and then export it again? Because I've exported my sculpt from ZBrush even with preserve polypaint on, then imported it to 3ds max for building the LP and then exported it from 3ds max again for baking in Xnormal. And as soon as I want to bake highpoly's vertex colours (ignore per vertex colour in HP slot unchecked), I get a white canvas. I guess if I just use the HP exported from ZBrush for baking, it will work, I'm just curious if the white canvas has something to do with exporting the HP from 3dsmax.
Thanks
Yes it is to do with passing the file through max. The obj format isn't really supposed to support vertex colors, but zbrush added their own way to hold it in the file and xnormal eventually made a way to bake that info.
I have tried importing and exporting with Maya, but I suspect Maya ignores the vert color info since it is not official spec, and also exporting as an fbx from Maya with vert colors to test, xnormal doesn't read these either, so even if you were to get the vert colors into max, you probably wouldn't be able to get them back out.
So use the file straight from zbrush to bake, to retopo you could always use goz in case you needed to move the high poly around.
Yes it is to do with passing the file through max. The obj format isn't really supposed to support vertex colors, but zbrush added their own way to hold it in the file and xnormal eventually made a way to bake that info.
I have tried importing and exporting with Maya, but I suspect Maya ignores the vert color info since it is not official spec, and also exporting as an fbx from Maya with vert colors to test, xnormal doesn't read these either, so even if you were to get the vert colors into max, you probably wouldn't be able to get them back out.
So use the file straight from zbrush to bake, to retopo you could always use goz in case you needed to move the high poly around.
I don't know how you'd get vertex colours into Max, but I do know that Max will export vertex colour with the .fbx file format, at least with a vertex paint modifier applied. I've used this to bake ID masks out of Xnormal at work, seems to work pretty well.
I don't know how you'd get vertex colours into Max, but I do know that Max will export vertex colour with the .fbx file format, at least with a vertex paint modifier applied. I've used this to bake ID masks out of Xnormal at work, seems to work pretty well.
Well then I probably screwed something up exporting the fbx from maya with vertex colours.
Rant on
Xnormal needs a pause button on render and or a stop button that you can continue later even after closing the program. Sudden chaotic storms can wreck havock upon you after rendering a ao map for 20 hours and it;s almost finished and your power goes out for 2 hours.
Rant off
BTW thank you for making this program for all of is to use.
1. the ability to transfer multiple textures (diffuse/gloss/normal/etc. from high to lowpoly in one go. Very useful for LOD creation.
2. revamp the baking options screen: on the left you could set up the map you want to bake then with a + button add it to a list on the right. This would allow for maps to be baked in different resolutions, with different settings, renderers, etc. in one go. Overriding ray distance, the vertex colours checkbox, and the other mesh settings/map bake would also be useful. For example, usually I want tangent and object space normal maps and an ao map in lower resolution for a mesh: currently I have to start a bake 3 times to achieve this, I can't just press bake and leave the computer to create all the maps I need.
3. a standard Windows ui or a ribbon ui.
4. less memory consumption for very high poly objs.
A Tiger 1 Ausf E, the low poly is around 9 million triangulated polies broken into 5 texture maps 4k each.
Was baking the LP Hull to HP Zbrushed parts for the hull section at twice the res and then downsizing to get 4x aa.
This is not for any game, it's one of those go crazy with polies and push the limits of realism art peices.
I did an Elefant tank destroyer on Military-Meshs.com that the LP was 12 million and was a featured model of the month there.Includes full interior as well.
I just made a thread but I'll re-post this here in case Jogshy or anybody else knows a way around this and I'll post the answer in the thread:
The thing that drives me crazy about xNormal is that apparently every vertex index must be the same between the lowpoly and the cage; having the same number of vertices is not enough. Is this correct?
This means that if I have an exploded mesh, do some test bakes, decide to correct some UVs in another app and bring it back to Maya before exporting everything to xNormal, I'll get the "incorrect vertex index" problem. This actually only occurs to me when I re-do specific cages, since I guess this alters the vertex index.
I read throughsomethreads but no clear solution is given. How do you artists go about this? Do you have any easy auto-reassign-vertex-index solutions in Maya?
I just made a thread but I'll re-post this here in case Jogshy or anybody else knows a way around this and I'll post the answer in the thread:
The thing that drives me crazy about xNormal is that apparently every vertex index must be the same between the lowpoly and the cage; having the same number of vertices is not enough. Is this correct?
This means that if I have an exploded mesh, do some test bakes, decide to correct some UVs in another app and bring it back to Maya before exporting everything to xNormal, I'll get the "incorrect vertex index" problem. This actually only occurs to me when I re-do specific cages, since I guess this alters the vertex index.
I read throughsomethreads but no clear solution is given. How do you artists go about this? Do you have any easy auto-reassign-vertex-index solutions in Maya?
Yes it is correct
If you aren't changing the topology too much, You could use transfer attributes to update the UV changes from the edited mesh to the one with matching vertex indices.
m4dcow, that sounds great, but the last time I used Transfer Attributes was before I discovered the wonders of Topogun. Needless to say I used it for a very different task.
How would one go about doing that? Say you add a few verts to a mesh to solve some skewing, you duplicate the mesh to re-do the cage, and then have to export everything to xNormal. To avoid compositing in Photoshop, it's faster to export all meshes along with the corrected one. Thus, I assume you Transfer Attributes with all the lowpoly meshes before exporting?
If there is anywhere I could read more about this method, I'd be happy to do so and save you the explanation : )
m4dcow, that sounds great, but the last time I used Transfer Attributes was before I discovered the wonders of Topogun. Needless to say I used it for a very different task.
How would one go about doing that? Say you add a few verts to a mesh to solve some skewing, you duplicate the mesh to re-do the cage, and then have to export everything to xNormal. To avoid compositing in Photoshop, it's faster to export all meshes along with the corrected one. Thus, I assume you Transfer Attributes with all the lowpoly meshes before exporting?
If there is anywhere I could read more about this method, I'd be happy to do so and save you the explanation : )
Well I was thinking that you might be bringing the meshes into some other app to change UVs and when you bring them back into Maya, the vertex indices wouldn't match. So you could then then use transfer maps to transfer your new UVs to your original low poly and not have to re-create your cage so the indices match etc...
I suspect your problem might be along the lines of having many meshes, and the desire to fix 1 mesh, but then having that fix result in mismatched vertex order and the inconvenience of having to duplicate all the low poly meshes all over again to create cages etc...
So what I have found that will work, is make sure you have all your low poly meshes in a group and your start making your cages by duplicating this group (So you would have 2 groups named "low" and "cage" for example). When you see you need to change topology/fix UVs or whatever, you will do this on the low poly mesh (if you change topology the cage is useless anyway). When you bring this mesh back into Maya, delete the old low and cage meshes, and put the new mesh into the low poly group, duplicate it and put it into the cage group. The key is to make sure they are in the same order in the outliner in each group (use middle mouse to re-arrange). When you export, select the group itself in the outliner and export, if you select the meshes directly they export in the order selected, or seemingly randomly if you marquee select.
It requires a little bit of organization, but it seems better than saving a low, cage, exploded low and exploded cage for each separate mesh element, and then having to load all of those into xNormal.
Holy moly m4dcow, I did some tests and you're right! I didn't know the order in the outliner affected the vertex index. So, in short, to export everything correctly you have to make sure your LPs & cages are in the same order.
Hey guys,
i have terrible problem with normals *shrug*
i used separate uv tools in maya 2016 and then sew uvs back together into shells.
seems like xnormal is trying to generate normal map for individual polygons :poly127:
Hey guys,
i have terrible problem with normals *shrug*
i used separate uv tools in maya 2016 and then sew uvs back together into shells.
seems like xnormal is trying to generate normal map for individual polygons :poly127:
Are your smoothing groups/hard edges set correctly?
xNormal's Dilation filter gives me slightly incorrect results, which is bad for normal maps :P
Here shown with artificially increased contrast:
Not sure if xNormal is causing this problem, but I see the majority of your normal map's flat area has a color of 139,139,255, which isn't the natural flat value for a normal map. Those dark edges though are the correct value, or close to it anyways; 127,127,255 would be the correct color. If your normal map is this brighter(139,139,255) before you dilate, the issue could be coming from xNormal "normalizing" your image before dilating? I'm not sure though. It shouldn't do that because not all textures you dilate are normal maps.
Not sure if xNormal is causing this problem, but I see the majority of your normal map's flat area has a color of 139,139,255, which isn't the natural flat value for a normal map..
Thanks for the reply. I increased the contrast after dilation to show the problem. Here's the real map. Try cutting and pasting a fragment of it, then dilate
>>xNormal is that apparently every vertex index must be the same between the lowpoly and the >>cage; having the same number of vertices is not enough. Is this correct?
The cage musty have the same TOPOLOGY:
1. Equal #vertices and #faces.
2. Same indices for the cage<->LP faces.
In general, once your lowpoly is finished, create the cage using a clone operation.
Then, you can MOVE the cage's vertices but NEVER add/remove vertices nor faces.
Also, caution if you work with quads and you have the "Use shortest diagonal" enabled in the xNormal's triangulator. I recommend to triangulate all your meshes manually to avoid problems.
>>the majority of your normal map's flat area has a color of 139,139,255
Yep, caution with normalizing and also with gamma correction (specially for PNGs and OpenEXR )
So I am currently trying to work with your product and have run into a little Snag.
I am currently trying to take my asset pipeline and do a "slight" shift for baking purposes of unreal 4.
So I am baking Object space maps in 3ds max and then trying to use your converter to turn them into proper tangents using mikk Tspace calculator...
The Modo guys have a full writeup on how to take there object space and conver to tangent...In theory that same workflow should work the same for all 3D engines if followed the same way... however I am getting some weird results and it is driving me up the wall!
here is a breakdown of what is happening.
I should also note the Object space Texture is baked with no compression as Xnormal gave an error with that the 1st time.
I *think* you can export the FBX as Z-Up from Max and xNormal should account for that? If not, then you'd need to use OBJ and ensure that it's set tp Z-Up in the export prefs.
I figured it out for some stuff at work but I don't remember exactly any more
No I just did a test with both FBX and OBJ and they still had the same issue as before...it seems the switching of the green and blue texture is the easiest/safest bet right now.
I updated a workflow guideline on how to bake Object space maps in Max and convert for ue4 ready using xnormal!
Thanks a ton Farfarer! Your input was the only one that helped and answered my exact questions!
Also, if you give xNormal an FBX with Tangents and Binormals, it'll use the ones supplied by the FBX, rather than generating them from the MikkTSpace plugin.
And I updated the top little guide to reflect that!
I tried using the standard Xnormal export as well with no luck on this one. FBX was the only format that seemed to work squared with this.
If you can find out about the pre-export settings for the orientation change and having it work without the whole Texture Blue/green switch that would be awesome.
Optionally max users. I know you can do this change from inside...cant for the life of me seem to locate it though!
I would like to see a layers system in xNormal, where each layer is rendered in isolation, and automatically composited. Each layer could contain a list of low poly models, and a list of high poly models, which are only visible when that layer is processed.
This would fix the destructive workflow of exploding meshes, making it easier to make changes after baking.
Hi everyone. I seem to be having a really strange problem with Xnormal that I can't figure out. I am working on an armor set and have baked out several pieces so far, all without error. This one in particular gives me big AO artifacts and I can't pinpoint where I'm going wrong. I have checked the cage and it doesn't have my zbrush mesh leaking through. I have remade my retopology in 3Dcoat several times, thinking it was a problem there, but it still comes out exactly the same. As you can see, the normal map baked fine, I just get these nasty black splodges with my AO bake. Any help would be appreciated
Replies
interesting. thx!
This would eliminate the need for cages all together.
For example xnooraml "isolates" each model part and if it mat id and name matches the high poly that is in the same place it bakes that also taking into account shadows from surrounding objects.
2. Increase AA for bakes 8x or more, knald just recently did this for its software.This owuld be great for normal maps that bake fast anyways.
3. Another wish, xnormal automatically creates a bowl and or flat plane based upon user choice that takes into account the model scale upon the bowls creation. A box with flat walls and open top would also be nice.
4. Can xnormal be programmed to only load 1 lp 1 hp and cage at a time and bake that instead of loading all at once at the begggining ? I know the software has to go through the models and see if theu match and have any errors.
Thank you for making this software for all of us and alot people appreciate your efforts for all of us.
So if I want to use Handplane is because I want to save time.. so I need to convert the Maya tangent Normal maps to object space normal maps and use Handplane.
My question is: How can I get the ObjectSpace Normal map without the HighPoly mesh? Because if I have to rebake the Highpoly again... is not worth it to use Handplane.. I just use xNormal to bake the proper tangent space normal map. I was thinking if I can do it in Maya but I cannot find a way of doing it. Maybe I can load the Maya TB Calculator and the Maya Triangulator in Xnormal but.. where can I find them?
Same issue in both programs, I've tried every combination of exports and fixes, help!
I've got the following question: Does the polypaint information (ZBrush) of the Highpoly get lost, as soon as I import it to 3ds max and then export it again? Because I've exported my sculpt from ZBrush even with preserve polypaint on, then imported it to 3ds max for building the LP and then exported it from 3ds max again for baking in Xnormal. And as soon as I want to bake highpoly's vertex colours (ignore per vertex colour in HP slot unchecked), I get a white canvas. I guess if I just use the HP exported from ZBrush for baking, it will work, I'm just curious if the white canvas has something to do with exporting the HP from 3dsmax.
Thanks
Yes it is to do with passing the file through max. The obj format isn't really supposed to support vertex colors, but zbrush added their own way to hold it in the file and xnormal eventually made a way to bake that info.
I have tried importing and exporting with Maya, but I suspect Maya ignores the vert color info since it is not official spec, and also exporting as an fbx from Maya with vert colors to test, xnormal doesn't read these either, so even if you were to get the vert colors into max, you probably wouldn't be able to get them back out.
So use the file straight from zbrush to bake, to retopo you could always use goz in case you needed to move the high poly around.
I don't know how you'd get vertex colours into Max, but I do know that Max will export vertex colour with the .fbx file format, at least with a vertex paint modifier applied. I've used this to bake ID masks out of Xnormal at work, seems to work pretty well.
Well then I probably screwed something up exporting the fbx from maya with vertex colours.
Xnormal needs a pause button on render and or a stop button that you can continue later even after closing the program. Sudden chaotic storms can wreck havock upon you after rendering a ao map for 20 hours and it;s almost finished and your power goes out for 2 hours.
Rant off
BTW thank you for making this program for all of is to use.
1. the ability to transfer multiple textures (diffuse/gloss/normal/etc. from high to lowpoly in one go. Very useful for LOD creation.
2. revamp the baking options screen: on the left you could set up the map you want to bake then with a + button add it to a list on the right. This would allow for maps to be baked in different resolutions, with different settings, renderers, etc. in one go. Overriding ray distance, the vertex colours checkbox, and the other mesh settings/map bake would also be useful. For example, usually I want tangent and object space normal maps and an ao map in lower resolution for a mesh: currently I have to start a bake 3 times to achieve this, I can't just press bake and leave the computer to create all the maps I need.
3. a standard Windows ui or a ribbon ui.
4. less memory consumption for very high poly objs.
Thanks for this awesome tool!
A Tiger 1 Ausf E, the low poly is around 9 million triangulated polies broken into 5 texture maps 4k each.
Was baking the LP Hull to HP Zbrushed parts for the hull section at twice the res and then downsizing to get 4x aa.
This is not for any game, it's one of those go crazy with polies and push the limits of realism art peices.
I did an Elefant tank destroyer on Military-Meshs.com that the LP was 12 million and was a featured model of the month there.Includes full interior as well.
http://i259.photobucket.com/albums/hh295/Bubba91873/ElefantFront_zps9f50d9a7.png
http://i259.photobucket.com/albums/hh295/Bubba91873/Raidtors_Top_zps38964d61.png
http://i259.photobucket.com/albums/hh295/Bubba91873/Radiators_Front_zps53506987.png
http://i259.photobucket.com/albums/hh295/Bubba91873/Elefant_Left_Side_zpsa19f75de.png
The thing that drives me crazy about xNormal is that apparently every vertex index must be the same between the lowpoly and the cage; having the same number of vertices is not enough. Is this correct?
This means that if I have an exploded mesh, do some test bakes, decide to correct some UVs in another app and bring it back to Maya before exporting everything to xNormal, I'll get the "incorrect vertex index" problem. This actually only occurs to me when I re-do specific cages, since I guess this alters the vertex index.
I read through some threads but no clear solution is given. How do you artists go about this? Do you have any easy auto-reassign-vertex-index solutions in Maya?
Yes it is correct
If you aren't changing the topology too much, You could use transfer attributes to update the UV changes from the edited mesh to the one with matching vertex indices.
How would one go about doing that? Say you add a few verts to a mesh to solve some skewing, you duplicate the mesh to re-do the cage, and then have to export everything to xNormal. To avoid compositing in Photoshop, it's faster to export all meshes along with the corrected one. Thus, I assume you Transfer Attributes with all the lowpoly meshes before exporting?
If there is anywhere I could read more about this method, I'd be happy to do so and save you the explanation : )
Well I was thinking that you might be bringing the meshes into some other app to change UVs and when you bring them back into Maya, the vertex indices wouldn't match. So you could then then use transfer maps to transfer your new UVs to your original low poly and not have to re-create your cage so the indices match etc...
I suspect your problem might be along the lines of having many meshes, and the desire to fix 1 mesh, but then having that fix result in mismatched vertex order and the inconvenience of having to duplicate all the low poly meshes all over again to create cages etc...
So what I have found that will work, is make sure you have all your low poly meshes in a group and your start making your cages by duplicating this group (So you would have 2 groups named "low" and "cage" for example). When you see you need to change topology/fix UVs or whatever, you will do this on the low poly mesh (if you change topology the cage is useless anyway). When you bring this mesh back into Maya, delete the old low and cage meshes, and put the new mesh into the low poly group, duplicate it and put it into the cage group. The key is to make sure they are in the same order in the outliner in each group (use middle mouse to re-arrange). When you export, select the group itself in the outliner and export, if you select the meshes directly they export in the order selected, or seemingly randomly if you marquee select.
It requires a little bit of organization, but it seems better than saving a low, cage, exploded low and exploded cage for each separate mesh element, and then having to load all of those into xNormal.
Thanks a ton m4dcow!
i have terrible problem with normals *shrug*
i used separate uv tools in maya 2016 and then sew uvs back together into shells.
seems like xnormal is trying to generate normal map for individual polygons :poly127:
Are your smoothing groups/hard edges set correctly?
xNormal's Dilation filter gives me slightly incorrect results, which is bad for normal maps :P
Here shown with artificially increased contrast (that;s why the colors are not correct):
Edit: the original map: http://i.imgur.com/MhVhK8y.png
Not sure if xNormal is causing this problem, but I see the majority of your normal map's flat area has a color of 139,139,255, which isn't the natural flat value for a normal map. Those dark edges though are the correct value, or close to it anyways; 127,127,255 would be the correct color. If your normal map is this brighter(139,139,255) before you dilate, the issue could be coming from xNormal "normalizing" your image before dilating? I'm not sure though. It shouldn't do that because not all textures you dilate are normal maps.
Thanks for the reply. I increased the contrast after dilation to show the problem. Here's the real map. Try cutting and pasting a fragment of it, then dilate
The cage musty have the same TOPOLOGY:
1. Equal #vertices and #faces.
2. Same indices for the cage<->LP faces.
In general, once your lowpoly is finished, create the cage using a clone operation.
Then, you can MOVE the cage's vertices but NEVER add/remove vertices nor faces.
Also, caution if you work with quads and you have the "Use shortest diagonal" enabled in the xNormal's triangulator. I recommend to triangulate all your meshes manually to avoid problems.
>>the majority of your normal map's flat area has a color of 139,139,255
Yep, caution with normalizing and also with gamma correction (specially for PNGs and OpenEXR )
So I am currently trying to work with your product and have run into a little Snag.
I am currently trying to take my asset pipeline and do a "slight" shift for baking purposes of unreal 4.
So I am baking Object space maps in 3ds max and then trying to use your converter to turn them into proper tangents using mikk Tspace calculator...
The Modo guys have a full writeup on how to take there object space and conver to tangent...In theory that same workflow should work the same for all 3D engines if followed the same way... however I am getting some weird results and it is driving me up the wall!
here is a breakdown of what is happening.
I should also note the Object space Texture is baked with no compression as Xnormal gave an error with that the 1st time.
Try swapping the G and B channels of your object space map and giving that a go?
I figured it out for some stuff at work but I don't remember exactly any more
I updated a workflow guideline on how to bake Object space maps in Max and convert for ue4 ready using xnormal!
Thanks a ton Farfarer! Your input was the only one that helped and answered my exact questions!
I tried using the standard Xnormal export as well with no luck on this one. FBX was the only format that seemed to work squared with this.
If you can find out about the pre-export settings for the orientation change and having it work without the whole Texture Blue/green switch that would be awesome.
Optionally max users. I know you can do this change from inside...cant for the life of me seem to locate it though!
This would fix the destructive workflow of exploding meshes, making it easier to make changes after baking.
http://www.polycount.com/forum/showthread.php?t=156684
I can provide sample files ready for baking if you want to test it yourself.