Home Technical Talk

Official handplane support thread - Now freeware!!

1356789

Replies

  • imperator_dk
    Offline / Send Message
    imperator_dk polycounter lvl 10
    What are the options to extend handplane to support proprietary as in non public studio engines. Do you provide an sdk to create plugins ?
  • AlecMoody
    Offline / Send Message
    AlecMoody ngon master
    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.
  • Chase
    Offline / Send Message
    Chase polycounter lvl 9
    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.
  • jmonsterman
    Offline / Send Message
    jmonsterman polycounter lvl 10
    Which plugin do we use for Maya 2014? It's not recognized by the installer.
  • AlecMoody
    Offline / Send Message
    AlecMoody ngon master
    The 2014 plugin is coming soon along with an update to the code that detects channel and object orientation.
  • Obscura
    Offline / Send Message
    Obscura grand marshal polycounter
    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.
  • AlecMoody
    Offline / Send Message
    AlecMoody ngon master
    handplane v1.2 is out today. The major changes are to the code that automatically selects the correct channel and object orientation for you lowpoly.

    Also, a Maya 2014 plugin has been added to the installer.

    http://www.handplane3d.com/handplane_v1.2.rar
  • joeriv
    Offline / Send Message
    joeriv polycounter lvl 7
    I am running into a bit of a problem, probably something silly, but I can't seem to figure it out.

    baked in max with localXYZ.
    tried with both obj/fbx exports.

    bakecolor.jpg
  • AlecMoody
    Offline / Send Message
    AlecMoody ngon master
    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?
  • joeriv
    Offline / Send Message
    joeriv polycounter lvl 7
    AlecMoody wrote: »
    *A different set of shells have been used for overlapping geometry during bake and tangent space creation.

    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 ^^
  • Obscura
    Offline / Send Message
    Obscura grand marshal polycounter
    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?
    67993351.jpg
  • AlecMoody
    Offline / Send Message
    AlecMoody ngon master
    That highlight is part of a cubemap reflection wrapping around the edge- its not related to smoothing splits.
  • Obscura
    Offline / Send Message
    Obscura grand marshal polycounter
    AlecMoody wrote: »
    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.
  • AlecMoody
    Offline / Send Message
    AlecMoody ngon master
    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.
  • Obscura
    Offline / Send Message
    Obscura grand marshal polycounter
    Sure, in a few minutes, I just need to copy/attach the mesh, and rebake it, because I used the same mesh first, and modified that when I tested this.
  • Obscura
    Offline / Send Message
    Obscura grand marshal polycounter
    Here they are:
    UDK
    alec2d.jpg
    alec4.jpg
    Uvs
    alec1c.jpg
    And the tangent space normalmap that I got after using Handplane
    alec3y.jpg
  • AlecMoody
    Offline / Send Message
    AlecMoody ngon master
    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.
  • Obscura
    Offline / Send Message
    Obscura grand marshal polycounter
    Very subtle?!...they are hard edges.
  • doc rob
    Offline / Send Message
    doc rob polycounter lvl 19
    Draw some red circles around the problem areas and try describing it again. Whatever your issue is, it's not obvious.
  • Obscura
    Offline / Send Message
    Obscura grand marshal polycounter
    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.

    - Its possible that is synced, but not with UDK
  • ZacD
    Offline / Send Message
    ZacD ngon master
    It isn't perfectly synced with UDK because Epic has not worked with anyone to properly sync their normal maps.
  • Obscura
    Offline / Send Message
    Obscura grand marshal polycounter
    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.
  • Obscura
    Offline / Send Message
    Obscura grand marshal polycounter
    Well, thank you for your reply, this was what I was wanted to make sure.
  • EarthQuake
    Obscura wrote: »
    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.
  • Obscura
    Offline / Send Message
    Obscura grand marshal polycounter
    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.
  • radiancef0rge
    Offline / Send Message
    radiancef0rge ngon master
    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?
  • AlecMoody
    Offline / Send Message
    AlecMoody ngon master
    Obscura wrote: »
    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.
  • Obscura
    Offline / Send Message
    Obscura grand marshal polycounter
    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:
    examplesabouthandplane2.jpg
    There are not too much differences between with Handplane/Without Handplane

    And in Max:
    examplesabouthandplanes.jpg
    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.
  • ZacD
    Offline / Send Message
    ZacD ngon master
    Try turning off the compression on the normal map, using the defer compression option. http://d2d04grx5ahzvh.cloudfront.net/000_QuickTips/038_UDK_Optimizing_Textures/Lods_settings.jpg
  • Obscura
    Offline / Send Message
    Obscura grand marshal polycounter
    AlecMoody wrote: »
    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.

    I can edit, If you want that.
  • AlecMoody
    Offline / Send Message
    AlecMoody ngon master
    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
  • Obscura
    Offline / Send Message
    Obscura grand marshal polycounter
    ZacD - Thanks, I tried, but its not changing too much things. There are still hard edges and shading problems.
  • Farfarer
    Obscura wrote: »
    - 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.
  • Obscura
    Offline / Send Message
    Obscura grand marshal polycounter
    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.

    Thank you all anyways!
  • AlecMoody
    Offline / Send Message
    AlecMoody ngon master
    Hi all,
    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.
  • warby
    Offline / Send Message
    warby polycounter lvl 18
    i am having an issue with a shading error in the center of my model could hardplane be used to fix this:

    972043_10151492586329285_2089879574_n.jpg

    i am here all week :D
  • Quack!
    Offline / Send Message
    Quack! polycounter lvl 17
    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?
  • Farfarer
    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.
  • Quack!
    Offline / Send Message
    Quack! polycounter lvl 17
    Farfarer wrote: »
    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.
  • Farfarer
    100% sure.

    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!
    Offline / Send Message
    Quack! polycounter lvl 17
    Perfect! I think that can be the rumor that you don't need to use cages with Handplane can be layed to rest. Thanks for clearing that up James.
  • AlecMoody
    Offline / Send Message
    AlecMoody ngon master
    Quack! wrote: »
    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.
  • AlecMoody
    Offline / Send Message
    AlecMoody ngon master
    Obscura wrote: »
    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:
    examplesabouthandplane2.jpg
    There are not too much differences between with Handplane/Without Handplane

    And in Max:
    examplesabouthandplanes.jpg
    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!
    Offline / Send Message
    Quack! polycounter lvl 17
    AlecMoody wrote: »
    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.
  • Computron
    Offline / Send Message
    Computron polycounter lvl 7
    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:
    B32dUrN.png

    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...
  • Bek
    Offline / Send Message
    Bek interpolator
    I think dDo takes into account that your ts nm will be different from your os nm? It uses OS for direction based details mostly I believe.
  • Computron
    Offline / Send Message
    Computron polycounter lvl 7
    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.
  • Bek
    Offline / Send Message
    Bek interpolator
    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?
  • Computron
    Offline / Send Message
    Computron polycounter lvl 7
    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
  • Bek
    Offline / Send Message
    Bek interpolator
    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?)
1356789
Sign In or Register to comment.