We don't have an SDK but if there are any studios looking for this we are more than happy to put together a private build with a custom TB output. The documentation requirements can be narrowed down to small snippets of very mundane code so there is very little exposure of proprietary information.
Hey Alec, can I send you what I have written up about normal maps and Handplane. It's by no means a 100% how to guide. I know normal map confusion runs rampant which is why I think what I have quickly written up could help shed some light. I know I'm far from being a pro at this stuff, but anything I could do to save someone else extra time and headaches would be great. Just let me know if you'd want to read it at your leisure.
Hi, I experienced something interesting. I tried out handplane with both one sg and sgs based on the uvs, and I got strange result in UDK. The one that is using sgs based on the uvs, are still totally hard edged from close, and the one that is using one sg is a little better, because it has hard edges only along the uv borders. Why is that?
*I also tried resetting xform and triangulating my mesh before baking, but I got the same results.
Hi Joe,
Email me a max scene along with your object space map and I will take a look. alecmoody@gmail.com
Typically this happens when either:
*the highpoly model has inverted normals at time of bake
*A different set of shells have been used for overlapping geometry during bake and tangent space creation.
Another easy test, how does the model look in the viewport using an object space normal map?
Another question. The marked areas looks hard edged to me because the specular is breaking so hard. How is that? After using handplane, the hard edges still hard edges?
That highlight is part of a cubemap reflection wrapping around the edge- its not related to smoothing splits.
Looks hard edges to me, but okay, lets say its because of the cubemap. And what about my previous post? Where I talk about the results that I got in udk, with different setups. Why I got hard edges, when I used uv splits and smoothing splits, and why I got hard edges only along the uv borders, when I used one smoothing group and one uv shell? Its a simple angular U shaped mesh by the way.
Can you post pictures? I am having a hard time understanding what is happening in UDK. Also, that 3dsmax viewport shot you linked to has no hard edges.
I'm still not understanding what the problem or question is exactly. Is it the very subtle break in the shading you can see where there are smoothing breaks? That is just how normal mapping works. You are combining two sets of data with totally different numerical representations and resolutions.
Lol, sorry but I can't really believe that you are not seeing the hard edges. And my problem is the hard edges. If I don't use Handplane, and I using multiple sgs based on the uvs, I get almost the same result, so then why I would have to use Handplane? It not looks 100% synced to me, because its not solving the hard edges, and also not gives perfect result with one sg. To me, this means its not doing enough good job. 3dsmax viewport gives perfect result, the sgs/uvs are not matters at all. Same with its offline renderer. I know its offline, but its not matters. So after all of that, if something is synced, then it needs to give perfect result with every method.
Sorry if these are harsh words, but this is what I see.
And honestly...Using hard edges to controlling the bad shading? Then the whole Highpoly modeling is loosing its importance. Then you can use simple hard edged lowpoly meshes, and floating highpoly elements that you can bake. I know why this "solution" is here, but its not a solution to me.
Lol, sorry but I can't really believe that you are not seeing the hard edges. And my problem is the hard edges.
The hard edge artifacts I see here look like they are from low resolution dynamic or baked shadows.
If I don't use Handplane, and I using multiple sgs based on the uvs, I get almost the same result, so then why I would have to use Handplane?
Thats the whole point. Try the same test without using handplane. The result without any smoothing splits/hard edges will look MUCH WORSE if you didn't use handplane. So if it looks the same smoothed or split, this is a sign handplane is doing what it is designed to do. This means you can use less uv seams to make texture painting easier, and generally have less technical crap you need to worry about because of broken tangents. This saves a huge amount of time tweaking things to look good in production.
It not looks 100% synced to me, because its not solving the hard edges, and also not gives perfect result with one sg. To me, this means its not doing enough good job. 3dsmax viewport gives perfect result, the sgs/uvs are not matters at all. Same with its offline renderer. I know its offline, but its not matters. So after all of that, if something is synced, then it needs to give perfect result with every method.
Sorry if these are harsh words, but this is what I see.
- Its possible that is synced, but not with UDK
Again, your issues look to me like they stem from shadowing problems. Try disabling shadows and lightmaps to take that out of the equation.
Well, this is what Alec said:
"UDK has some limitations which cannot be overcome. The engine throws away render precisions and it is not possible to produce a normal map that can compensate for this. handplane's output is synced, in that the tangents are generated and interpolated the same way UDK renders, it just isn't possible to create a perfect output. This is made clear several times in the thread, along with images showing the output for unreal."
So its not because of the shadows (they are dynamic btw).
I made a lot of tests with different models, smoothing, uv's, etc. Yes, the ones that are using one sg are looks worse without Handplane, but the ones that are using smoothing splits+uv splits are looks almost the same. But my model that is using one sg have hard edges along the uv borders after using Handplane. I just saying its not giving that perfect result that any of the 3dsmax's SYNCED renderers would give.
So as opposed to claiming the thing is broken and useless perhaps showing an alternative that produces better results will result in a learning experience for all of us. I dont see any hard edges btw, I see normal mapped edge.
Can we see what it looks like in max because its perfect?
Well, this is what Alec said:
"UDK has some limitations which cannot be overcome. The engine throws away render precisions and it is not possible to produce a normal map that can compensate for this. handplane's output is synced, in that the tangents are generated and interpolated the same way UDK renders, it just isn't possible to create a perfect output. This is made clear several times in the thread, along with images showing the output for unreal."
So its not because of the shadows (they are dynamic btw).
I made a lot of tests with different models, smoothing, uv's, etc. Yes, the ones that are using one sg are looks worse without Handplane, but the ones that are using smoothing splits+uv splits are looks almost the same. But my model that is using one sg have hard edges along the uv borders after using Handplane. I just saying its not giving that perfect result that any of the 3dsmax's SYNCED renderers would give.
In the future, please don't transpose the contents of a private message onto the forum. Had I written that for the public it would have been phrased differently and I would have included a few more qualifying statements.
So as opposed to claiming the thing is broken and useless perhaps showing an alternative that produces better results will result in a learning experience for all of us. I dont see any hard edges btw, I see normal mapped edge.
Can we see what it looks like in max because its perfect?
You must be joking with me...Its clearly visible. Anyway, here are my last examples, now with/without Handplane.
The results speak for themselves...
UDK:
There are not too much differences between with Handplane/Without Handplane
And in Max:
Yes, the seams are visible a little, but this is what I would call "very subtle break". So, now everybody can see the differences. I hope that this is enough. I stop posting my tests here, because I finished the testing.
- Oh and, if something is synced, then its working good with one or more sgs, but I think that this is visible on my picture that made in Max.
In the future, please don't transpose the contents of a private message onto the forum. Had I written that for the public it would have been phrased differently and I would have included a few more qualifying statements.
Obscura,
If you are comparing handplane's output to xnormal + import tangent and explicit normals then the results will be nearly identical. The reason the handplane output exists is that it works with skeletal meshes and currently UDK does not allow for importing tangents and normals for skeletal meshes. This thread from the beta has some good information for you: http://www.polycount.com/forum/showthread.php?t=108744&highlight=handplane
- Oh and, if something is synced, then its working good with one or more sgs, but I think that this is visible on my picture that made in Max.
If something is synced, then it uses the same maths and values to convert to tangent space when baking as it does when rendering. Smoothing groups have nothing to do with it.
Also, if you're going to test normal maps, you should turn everything off except the normal maps (disable the SSAO and everything else), ensure that the normal maps are uncompressed, etc... Basically give it the best possible chance to be the highest quality possible.
If it doesn't work then, then there's an issue with Handplane (and, in the case of UDK it's a known and acknowledged issue). Otherwise you're simply asking too much of your normal map and you need to help it out with better smoothing or more geometry.
Ultimately, if it's that big an issue for you, don't use Handplane.
Don't worry, I will not. Because its not really helping me with UDK. I can get almost the same result without it (especially with the hard edged method) and I can placing more edges easily.
This question has come up a lot and I would love some clarification. The way we baked before handplane, required a cage to get the best results. However it seems many are under the impression that handplane removes the need for a cage.
The question for Alec: when using handplane, is a cage needed to bake the object space maps for handplane to convert to achieve the best results? Or does ray distance achieve the same effect?
Ray distance is the same as projecting out along the vertex normals. Imagine a cage that's projected out along the vertex normals for that distance - same thing.
So if you've got hard or split edges, then you're going to have the same problems you would get if you were baking any kind of map - tangent space, object space, AO or anything else... (i.e. the cage splits and you end up missing or duplicating bake data from the high poly mesh along that split).
If you have no hard or split edges, the result of using ray distance is similar to using an "averaged normals" cage, where it projects that distance along the vertex normals (as if there were no smoothing splits). This means you don't get gaps in your bake where it's missed high res details. You might still get "waviness" in areas where a properly edited cage would reduce the effect.
So, ray distance has the same effect as a cage that's projected out that distance only if you have no smoothing splits. Any issues with the object space bake will carry over to the result from handplane - all Handplane does is convert the object space map to a tangent space map synced to the target engine - it's result can only be as good as the object space map you feed into it.
Ray distance is the same as projecting out along the vertex normals. Imagine a cage that's projected out along the vertex normals for that distance - same thing.
So if you've got hard or split edges, then you're going to have the same problems you would get if you were baking any kind of map - tangent space, object space, AO or anything else... (i.e. the cage splits and you end up missing or duplicating bake data from the high poly mesh along that split).
If you have no hard or split edges, the result of using ray distance is similar to using an "averaged normals" cage, where it projects that distance along the vertex normals (as if there were no smoothing splits). This means you don't get gaps in your bake where it's missed high res details. You might still get "waviness" in areas where a properly edited cage would reduce the effect.
So, ray distance has the same effect as a cage that's projected out that distance only if you have no smoothing splits. Any issues with the object space bake will carry over to the result from handplane - all Handplane does is convert the object space map to a tangent space map synced to the target engine - it's result can only be as good as the object space map you feed into it.
Thanks for the response James. Glad we can have this discussion with more then 140 characters, heh.
To play devils advocate, are you 100% sure that object space projection has the same cage issues as tangent space, or is this an assumption? It makes sense that it would, but just want to get all the facts on the table.
In your 3D app, when you bake a tangent space map, it actually bakes an object space map and then converts that to a tangent space map using your 3D app's tangent basis.
It's just that Handplane takes the place of this last step and converts the object space map to a tangent space map using your choice of tangent basis.
This question has come up a lot and I would love some clarification. The way we baked before handplane, required a cage to get the best results. However it seems many are under the impression that handplane removes the need for a cage.
The question for Alec: when using handplane, is a cage needed to bake the object space maps for handplane to convert to achieve the best results? Or does ray distance achieve the same effect?
Quack,
You still need an averaged projection. The root of that "no need to use a cage with handplane" is based on baking in xnormal (and in that case it is true). With xnormal, if you are using smoothing splits, you must use a cage to get an averaged projection. When you use handplane, you can set xnormal to average your lowpoly mesh on import. This has the side effect of eliminated all projection splitting, thus creating an averaged projection and negating the need to use a cage. You can't do this with a standard baking workflow because averaging the lowpoly mesh normals would totally break the tangent space output. With handplane projection and tangent space generation are decoupled.
You must be joking with me...Its clearly visible. Anyway, here are my last examples, now with/without Handplane.
The results speak for themselves...
UDK:
There are not too much differences between with Handplane/Without Handplane
And in Max:
Yes, the seams are visible a little, but this is what I would call "very subtle break". So, now everybody can see the differences. I hope that this is enough. I stop posting my tests here, because I finished the testing.
- Oh and, if something is synced, then its working good with one or more sgs, but I think that this is visible on my picture that made in Max.
Obscura,
Please post your import settings for the object when it is being used both with and without the handplane output. It would appear you are misunderstanding the functionality with unreal. hanplane's unreal output will look 99.9% the same as a map baked in xnormal using the import tangent/explicit normals workflow. This is the best unreal is capable of. The advantage to using handplane with udk is that you can get that same quality with skeletal meshes (import tangent/explicit normals currently only supports static meshes). In practice, most baked assets are skeletal meshes so this ends up being very useful (weapons, vehicles, anything rigged props). If you had been working with unreal bakes for the last few years, prior to the import tangents option, and even prior to the explicit normals option, you would understand how hugely improved your example image is over how unreal used to look (and skeletal meshes still look).
There are of course, many other workflow benefits to using handplane, aside from reducing shading errors in your normal maps.
Quack,
You still need an averaged projection. The root of that "no need to use a cage with handplane" is based on baking in xnormal (and in that case it is true). With xnormal, if you are using smoothing splits, you must use a cage to get an averaged projection. When you use handplane, you can set xnormal to average your lowpoly mesh on import. This has the side effect of eliminated all projection splitting, thus creating an averaged projection and negating the need to use a cage. You can't do this with a standard baking workflow because averaging the lowpoly mesh normals would totally break the tangent space output. With handplane projection and tangent space generation are decoupled.
Gah! The xnormal part slipped my mind when the discussion was happening. Thanks for the (re) clarification.
It would be awesome if the next version of handplane included a feature that would allow you to convert tangent space maps back into world space maps.
Why would you need this feature?
Say, for example, I needed to add details to my tangent space map in a program such as nDo2, like the knurling on the grip of my gun:
When I finish adding the detial in nDo2 and I want to move on to dDo, I will need to import both of my normal maps. (dDo needs both a World Space and a tangent space map to use all the features) However, since I can only edit my tangent space map in nDo, my world space normal maps will not match.
It would be great if I could feed my final (nDo2 adjusted) tangent space normal map back into handplane and get a world space normals map that matches.
I believe xNormal has a feature like this, however I don't think it will give a synced tangent basis...
I'm not sure what you mean by "takes into account," I don't think it does. Besides, how would it?
In quixels last dDo tutorial they added nDo2 details and converted the tangent space map back to world space using xNormal, so I don't think they would have such a feature if they are showing this kind of a workaround.
Haven't seen that video, I was basing my guess off when I was mucking around with the trial. Just run a test with an unedited OS nm and nDo's ts nm, see if you have any issues?
Another thought is why do you need the OS map to be synced? You're not going to be using it in your target engine are you? If it's just for use with dDo's detail presets I don't see a problem?
I think we are talking about two different thing here. I'm not sure.
Another thought is why do you need the OS map to be synced?
Are you saying this in the sense that the OS normals map is using a synced tangent space? That wouldn't make sense, because OS normals maps replace the normals entirely, they aren't deriveing tangents or anything. By definition they can't be "synced" or not.
My thought was that if I were to convert my handplane-generated-nDo2-edited tangent space normals map back to a OS/WS normals map with xNormal, it wouldn't calculate the correct OS normals because its tangent space doesn't match handplane's.
Therefore, What I want is the ability for handplane to do this conversion so that I can generate an object/world-space map that has all the details, or "matches" all the features that I add in nDo 2 in my tangent space map (Because nDo2 only allows works with tangent space map). This way, if I add a lot of details in nDo2, I can have those details take advantage of the World space oriented dDo filters/details rather then be ignored as if they aren't even there. Hopefully that makes sense
Yeah sorry by synched I meant "matched" as you said in your original post, I wasn't very clear in writing that.
Do you mean that because your ts nm is not in xNormal's tangent basis, that any conversion of that map though xN will be flawed because of this mismatch? For what you're using the ts-to-os map for (dDo) it doesn't seem like it would matter? As an example, the Mud filter in dDo uses the direction from the OS NM correct? Since the details added by nDo aren't going to be large forms, are there any filters that you would actually want to take the nDo details into account?
Basically I'm thinking:
1) Does it actually matter that the OS map in dDo has your nDo details or not? (I would assume no but test the specific case you're working with)
2) If yes, does it matter that the ts map converted by xN to os 'matches' the ts nm. (Ie will the mismatch cause any problems in the final outputs from dDo? I would assume no, but again why not just test it?)
Replies
*I also tried resetting xform and triangulating my mesh before baking, but I got the same results.
Also, a Maya 2014 plugin has been added to the installer.
http://www.handplane3d.com/handplane_v1.2.rar
baked in max with localXYZ.
tried with both obj/fbx exports.
Email me a max scene along with your object space map and I will take a look.
alecmoody@gmail.com
Typically this happens when either:
*the highpoly model has inverted normals at time of bake
*A different set of shells have been used for overlapping geometry during bake and tangent space creation.
Another easy test, how does the model look in the viewport using an object space normal map?
after doublechecking that, the export was a older version with a overlapped piece, after fixing that it comes out fine
thanks for the quick help ^^
Looks hard edges to me, but okay, lets say its because of the cubemap. And what about my previous post? Where I talk about the results that I got in udk, with different setups. Why I got hard edges, when I used uv splits and smoothing splits, and why I got hard edges only along the uv borders, when I used one smoothing group and one uv shell? Its a simple angular U shaped mesh by the way.
UDK
Uvs
And the tangent space normalmap that I got after using Handplane
Sorry if these are harsh words, but this is what I see.
- Its possible that is synced, but not with UDK
The hard edge artifacts I see here look like they are from low resolution dynamic or baked shadows.
Thats the whole point. Try the same test without using handplane. The result without any smoothing splits/hard edges will look MUCH WORSE if you didn't use handplane. So if it looks the same smoothed or split, this is a sign handplane is doing what it is designed to do. This means you can use less uv seams to make texture painting easier, and generally have less technical crap you need to worry about because of broken tangents. This saves a huge amount of time tweaking things to look good in production.
Again, your issues look to me like they stem from shadowing problems. Try disabling shadows and lightmaps to take that out of the equation.
"UDK has some limitations which cannot be overcome. The engine throws away render precisions and it is not possible to produce a normal map that can compensate for this. handplane's output is synced, in that the tangents are generated and interpolated the same way UDK renders, it just isn't possible to create a perfect output. This is made clear several times in the thread, along with images showing the output for unreal."
So its not because of the shadows (they are dynamic btw).
I made a lot of tests with different models, smoothing, uv's, etc. Yes, the ones that are using one sg are looks worse without Handplane, but the ones that are using smoothing splits+uv splits are looks almost the same. But my model that is using one sg have hard edges along the uv borders after using Handplane. I just saying its not giving that perfect result that any of the 3dsmax's SYNCED renderers would give.
Can we see what it looks like in max because its perfect?
In the future, please don't transpose the contents of a private message onto the forum. Had I written that for the public it would have been phrased differently and I would have included a few more qualifying statements.
You must be joking with me...Its clearly visible. Anyway, here are my last examples, now with/without Handplane.
The results speak for themselves...
UDK:
There are not too much differences between with Handplane/Without Handplane
And in Max:
Yes, the seams are visible a little, but this is what I would call "very subtle break". So, now everybody can see the differences. I hope that this is enough. I stop posting my tests here, because I finished the testing.
- Oh and, if something is synced, then its working good with one or more sgs, but I think that this is visible on my picture that made in Max.
I can edit, If you want that.
If you are comparing handplane's output to xnormal + import tangent and explicit normals then the results will be nearly identical. The reason the handplane output exists is that it works with skeletal meshes and currently UDK does not allow for importing tangents and normals for skeletal meshes. This thread from the beta has some good information for you:
http://www.polycount.com/forum/showthread.php?t=108744&highlight=handplane
Also, if you're going to test normal maps, you should turn everything off except the normal maps (disable the SSAO and everything else), ensure that the normal maps are uncompressed, etc... Basically give it the best possible chance to be the highest quality possible.
If it doesn't work then, then there's an issue with Handplane (and, in the case of UDK it's a known and acknowledged issue). Otherwise you're simply asking too much of your normal map and you need to help it out with better smoothing or more geometry.
Ultimately, if it's that big an issue for you, don't use Handplane.
Thank you all anyways!
Is anyone out there using handplane with blender? If so I would like to hear from you:
alecmoody@gmail.com
Also, anyone working with the source output? Drop me a line if you are.
i am here all week
The question for Alec: when using handplane, is a cage needed to bake the object space maps for handplane to convert to achieve the best results? Or does ray distance achieve the same effect?
So if you've got hard or split edges, then you're going to have the same problems you would get if you were baking any kind of map - tangent space, object space, AO or anything else... (i.e. the cage splits and you end up missing or duplicating bake data from the high poly mesh along that split).
If you have no hard or split edges, the result of using ray distance is similar to using an "averaged normals" cage, where it projects that distance along the vertex normals (as if there were no smoothing splits). This means you don't get gaps in your bake where it's missed high res details. You might still get "waviness" in areas where a properly edited cage would reduce the effect.
So, ray distance has the same effect as a cage that's projected out that distance only if you have no smoothing splits. Any issues with the object space bake will carry over to the result from handplane - all Handplane does is convert the object space map to a tangent space map synced to the target engine - it's result can only be as good as the object space map you feed into it.
Thanks for the response James. Glad we can have this discussion with more then 140 characters, heh.
To play devils advocate, are you 100% sure that object space projection has the same cage issues as tangent space, or is this an assumption? It makes sense that it would, but just want to get all the facts on the table.
In your 3D app, when you bake a tangent space map, it actually bakes an object space map and then converts that to a tangent space map using your 3D app's tangent basis.
It's just that Handplane takes the place of this last step and converts the object space map to a tangent space map using your choice of tangent basis.
Quack,
You still need an averaged projection. The root of that "no need to use a cage with handplane" is based on baking in xnormal (and in that case it is true). With xnormal, if you are using smoothing splits, you must use a cage to get an averaged projection. When you use handplane, you can set xnormal to average your lowpoly mesh on import. This has the side effect of eliminated all projection splitting, thus creating an averaged projection and negating the need to use a cage. You can't do this with a standard baking workflow because averaging the lowpoly mesh normals would totally break the tangent space output. With handplane projection and tangent space generation are decoupled.
Obscura,
Please post your import settings for the object when it is being used both with and without the handplane output. It would appear you are misunderstanding the functionality with unreal. hanplane's unreal output will look 99.9% the same as a map baked in xnormal using the import tangent/explicit normals workflow. This is the best unreal is capable of. The advantage to using handplane with udk is that you can get that same quality with skeletal meshes (import tangent/explicit normals currently only supports static meshes). In practice, most baked assets are skeletal meshes so this ends up being very useful (weapons, vehicles, anything rigged props). If you had been working with unreal bakes for the last few years, prior to the import tangents option, and even prior to the explicit normals option, you would understand how hugely improved your example image is over how unreal used to look (and skeletal meshes still look).
There are of course, many other workflow benefits to using handplane, aside from reducing shading errors in your normal maps.
Gah! The xnormal part slipped my mind when the discussion was happening. Thanks for the (re) clarification.
Why would you need this feature?
Say, for example, I needed to add details to my tangent space map in a program such as nDo2, like the knurling on the grip of my gun:
When I finish adding the detial in nDo2 and I want to move on to dDo, I will need to import both of my normal maps. (dDo needs both a World Space and a tangent space map to use all the features) However, since I can only edit my tangent space map in nDo, my world space normal maps will not match.
It would be great if I could feed my final (nDo2 adjusted) tangent space normal map back into handplane and get a world space normals map that matches.
I believe xNormal has a feature like this, however I don't think it will give a synced tangent basis...
In quixels last dDo tutorial they added nDo2 details and converted the tangent space map back to world space using xNormal, so I don't think they would have such a feature if they are showing this kind of a workaround.
Another thought is why do you need the OS map to be synced? You're not going to be using it in your target engine are you? If it's just for use with dDo's detail presets I don't see a problem?
Are you saying this in the sense that the OS normals map is using a synced tangent space? That wouldn't make sense, because OS normals maps replace the normals entirely, they aren't deriveing tangents or anything. By definition they can't be "synced" or not.
My thought was that if I were to convert my handplane-generated-nDo2-edited tangent space normals map back to a OS/WS normals map with xNormal, it wouldn't calculate the correct OS normals because its tangent space doesn't match handplane's.
Therefore, What I want is the ability for handplane to do this conversion so that I can generate an object/world-space map that has all the details, or "matches" all the features that I add in nDo 2 in my tangent space map (Because nDo2 only allows works with tangent space map). This way, if I add a lot of details in nDo2, I can have those details take advantage of the World space oriented dDo filters/details rather then be ignored as if they aren't even there. Hopefully that makes sense
Do you mean that because your ts nm is not in xNormal's tangent basis, that any conversion of that map though xN will be flawed because of this mismatch? For what you're using the ts-to-os map for (dDo) it doesn't seem like it would matter? As an example, the Mud filter in dDo uses the direction from the OS NM correct? Since the details added by nDo aren't going to be large forms, are there any filters that you would actually want to take the nDo details into account?
Basically I'm thinking:
1) Does it actually matter that the OS map in dDo has your nDo details or not? (I would assume no but test the specific case you're working with)
2) If yes, does it matter that the ts map converted by xN to os 'matches' the ts nm. (Ie will the mismatch cause any problems in the final outputs from dDo? I would assume no, but again why not just test it?)