If the xnormal map looks good in xnormal, then it's fine. Each app makes maps that look best in its own display. What does it look like in your game engine, that's what really matters.
The problem is Im unsure it did do it before. Dont have any local older copies of xnormal to test against. Jogshy, is here a backlog of your older releases somewhere? Say like mid last year 3.14 ish or so?
Have you rendered the NM in xnormal or in 3dsmax? xN maps should be viewer in xNormal. 3dsmax's ones in 3dsmax.
Well, some advices:
1. Enable the "Show tangents" in the xN's 3D viewer to see if the UVs are well welded.
2. Render a "wireframe and ray fails map" to see if rays are failing or there are problems with your UVs.
3. Render the normal map as object space and see if the seam still appears.
4. Have you setup your cage in a way that covers completely the highpoly mesh?
5. Do you use Xoulil's max shader or the default one?
6. Don't use the max2obj exporter... Nevah!
7. Collapse + Edit mesh + ResetXForm ( + optionnally,Projection ) before exporting, always.
Ho Jogshy. I don't know if you saw the pictures as my site seems to be currently offline.
Last one was in xnormal 3d viewer and it still showed issue with seam. Have checked all you put. No difference. Should I send you files so you can test on your end?
1. Enable the "Show tangents" in the xN's 3D viewer to see if the UVs are well welded.
Showing tangents no issue.
2. Render a "wireframe and ray fails map" to see if rays are failing or there are problems with your UVs.
Nope all show
3. Render the normal map as object space and see if the seam still appears.
Attempted now and no the seam does not appear Only with your tangent render. Hence wondering if there is a bug.
4. Have you setup your cage in a way that covers completely the highpoly mesh?
Absolutely
5. Do you use Xoulil's max shader or the default one?
Default. But again inside xnormal itself showing same issue.
Last one was in xnormal 3d viewer and it still showed issue with seam. Have checked all you put. No difference. Should I send you files so you can test on your end?
1. Assign a random VDM/normal map file(any pow2 texture file will work). Enable the "show vector displacement map's seams". UV seams are marked in red.
or
2. In 3dsmax, mark the conflictive faces. Then, place an UVW Unwrap modifier with the all the "show seams" options enabled. Seams will be marked in green.
or
3. Assign a normal map, enter the xN's viewer. Enable the "show tangent basis". If you see any point with more than one three-axis basis then there is a seam there. ( important: assign a normal map or you'll see only the blue lines, which correspond with the normals ).
or
4. Render a "wireframe and ray fails map". UV seams are marked in green ( try to render always at 2k x 2k to see them well ).
1. Assign a random VDM/normal map file(any pow2 texture file will work). Enable the "show vector displacement map's seams". UV seams are marked in red.
or
2. In 3dsmax, mark the conflictive faces. Then, place an UVW Unwrap modifier with the all the "show seams" options enabled. Seams will be marked in green.
or
3. Assign a normal map, enter the xN's viewer. Enable the "show tangent basis". If you see any point with more than one three-axis basis then there is a seam there. ( important: assign a normal map or you'll see only the blue lines, which correspond with the normals ).
or
4. Render a "wireframe and ray fails map". UV seams are marked in green ( try to render always at 2k x 2k to see them well ).
I hope it helps.
Jogshy. I think there is a misunderstanding. Those seams are known and purposely made to uvw mirror. If you look at the max file I sent in fact the mirrored portions are off the uv space with the uv modifier in the stack. The issue is. Max correctly blends the island seams when it builds the normal map Xnormal is not. See below. The max normal map in xnormal displays fine. The Xnormal made map does not.
I also noticed this on a ball I created recently. Xnormal is not correctly blending these seams on uv islands.
If you want, if you can show me where I can download an earlier version of xnormal 3 from mid last year, I can see if it does the same. However, I dont believe Ive experienced this before. Im implying something I think there is a bug. Specifically with the tangent space renderer as the object space worked fine.
normal is not correctly blending these seams on uv islands.
hose seams are known and purposely made to uvw mirror
I don't see your UVs mirrored. There are not in range (-inf,0] or [1,+inf).
If there is a UV seam the light won't be continuous. Perhaps 3dsmax solves that using some black magic ( like auto UV-welding with very small threshold ), but if there is an UV seam there the logical and normal is to get a discontinuity in the lighting.
I'll review my code searching for a possible bug but I think and UV seam will be always an UV seam ! If you want to mitigate it just keep some space over the neighbor island and let the dilation filter to deal with it... but it won't be perfect neither.
It should be there for the 3.17.1. See the xNormalSBM_Maya2k11_x64.mll file in the x64\maya_plugins folder.
I don't see your UVs mirrored. There are not in range (-inf,0] or [1,+inf).
If there is a UV seam the light won't be continuous. Perhaps 3dsmax solves that using some black magic ( like auto UV-welding with very small threshold ), but if there is an UV seam there the logical and normal is to get a discontinuity in the lighting.
I'll review my code searching for a possible bug but I think and UV seam will be always an UV seam ! If you want to mitigate it just keep some space over the neighbor island and let the dilation filter to deal with it... but it won't be perfect neither.
Jogshy. No offense, but I see you went back and changed your answer. Your original was you were going to look over the code for tangent. As said Object worked fine in xnormal.
The UVs arent in range, they are outside the uv space purposely.. The issue is as you can see with your answer. If max is auto uv'ing welding. Why does it not show up in xnormal? Unless your stating the way max bakes the normals. If it did uv weld baking, that would have left a seam so wouldn't that have been more apparent?
Im also unsure this happened in the past, hence why if you can point me to your backlog of releases so I can test.
Ok, I see your confusion. The sbm files I sent where based on a different version from what I burned. I have included the correct sbm file for the base with the mirrors outside. The pictures you see on the previous page where taken with the correct sbm with mirror outside the uv space.
I apologize for that confusion, but now hopefully it should be apparent this is something with xnormal tangent burning of curved surfaces and islands.
Edit. In fact, I have made a custom version of the normal map with two different layers so you can see the difference of how those are being burnt. If you click on the paths tab, it will give you the uv outlines to make it easier to discern.
oXY, you have a seam there, also in your new meshes...
It's VERY hard to see it, because if you place an UVW Wrap modifier with the "show seams" options does not show unless you make a full zoom over the conflictive zone...
But see it, here is:
I simply welded the conflictive vertices/edges:
and no longer shows the light discontinuity in xNormal. You should also weld the edge on the left though ( those > and < edges )
I think the UV layout you use contains too many seams. If you don't need to sculpt each rail independently and you don't use object-space NMs, I suggest you to use an UV layout like this one:
There's no need to use more texture space for the plaform because the top and bottom part can share the TS.
Jogshy. I know about those seams. Those were done purposely to not have as much pixel stretching. Moreover, max rendered them fine. And max render looks fine in xnormals viewer while xnormals own does not. Look at the normal map I sent. You can see there is a difference not just in those seams but the entire way the normal map looks in those areas.
I know seams will always have a seam, but again, I have proof positive that with xnormals own 3d viewer, the max ones are almost if not invisible while the xnormal ones are plain as day. Further, again, I have had this happen on circular objects. Which as you know there is no way to have a simple hidden seam.
Oh and the wasted space on the map is actually reserved for another object that I have (you can see in the normal map I sent).
I know my website was out part of last week, but if you go to the previous page you can see all the images I had posted along the way.
Well, in theory you should get light artifact there because there is a UV seam... but I wonder what 3dsmax does to avoid it and if it would work with a box. Black magic, definitely.
An issue I'm having at the moment: When I bake my normals, it gets to about the 5th bar in the rendering window, then it gets caught up and stays there. It's done this to me on two meshes that are very similar, one is a tree base, and the other is a bunch of smaller branches. It's not a visual error for me so it's pointless to post pics, i can't even get it to render correctly. Do you know what some possible causes may be, Jogshy? Maybe it's the way the mesh is built? Thanks in advance.
Anyone else getting errors when visiting xnormal.net? For the last twenty-four hours, seems like if it's not 'page not found' errors, I get server errors trying to access the tutorials.
Anyone else getting errors when visiting xnormal.net? For the last twenty-four hours, seems like if it's not 'page not found' errors, I get server errors trying to access the tutorials.
http://www.xnormal.net works for me ( don't use /1.aspx ). Try to clean the web browser's cookies and perform a complete page refresh with CTRL+F5.
An issue I'm having at the moment: When I bake my normals, it gets to about the 5th bar in the rendering window, then it gets caught up and stays there.
Try the 3.17.2 Beta 3 pls. I've corrected a hang rendering the normals.
[trivia]
hey, just throwing this in between all the relevant tech stuff:
if you go crazy for xNormal and you are a facebook user too,
then you might want to join the unofficial xNormal appreciation group.
currently we are ~100 counting..
so see you there if you think xNormal is awesome!
[/trivia]
sorry for this little advert. but this group is just made for fun and i like to spread the word, nothing commercial. hope its no problem.
Can anyone please explain to me why when I bake a normal or an AO, the renders end up exploding right after it finished. It looks fine while it renders but once it finished they just explode and stretch outwards.
Can anyone please explain to me why when I bake a normal or an AO, the renders end up exploding right after it finished. It looks fine while it renders but once it finished they just explode and stretch outwards.
Sorry I don't understand the last part. Are you referring to the dilation filter?
'stretch outwards' sounds like the edge padding, which is good behaviour! It stops your background colour from bleeding into your texture when that gets filtered ingame
- Optimized the software CPU rendering a 5% ( thx to new LR child heuristics ).
- The Optix renderer now uses a better sampling to reduce banding artifacts. Also improved sightly the performance.
- Solved some bugs in the displacement map computations with the MatchUV option enabled.
- Removed the dependency from the CUDA runtime DLL ( driver ftw! ).
- Fixed a bug in the xNormal's installer that was causing to abort the installation due to an incorrect .NET 2.0 detection under Windows 7.
- Reduced a bit more the xNormal's installer because the program no longer depends on the VS2005 SP1 runtime, the CUDA 3.0 DLL runtime and neither DX9.0c ( which is included in XP SP2 ).
- Solved some compatibility problems with OpenGL 3.2 in the Optix renderer.
- Solved a rare problem in the Default Bucket Renderer that could lead to slow/hang the render.
- Fixed a problem loading .DDS files with mipmapping ( affecting to the DDS image importer and the OpenGL/DX9/DX10 graphics drivers ).
- Solved a very-rare potential problem computing the tangent space for opposite faces.
- Fixed a problem in the OBJ mesh importer that could cause to use more RAM than should be used to load the objects.
- Recompiled using the latest libraries ( Optix 2.0 final, DX June 2010, etc... )
Jogshy, have you considered adding curvature maps to Xnormal?
My workflow's been to decimate my meshes and bake them in Max, but while that works fine for normals, the curvature comes out horribly mangled and needs quite some fixing by hand:
It would be great if I could do these in Xnormal.
I had a bug while trying Xnormal so I decided to uninstalled it and then reinstall it, But when i'm reinstalling it, it says that the tool is already on my computer wich is not possible. I restarted my computer and i still can't reinstall it
r = static_cast<unsigned char>(l_vN.x*0.5f+0.5f);
g = static_cast<unsigned char>(l_vN.y*0.5f+0.5f);
b = static_cast<unsigned char>(l_vN.z*0.5f+0.5f);
so the flat color in 8bits will be (127,127,255)
You can change the background color, not the conversion itself.
Press over the "..." green buton near the "Generate Maps->Normal map" and change the background color.
Btw, why you want the 128 as flat color? If you give me a good technically-funded reason I can change the conversion mechanism.
I'm running into an issue when trying to bake my normals with xnormal... I keep getting these artifacts.
I thought it was an issue with the face not being uv mapped correctly.. I checked my UV and there arent any broken verts or anything. I did notice that when I selected one edge in UV space it highlighted two edges in the viewport:
I've been getting this bug for a while now.
Basically I set bake base texture color to black, but it always reverts back to red after restart / reloading bake settings.
I've been getting this bug for a while now.
Basically I set bake base texture color to black, but it always reverts back to red after restart / reloading bake settings.
Replies
Well, some advices:
1. Enable the "Show tangents" in the xN's 3D viewer to see if the UVs are well welded.
2. Render a "wireframe and ray fails map" to see if rays are failing or there are problems with your UVs.
3. Render the normal map as object space and see if the seam still appears.
4. Have you setup your cage in a way that covers completely the highpoly mesh?
5. Do you use Xoulil's max shader or the default one?
6. Don't use the max2obj exporter... Nevah!
7. Collapse + Edit mesh + ResetXForm ( + optionnally,Projection ) before exporting, always.
Last one was in xnormal 3d viewer and it still showed issue with seam. Have checked all you put. No difference. Should I send you files so you can test on your end?
1. Enable the "Show tangents" in the xN's 3D viewer to see if the UVs are well welded.
Showing tangents no issue.
2. Render a "wireframe and ray fails map" to see if rays are failing or there are problems with your UVs.
Nope all show
3. Render the normal map as object space and see if the seam still appears.
Attempted now and no the seam does not appear Only with your tangent render. Hence wondering if there is a bug.
4. Have you setup your cage in a way that covers completely the highpoly mesh?
Absolutely
5. Do you use Xoulil's max shader or the default one?
Default. But again inside xnormal itself showing same issue.
6. Don't use the max2obj exporter... Nevah!
Always use sbm
7. Collapse + Edit mesh + ResetXForm ( + optionnally,Projection ) before exporting, always.
Always reset and edit mesh.
http://www.oxynary.com/downloads/udk/export.7z
See your PM for the password
Was from Max 9. Normal map was +X -Y +Z (ie max normal).
You can see it via these tricks:
1. Assign a random VDM/normal map file(any pow2 texture file will work). Enable the "show vector displacement map's seams". UV seams are marked in red.
or
2. In 3dsmax, mark the conflictive faces. Then, place an UVW Unwrap modifier with the all the "show seams" options enabled. Seams will be marked in green.
or
3. Assign a normal map, enter the xN's viewer. Enable the "show tangent basis". If you see any point with more than one three-axis basis then there is a seam there. ( important: assign a normal map or you'll see only the blue lines, which correspond with the normals ).
or
4. Render a "wireframe and ray fails map". UV seams are marked in green ( try to render always at 2k x 2k to see them well ).
I hope it helps.
Keep up the good work.
Jogshy. I think there is a misunderstanding. Those seams are known and purposely made to uvw mirror. If you look at the max file I sent in fact the mirrored portions are off the uv space with the uv modifier in the stack. The issue is. Max correctly blends the island seams when it builds the normal map Xnormal is not. See below. The max normal map in xnormal displays fine. The Xnormal made map does not.
I also noticed this on a ball I created recently. Xnormal is not correctly blending these seams on uv islands.
If you want, if you can show me where I can download an earlier version of xnormal 3 from mid last year, I can see if it does the same. However, I dont believe Ive experienced this before. Im implying something I think there is a bug. Specifically with the tangent space renderer as the object space worked fine.
I don't see your UVs mirrored. There are not in range (-inf,0] or [1,+inf).
If there is a UV seam the light won't be continuous. Perhaps 3dsmax solves that using some black magic ( like auto UV-welding with very small threshold ), but if there is an UV seam there the logical and normal is to get a discontinuity in the lighting.
I'll review my code searching for a possible bug but I think and UV seam will be always an UV seam ! If you want to mitigate it just keep some space over the neighbor island and let the dilation filter to deal with it... but it won't be perfect neither.
Jogshy. No offense, but I see you went back and changed your answer. Your original was you were going to look over the code for tangent. As said Object worked fine in xnormal.
The UVs arent in range, they are outside the uv space purposely.. The issue is as you can see with your answer. If max is auto uv'ing welding. Why does it not show up in xnormal? Unless your stating the way max bakes the normals. If it did uv weld baking, that would have left a seam so wouldn't that have been more apparent?
Im also unsure this happened in the past, hence why if you can point me to your backlog of releases so I can test.
I apologize for that confusion, but now hopefully it should be apparent this is something with xnormal tangent burning of curved surfaces and islands.
http://www.oxynary.com/downloads/udk/merrygolowN.SBM
Edit. In fact, I have made a custom version of the normal map with two different layers so you can see the difference of how those are being burnt. If you click on the paths tab, it will give you the uv outlines to make it easier to discern.
http://www.oxynary.com/downloads/udk/merryGoN.7z
Pw is same as before.
Yep, I was thinking I was crazy for a moment
Cannot download your files currently but I'll do later.
thx
It's VERY hard to see it, because if you place an UVW Wrap modifier with the "show seams" options does not show unless you make a full zoom over the conflictive zone...
But see it, here is:
I simply welded the conflictive vertices/edges:
and no longer shows the light discontinuity in xNormal. You should also weld the edge on the left though ( those > and < edges )
I think the UV layout you use contains too many seams. If you don't need to sculpt each rail independently and you don't use object-space NMs, I suggest you to use an UV layout like this one:
There's no need to use more texture space for the plaform because the top and bottom part can share the TS.
I hope it helps.
I know seams will always have a seam, but again, I have proof positive that with xnormals own 3d viewer, the max ones are almost if not invisible while the xnormal ones are plain as day. Further, again, I have had this happen on circular objects. Which as you know there is no way to have a simple hidden seam.
Oh and the wasted space on the map is actually reserved for another object that I have (you can see in the normal map I sent).
I know my website was out part of last week, but if you go to the previous page you can see all the images I had posted along the way.
If you find an object causing seams in places without a seams please drop me a message.
Unfortunately I dont know what to tell you. The seam should not be that noticable.
I have this simple example here showing the issue is with the y/green channel.
Original Mesh
Max Viewport
Xnormal Viewport
Normal Maps
Max
Xnormal
File:
http://www.oxynary.com/downloads/udk/ball.7z
I attempted without a cage, stock tangent specs, expoted as an obj and still got similar results.
Problems with your hosting maybe, Jogshy?
Try the 3.17.2 Beta 3 pls. I've corrected a hang rendering the normals.
EDIT: Never mind, it's showing up for me now. Strange.
hey, just throwing this in between all the relevant tech stuff:
if you go crazy for xNormal and you are a facebook user too,
then you might want to join the unofficial xNormal appreciation group.
currently we are ~100 counting..
so see you there if you think xNormal is awesome!
[/trivia]
sorry for this little advert. but this group is just made for fun and i like to spread the word, nothing commercial. hope its no problem.
He definately means the edge padding like MightyPea said.
- Added support for Growl notifications.
- Optimized the software CPU rendering a 5% ( thx to new LR child heuristics ).
- The Optix renderer now uses a better sampling to reduce banding artifacts. Also improved sightly the performance.
- Solved some bugs in the displacement map computations with the MatchUV option enabled.
- Removed the dependency from the CUDA runtime DLL ( driver ftw! ).
- Fixed a bug in the xNormal's installer that was causing to abort the installation due to an incorrect .NET 2.0 detection under Windows 7.
- Reduced a bit more the xNormal's installer because the program no longer depends on the VS2005 SP1 runtime, the CUDA 3.0 DLL runtime and neither DX9.0c ( which is included in XP SP2 ).
- Solved some compatibility problems with OpenGL 3.2 in the Optix renderer.
- Solved a rare problem in the Default Bucket Renderer that could lead to slow/hang the render.
- Fixed a problem loading .DDS files with mipmapping ( affecting to the DDS image importer and the OpenGL/DX9/DX10 graphics drivers ).
- Solved a very-rare potential problem computing the tangent space for opposite faces.
- Fixed a problem in the OBJ mesh importer that could cause to use more RAM than should be used to load the objects.
- Recompiled using the latest libraries ( Optix 2.0 final, DX June 2010, etc... )
My workflow's been to decimate my meshes and bake them in Max, but while that works fine for normals, the curvature comes out horribly mangled and needs quite some fixing by hand:
It would be great if I could do these in Xnormal.
If you can explain it a bit more in depth ( what you need/want, what represents red/blue/green colors ) I can try again.
http://www.polycount.com/forum/showthread.php?t=74251&page=2
or you could ask rebb how he did it.
But, at the end, if you use a 8bits format like BMP or TGA then I convert it in this way:
Vector l_vN ( 0.0f, 0.0f, 1.0f );
unsigned char r, g, b;
r = static_cast<unsigned char>(l_vN.x*0.5f+0.5f);
g = static_cast<unsigned char>(l_vN.y*0.5f+0.5f);
b = static_cast<unsigned char>(l_vN.z*0.5f+0.5f);
so the flat color in 8bits will be (127,127,255)
You can change the background color, not the conversion itself.
Press over the "..." green buton near the "Generate Maps->Normal map" and change the background color.
Btw, why you want the 128 as flat color? If you give me a good technically-funded reason I can change the conversion mechanism.
I'm running into an issue when trying to bake my normals with xnormal... I keep getting these artifacts.
I thought it was an issue with the face not being uv mapped correctly.. I checked my UV and there arent any broken verts or anything. I did notice that when I selected one edge in UV space it highlighted two edges in the viewport:
How can I fix this? Thanks in advance.
Basically I set bake base texture color to black, but it always reverts back to red after restart / reloading bake settings.