Hello. I'm new to normal mapping, and i need help.
When i try to bake normal map, it seems ok (i attached image - problem00.jpg)
But when baking is finished, suddenly normal map become very angled (problem01.jpg)
Can you please tell me - how may i prevent it? I'm trying to bake proper normal map for about three days and still i can't get result.
this is normal (no pun intended). xnormal adds a "buffer" around the actual normal map to improve rendering. its called edge padding. just look it up in the normal map thread or the wiki if you want to learn more about it.
just try this normal map on your model (without changing the UVs of course) and you will see that it works fine (that is if you have no other baking errors).
Any blender users here with experience with creating cage meshes ?
It seems that almost any modifications I make to my duplicated LP (to create the cage)
cause xnormal to complain about vertices not matching up. Displacement and solidify modifiers seem like a no go and manual editing is hit or miss.
Make sure the triangulation is identical. In case you are using a triangulate modifier, apply it for your cage mesh before you start using displace/solidify.
Sorry if this has been answered before but I'm having a problem with Xnormal on my home computer. I keep getting this error when saving out my cages:
I use Xnormal at Uni and never have this problem and I've reset the settings to their defaults but it doesn't seem to sorted it. Anyone know what I'm doing wrong?
Auldbenkenobi, the OVB mesh format is not designed to deal with very dense meshes because it's XML based. Better use the SBM format which is binary-based.
You're getting that error because there is no FBX mesh "exporter", only OVB/SBM. You should add the proper mesh extension.
You can convert then the output SBM mesh into FBX importing it into 3dsmax or Maya, but usually it's just ok to save the cage as SBM and answer "yes" to the automatic cage assignment after your save the meshes in the 3D viewer.
Hey people.
I hope this issue hasn't been answered a 100 times. I searched this thread and the forum in general but did not find any usefull information to 32 bit normalmaps, which I guess are a large part of my problem.
I'm expeirencing some issue with the new toolbag, although I have to admit I have encountered such issues with toolbag 1 as well but didn't cared enough to really find out what was going on. So here is the isue:
When I invert my gloss map my whole asset acts more like a mirror surface. So far everything works fine. But on most parts of my surfaces the reflections are kind of distorted and have discontinuities (can't find a better word for this) here is a screenshot:
My idea is, that my normalmap was not rendered in 32 bit color depth and as such there might be not enough colorspace to cover the super slight gradients on those flat surfaces.
The above area in my normalmap looks like this:
I also did a test and looked at each colorchannel on its own and adjusted the levels so I could see what is going on. Well the green channel shows exactly those distortions.
The normalmap was baked in xnormal. I'm pretty sure that this is a colordepth issue. I tried other things like using different tangent basis in toolbag. But as toolbag supports the xnormal tangent basis this wasn't helping.
How are you guys go for rendering 32 bit normalmaps? I tried different fileformats like tiff or hdr or raw that have 32 bit color depths or can at least store every nuance. Bit all those bakes had some strange colordeviation from my original normals. So how you tackle such issues? I could try to bake the shit in maya but I'd rather keep using xNormal. It just provides more control.
Hey people.
I hope this issue hasn't been answered a 100 times. I searched this thread and the forum in general but did not find any usefull information to 32 bit normalmaps, which I guess are a large part of my problem.
I'm expeirencing some issue with the new toolbag, although I have to admit I have encountered such issues with toolbag 1 as well but didn't cared enough to really find out what was going on. So here is the isue:
When I invert my gloss map my whole asset acts more like a mirror surface. So far everything works fine. But on most parts of my surfaces the reflections are kind of distorted and have discontinuities (can't find a better word for this) here is a screenshot:
My idea is, that my normalmap was not rendered in 32 bit color depth and as such there might be not enough colorspace to cover the super slight gradients on those flat surfaces.
The above area in my normalmap looks like this:
I also did a test and looked at each colorchannel on its own and adjusted the levels so I could see what is going on. Well the green channel shows exactly those distortions.
The normalmap was baked in xnormal. I'm pretty sure that this is a colordepth issue. I tried other things like using different tangent basis in toolbag. But as toolbag supports the xnormal tangent basis this wasn't helping.
How are you guys go for rendering 32 bit normalmaps? I tried different fileformats like tiff or hdr or raw that have 32 bit color depths or can at least store every nuance. Bit all those bakes had some strange colordeviation from my original normals. So how you tackle such issues? I could try to bake the shit in maya but I'd rather keep using xNormal. It just provides more control.
Thanks in advance.
16bit should be plenty for 99.99% of cases where star stepping is a problem and you can render to 16bit tiff in xNormal via the xNormal plugin manager> Image Exporters>Tiff Exporter>Configure>16bit.
OFC, also make sure that you are triangulating your mesh before baking and then use the exact same mesh (triangulated) for rendering.
So, I've been lurking on these forums for a while now (years), and I just had to post with this question, I am at my wits end! I only recently discovered normals and how they work *facepalm*. Well, basically I was wondering what you all made of these artifacts that appear clearly where my Uvmap was made on the low poly, I have to have screwed up somewhere... The detail from the high poly mesh is almost nonexistent...
Any imput on what I'm doing wrong? I've tried to read but only made it from pages 1-15 then like the last 15 too, I get a bit of reading in at work, oddly these forums aren't sonicwaffled, how bout that... No pictures tho so it's a bit difficult keeping up hehe. Also hi everyone.
OP made an amazing tool here, I know the problem is with me, I found a sweet tutorial written out in steps here in this thread somewhere do it quick n dirty but this is the result after following it...
hey i rember watching a tutorial where someone was baking a edge highlight map. there was some tweaking and inverting of the ao or cavity settings involved. some very low or even negative values. i cant find it anymore. can someone give me a hint?
Use a cage to fix both the problems. If you get bad projection errors you'll need to either adjust the cage or add some geometry to compensate near the edges.
SBM now exports with a different offset to any OBJs I export from either zbrush or max. If I import the SBM back into max it is rotated 90 degrees and the translation on the Y axis is flipped> ie instead of +33 it is -33. Or so I gather from eyeballing it briefly.
So pics so you know what I am talking about>
Are there any controls in the SBM exporter/ini file or something that changes this back to the previous way of it working? Or am I just an idiot and missed something?
I need to use OBJs for high poly models as importing them into max to use the SBM export to keep them sharing the correct space isn't always viable due to the millions of poly that max won't like, wiping poly paint, and sometimes I want to do that more than once, it just takes extra time and bums me out even if it isn't 10mil poly mesh, really don't want to have faff about with adding to the workflow and making textures on high poly meshes and would rather just use the polypaint when it makes sense to do so etc.
Hey everyone. I am trying to bake an AO in Xnormals from a high poly Decimated Zbrush Mesh. I am getting some really dark areas on my AO. My AO settings are all default except I turned the rays up to 256.
Here is the Low res in Maya with the Texture Applied so you can see the Errors
Here is the same image with the High res also visible
^^It just looks like you are getting black where the low poly isn't covering the high.
Use a cage and make sure the cage fully encompasses the high poly, making sure about keeping an eye on any faces that get triangulated convexly and that should solve those areas.
Hey, did anyone encounter this problem:
I have exported lowpoly mesh with seemingly correct UVs. When I try to bake in xnormal, I get totally different UVs that does not make any sense. I have checked if I have multiple UV sets, but that wasn't the case. I also did entirely new UVs with no overlapping shells (just using auto UVs tool in Maya) and I got exact same UV problem. Any ideas how can this be happening?
Looks like you have overlapping UVs, try to move the mirrored UV to the next UV range (from 0/1 to -1/0 for example) and rebake.
Yes, it has overlapping UVs. I tried before, here I did it again - entirely new UVs. But this strange behaviour is still here. It does not make any sense at all - where does that little UV shell come from and where everything else is.
Material-id baking process in xNormal 32-bit a'la 3dsMax:
I'm not sure if the 64-bit version is capable of this process. . . :DD just kidding.
1. Its a good idea to UV your hipolys and texture them and also sculpt them in Zbrush so they have good geometric detail and a texture. Separate hipoly Subtools by material. 2. Bake the normal map, AO, base texture, thickness map in xNormal.
Fantastic results! Wow, it really looks good. Now on to creating a texture in Photoshop! Umm.. wait..
it would be soOo good if we could bake a Material-id map in xNormal. Nothing special like a multi-subobject thingy, just single-id (one differentiating color for each Subtool) so that I can quickly select hipoly components in the texture and enhance the already baked base texture in Photoshop.
3. Looking at the base texture map baked by xNormal from ~10 hipoly OBJs (Subtools) - if you do this process for your own paid work - its really easy to spot / have the idea, what is needed here to create a nice & useful Material-id map that can be used for creating selection masks to separate wooden, metal, etc.. texture components of the model in Photoshop.
Aand Voila! I scribbled in what is what. Separated the many wooden subtools by color for xNormal to render, just for fun. This is a reinforced door = metal+wood only.
Yes, it has overlapping UVs. I tried before, here I did it again - entirely new UVs. But this strange behaviour is still here. It does not make any sense at all - where does that little UV shell come from and where everything else is.
Maybe try to load the 3D Viewer of xNormal, this will help to see some other problems. Maybe your HP and LP don't align properly (that's what I think regarding your second texture result).
Maybe try to load the 3D Viewer of xNormal, this will help to see some other problems. Maybe your HP and LP don't align properly (that's what I think regarding your second texture result).
Ah, silly mistake. I've scaled lowpoly and by some reason totally forgot I will need to bake it. Thanks, it works now
Could someone help me out here ? I appear to be in a bit of a pickle.
There's some ugly seams in my normal maps along my UV borders. The mesh is made up out of a single smoothing group. There's more than enough room for edge padding. I'm using blender and xnormal.
This is the map :
NanoTurtle, according to the normalmap gurus in this forum, hard edges have to be implemented at all UV-splits.
Do you bake without a cage? If so, using one might solve your problem.
NanoTurtle, according to the normalmap gurus in this forum, hard edges have to be implemented at all UV-splits.
Do you bake without a cage? If so, using one might solve your problem.
I thought it was the other way around, UV splits at all hard edges ?
Forgot to mention that I'm using a cage.
NanoTurtle, according to the normalmap gurus in this forum, hard edges have to be implemented at all UV-splits.
Do you bake without a cage? If so, using one might solve your problem.
You don't HAVE to add hard edges to UV splits, you do have to add UV splits at hard edges though.
As in you could leave it smooth shaded and it would technically bake fine, but it's free to add hard edges at the UV splits as it won't increase the vert count on the model and will allow the normal map to render better when the baker and target renderer isn't synced.
Hard edges need UV splits. UV splits DO NOT need hard edges.
But those borders you're seeing are padding, they're a good thing - it prevents mip-mapping from giving shading artifacts at UV seams. If you view your UVs, you'll see that the padding is on the outside of the UV seam, so doesn't directly affect the surface.
Hard edges need UV splits. UV splits DO NOT need hard edges.
But those borders you're seeing are padding, they're a good thing - it prevents mip-mapping from giving shading artifacts at UV seams. If you view your UVs, you'll see that the padding is on the outside of the UV seam, so doesn't directly affect the surface.
I'm not talking about the padding, but this here :
There's some ugly seams in my normal maps along my UV borders. The mesh is made up out of a single smoothing group. There's more than enough room for edge padding. I'm using blender and xnormal
Judging by your texture one channel is inverted definitely. Most likely green but it might be also red (can't tell without some pics of the whole mesh).
Judging by your texture one channel is inverted definitely. Most likely green but it might be also red (can't tell without some pics of the whole mesh).
I'm afraid that's not it either. I am using +++ in blender and +-+ in cryengine as I'm supposed to. -++ or --+ makes it look even worse.
Zoom out to where you would see this in game. Can you still see the seam?
Even with best case circumstances, you may still get seams. This looks like there is a slight pixel difference where the seam is on the normal map. This is caused, most likely, because your two uv islands are at odd angles compared to the next.
After you get a diffuse on there and zoom out to regular view, it will not be noticeable.
If you want to fix it you can try adding a bit more geo, say a bevel, to give the normal map some help. You can also try breaking your UV islands up a bit more (i don't recommend this) which can also help the normal map bake a little cleaner.
I've done some more tests and it seems it's the CryEngine exporter that is to blame, not my normalmaps. Good to know I got baking right this time though. Thanks for the help !
I just started using xNormal(v3.18.4.37652), and I have a problem baking. It seems like my nomarl map is inverted. Does anyone know what the problem is? I am using a cage
Please help me solving this issue:
This wheel is part of a multimesh object, I want to bake it piece by piece, but I have problem even with the first one. It's a simple cilinder. On the picture is the high poly version and next the applied normal map on the low poly. The problem is that band on both side of the wheel. I only get this when i use cages and I did dozens of different test, adjusting the cage many times. Without the cage I don't get that band, but then I have other problems (The low poly cilinder has only 16 segment)
I really tried smaller, bigger cages. some was much bigger than the high poly, the other was the simple copy of the low poly (same size), yet this belt stays.
How can I bake this to make it look good? These are just test btw, once I figure it out I intend to sculpt more details on it.
I did two version: one where i used minimum amount of UV seams, and the other where I marked all high-angled edge. I saw not much difference, but the one I splitted more is a bit better. Not sure I should go on that route.
I'm currently trying to cage-bake using an external cage from Blender, And I keep getting infinite vertex mismatch errors.
Its driving me insane. The vertex count and topology of the LP and the cage are absolutely the same, yet I keep getting errors!
My workflow is:
1.Triangulate Low Poly.
2.Use the solidify Modifier to create the cage. (And delete the inner part of the mesh)
3.Export as OBJ.
While I managed to get it working before, All of a sudden I get this random vertex index error.
Also, in a rare case where I manage to proceed with the bake, I get weird results.
As if the different parts of the mesh bake on one another.
My mesh is basically a couple of different objects merged together and exported as a single OBJ file.
Will separating the High Poly meshes to separate OBJ files prevent baking errors? Or should the cages block any weird reflections.
I'm currently trying to cage-bake using an external cage from Blender, And I keep getting infinite vertex mismatch errors.
Its driving me insane. The vertex count and topology of the LP and the cage are absolutely the same, yet I keep getting errors!
My workflow is:
1.Triangulate Low Poly.
2.Use the solidify Modifier to create the cage. (And delete the inner part of the mesh)
3.Export as OBJ.
While I managed to get it working before, All of a sudden I get this random vertex index error.
Also, in a rare case where I manage to proceed with the bake, I get weird results.
As if the different parts of the mesh bake on one another.
My mesh is basically a couple of different objects merged together and exported as a single OBJ file.
Will separating the High Poly meshes to separate OBJ files prevent baking errors? Or should the cages block any weird reflections.
I don't really use blender, but from what you describe using the solidify modifier, and having to delete part of the mesh after the operation, its no wonder the vertex indices won't match up.
After a brief search, the shrink/fatten tool is what you might want to use, since it simply moves verts along their normals.
That workflow is a bit cumbersome but it does work. I usually avoid cages altogether because of that and instead bake OS normalmaps that I convert with Handplane and use blockers where ever necessary. However the problem is most probably that you're using different objects, so try either combining all the objects into one before you export or export the different objects (and cages) to separate files.
The shrink/fatten tool works too, but when you're dealing with hardsurface meshes with sharp angles it often fails at said angles so you need to either fatten the mesh a lot or manually adjust those parts. Neither workflow is great, but I've found the one with the solidify produces the best result in the most cases.
Replies
When i try to bake normal map, it seems ok (i attached image - problem00.jpg)
But when baking is finished, suddenly normal map become very angled (problem01.jpg)
Can you please tell me - how may i prevent it? I'm trying to bake proper normal map for about three days and still i can't get result.
just try this normal map on your model (without changing the UVs of course) and you will see that it works fine (that is if you have no other baking errors).
It seems that almost any modifications I make to my duplicated LP (to create the cage)
cause xnormal to complain about vertices not matching up. Displacement and solidify modifiers seem like a no go and manual editing is hit or miss.
I have a tutorial about blender to xNormal on the cgcookie site.
http://cgcookie.com/blender/2013/12/04/baking-normal-maps-blender-xnormal/
There I go over everything also mirror the settings I use when exporting the meshes.
I've got me some nice bakes now. awesome.
I use Xnormal at Uni and never have this problem and I've reset the settings to their defaults but it doesn't seem to sorted it. Anyone know what I'm doing wrong?
You're getting that error because there is no FBX mesh "exporter", only OVB/SBM. You should add the proper mesh extension.
You can convert then the output SBM mesh into FBX importing it into 3dsmax or Maya, but usually it's just ok to save the cage as SBM and answer "yes" to the automatic cage assignment after your save the meshes in the 3D viewer.
I hope this issue hasn't been answered a 100 times. I searched this thread and the forum in general but did not find any usefull information to 32 bit normalmaps, which I guess are a large part of my problem.
I'm expeirencing some issue with the new toolbag, although I have to admit I have encountered such issues with toolbag 1 as well but didn't cared enough to really find out what was going on. So here is the isue:
When I invert my gloss map my whole asset acts more like a mirror surface. So far everything works fine. But on most parts of my surfaces the reflections are kind of distorted and have discontinuities (can't find a better word for this) here is a screenshot:
My idea is, that my normalmap was not rendered in 32 bit color depth and as such there might be not enough colorspace to cover the super slight gradients on those flat surfaces.
The above area in my normalmap looks like this:
I also did a test and looked at each colorchannel on its own and adjusted the levels so I could see what is going on. Well the green channel shows exactly those distortions.
The normalmap was baked in xnormal. I'm pretty sure that this is a colordepth issue. I tried other things like using different tangent basis in toolbag. But as toolbag supports the xnormal tangent basis this wasn't helping.
How are you guys go for rendering 32 bit normalmaps? I tried different fileformats like tiff or hdr or raw that have 32 bit color depths or can at least store every nuance. Bit all those bakes had some strange colordeviation from my original normals. So how you tackle such issues? I could try to bake the shit in maya but I'd rather keep using xNormal. It just provides more control.
Thanks in advance.
16bit should be plenty for 99.99% of cases where star stepping is a problem and you can render to 16bit tiff in xNormal via the xNormal plugin manager> Image Exporters>Tiff Exporter>Configure>16bit.
OFC, also make sure that you are triangulating your mesh before baking and then use the exact same mesh (triangulated) for rendering.
Hopefully that will work out for you.
Any imput on what I'm doing wrong? I've tried to read but only made it from pages 1-15 then like the last 15 too, I get a bit of reading in at work, oddly these forums aren't sonicwaffled, how bout that... No pictures tho so it's a bit difficult keeping up hehe. Also hi everyone.
OP made an amazing tool here, I know the problem is with me, I found a sweet tutorial written out in steps here in this thread somewhere do it quick n dirty but this is the result after following it...
I tried to bake with and without cage. I tried to uncheck Discard Back Faces. I didn't tried bake this in Max yet.
Any ideas ?
Use a cage
Just sure it covers completely the HP mesh ... and play a bit with the poles to avoid the typical wobbling effect on cylinders.
1)
I want to save circle in the center
And second: I don't get how to bake hard surfaces with good chamfer edges. I have only this one
2)
because if I turn on average normals or have one smoothing group in model- this parts becames really wierd
Max 2012 x64
SBM now exports with a different offset to any OBJs I export from either zbrush or max. If I import the SBM back into max it is rotated 90 degrees and the translation on the Y axis is flipped> ie instead of +33 it is -33. Or so I gather from eyeballing it briefly.
So pics so you know what I am talking about>
Are there any controls in the SBM exporter/ini file or something that changes this back to the previous way of it working? Or am I just an idiot and missed something?
I need to use OBJs for high poly models as importing them into max to use the SBM export to keep them sharing the correct space isn't always viable due to the millions of poly that max won't like, wiping poly paint, and sometimes I want to do that more than once, it just takes extra time and bums me out even if it isn't 10mil poly mesh, really don't want to have faff about with adding to the workflow and making textures on high poly meshes and would rather just use the polypaint when it makes sense to do so etc.
SBMs export correctly positioned to OBJs again.
Here is the Low res in Maya with the Texture Applied so you can see the Errors
Here is the same image with the High res also visible
Here they are in TopoGun
Here is the actual Map
Use a cage and make sure the cage fully encompasses the high poly, making sure about keeping an eye on any faces that get triangulated convexly and that should solve those areas.
I have exported lowpoly mesh with seemingly correct UVs. When I try to bake in xnormal, I get totally different UVs that does not make any sense. I have checked if I have multiple UV sets, but that wasn't the case. I also did entirely new UVs with no overlapping shells (just using auto UVs tool in Maya) and I got exact same UV problem. Any ideas how can this be happening?
Yes, it has overlapping UVs. I tried before, here I did it again - entirely new UVs. But this strange behaviour is still here. It does not make any sense at all - where does that little UV shell come from and where everything else is.
I'm not sure if the 64-bit version is capable of this process. . . :DD just kidding.
1. Its a good idea to UV your hipolys and texture them and also sculpt them in Zbrush so they have good geometric detail and a texture. Separate hipoly Subtools by material.
2. Bake the normal map, AO, base texture, thickness map in xNormal.
Fantastic results! Wow, it really looks good. Now on to creating a texture in Photoshop! Umm.. wait..
it would be soOo good if we could bake a Material-id map in xNormal. Nothing special like a multi-subobject thingy, just single-id (one differentiating color for each Subtool) so that I can quickly select hipoly components in the texture and enhance the already baked base texture in Photoshop.
3. Looking at the base texture map baked by xNormal from ~10 hipoly OBJs (Subtools) - if you do this process for your own paid work - its really easy to spot / have the idea, what is needed here to create a nice & useful Material-id map that can be used for creating selection masks to separate wooden, metal, etc.. texture components of the model in Photoshop.
Aand Voila! I scribbled in what is what. Separated the many wooden subtools by color for xNormal to render, just for fun. This is a reinforced door = metal+wood only.
Maybe try to load the 3D Viewer of xNormal, this will help to see some other problems. Maybe your HP and LP don't align properly (that's what I think regarding your second texture result).
There's some ugly seams in my normal maps along my UV borders. The mesh is made up out of a single smoothing group. There's more than enough room for edge padding. I'm using blender and xnormal.
This is the map :
Do you bake without a cage? If so, using one might solve your problem.
I thought it was the other way around, UV splits at all hard edges ?
Forgot to mention that I'm using a cage.
You don't HAVE to add hard edges to UV splits, you do have to add UV splits at hard edges though.
As in you could leave it smooth shaded and it would technically bake fine, but it's free to add hard edges at the UV splits as it won't increase the vert count on the model and will allow the normal map to render better when the baker and target renderer isn't synced.
But those borders you're seeing are padding, they're a good thing - it prevents mip-mapping from giving shading artifacts at UV seams. If you view your UVs, you'll see that the padding is on the outside of the UV seam, so doesn't directly affect the surface.
I'm not talking about the padding, but this here :
As far as one can tell the normal map itself looks fine, so I think your bake is ok.
Kinda gives me the impression of the orientation is wrong. Try inverting the G channel.
Can I manually get the plug-ins from somewhere, or what?
Judging by your texture one channel is inverted definitely. Most likely green but it might be also red (can't tell without some pics of the whole mesh).
I'm afraid that's not it either. I am using +++ in blender and +-+ in cryengine as I'm supposed to. -++ or --+ makes it look even worse.
Even with best case circumstances, you may still get seams. This looks like there is a slight pixel difference where the seam is on the normal map. This is caused, most likely, because your two uv islands are at odd angles compared to the next.
After you get a diffuse on there and zoom out to regular view, it will not be noticeable.
If you want to fix it you can try adding a bit more geo, say a bevel, to give the normal map some help. You can also try breaking your UV islands up a bit more (i don't recommend this) which can also help the normal map bake a little cleaner.
Please help me solving this issue:
This wheel is part of a multimesh object, I want to bake it piece by piece, but I have problem even with the first one. It's a simple cilinder. On the picture is the high poly version and next the applied normal map on the low poly. The problem is that band on both side of the wheel. I only get this when i use cages and I did dozens of different test, adjusting the cage many times. Without the cage I don't get that band, but then I have other problems (The low poly cilinder has only 16 segment)
I really tried smaller, bigger cages. some was much bigger than the high poly, the other was the simple copy of the low poly (same size), yet this belt stays.
if pics not working here is a direct link:
http://imgur.com/pGXpcA8
How can I bake this to make it look good? These are just test btw, once I figure it out I intend to sculpt more details on it.
I did two version: one where i used minimum amount of UV seams, and the other where I marked all high-angled edge. I saw not much difference, but the one I splitted more is a bit better. Not sure I should go on that route.
Its driving me insane. The vertex count and topology of the LP and the cage are absolutely the same, yet I keep getting errors!
My workflow is:
1.Triangulate Low Poly.
2.Use the solidify Modifier to create the cage. (And delete the inner part of the mesh)
3.Export as OBJ.
While I managed to get it working before, All of a sudden I get this random vertex index error.
Also, in a rare case where I manage to proceed with the bake, I get weird results.
As if the different parts of the mesh bake on one another.
My mesh is basically a couple of different objects merged together and exported as a single OBJ file.
Will separating the High Poly meshes to separate OBJ files prevent baking errors? Or should the cages block any weird reflections.
I don't really use blender, but from what you describe using the solidify modifier, and having to delete part of the mesh after the operation, its no wonder the vertex indices won't match up.
After a brief search, the shrink/fatten tool is what you might want to use, since it simply moves verts along their normals.
The shrink/fatten tool works too, but when you're dealing with hardsurface meshes with sharp angles it often fails at said angles so you need to either fatten the mesh a lot or manually adjust those parts. Neither workflow is great, but I've found the one with the solidify produces the best result in the most cases.