The locking normals thing is important if you're baking in Maya, as like Alec said, if you have a lowpoly mesh that is a mix of quads/tris/ngons, and bake from that, and then triangulate your mesh normals change and that will cause smoothing errors. So you can triangulate before baking, or your can lock normals after baking but before triangulating and sending your mesh off to your engine.
If you're baking in XN and not triangulating, you don't really have to worry about that, but beware that you're now counting on 3 different apps to triangulate your mesh exactly the same. Also, if you're baking in XN, again like Alec mentioned, you're no longer synced to maya normals.
So, baking object space in XN and converting to Maya tangents would seem to be a very good workflow for you guys, considering how reliant on XN you currently are, and how annoying it is exporting very dense meshes from Z/Mud into Maya to bake.
However, you've really got to make sure your entire pipeline is synced up, and that the results when you bake a mesh in Maya show up the same in your game engine as well. Otherwise handplane isn't really going to help.
So again, I would suggest taking some relatively complex asset, softening the normals for it, baking it in Maya and exporting it to your game engine. If you get the same shading quality in game as you do in engine, hooray, your tangents are synced! If you don't, there could be a number problems along the way, include how tangents are handled by the shader/renderer, triangulation issues, and how the mesh is imported into your engine.
Just to clarify- if you are using handplane with the h3d format you don't need to worry about locking normals until you are actually sending objects into your game. If you aren't using handplane (or baking normals inside maya), joes suggestion is best. At that point it is just a matter of how smart your engine is about maya stuff (and it matters if you are using a format that can send triangle directions- fbx for maya can't).
Yeah, the locking normals stuff I do has nothing to do with handplane, I do it when I'm baking something in Maya and sending it directly to an engine that is synced to Maya.
Alec and Luke put a lot of thought into how handplane works, so artists don't have to bother with knowing all of these little work arounds.
Not sure I see the point of locking the normals, you are doing this because you don't trust the export process to keep the triangulation the same once the pipeline converts it to game format? We have our own custom pipeline and render engine/file format so we should be able to match this up exactly with Maya if it isn't already.
Here is the test I'll have the guys do, please check for sanity.
1.
-Bake high to low normal map in Maya, low poly 180 soft normals.
-Export to game, check consistency in shading between VP 2.0 and game render.
-If shading is different in game try locking normals after baking and send to game, see if it fixes the issue.
-If shading looks correct with locked normals then we will know the mesh is getting triangulated somewhere after it leaves Maya.
2.
-Bake high to low in xNormal, low poly 180 soft normals.
-Comepare normal maps in VP 2.0.
-If they look different try baking object space normal map and using handplane to output Maya map.
3.
-I want to avoid triangulated models all together, surely we can find a way to get the pipeline export to triangulate the mesh the same way Maya would do it.
Not sure I see the point of locking the normals, you are doing this because you don't trust the export process to keep the triangulation the same once the pipeline converts it to game format?
Again, if you triangulate your mesh in Maya after you bake, the mesh normals change. So if you're baking in Maya and triangulating in Maya before export, you should lock your mesh normals.
If you're triangulating somewhere else, like on load, then you just need to make sure your mesh normals aren't being changed when it triangulates, normally this doesn't happen but its something Maya does when you go to Mesh -> Triangulate. Do a quick test bake in Maya with a mesh that has quads, preview it in the Maya viewport and triangulate the mesh, it will be visibly obvious what the issue is. Then undo it, lock your normals first, and do it again.
If triangulation in Maya before export is not part of your workflow, its not something you need to worry or even think about.
If you're doing Maya -> Xnormal Object Space -> Handplane w/ Maya tangents -> Game, the only thing you need to be sure of is that your mesh normals and triangulation match up in the mesh you load into handplane, and the mesh that gets loaded into engine(and that your engine is synced to Maya tangents of course).
I simulated your workflow for Maya/Xnormal/Handplane and can clearly see how this saves time, since no rebakes are required each time the mesh gets edited.
The Handplane web site also says that Handplane can create lower vertex count assets, improve shading quality and fix projection errors. I realize that artists can employ a variety of tricks and techniques to achieve better results. It's unclear to me though, what specific features of Handplane can produce these improved results - and how. Do you have any examples? (the Maya/Xnormal/Handplane video was a great example for showing how Handplane can save time)
Here's a weird one. I was getting unexpected end of file errors in photoshop from the rendered hand plane normal map. It only happens if I render a non square map, ie 512*1024, and it only happens if the output is tga. I tested a bmp and png output and they open fine.
I have to say though this is an awesome tool and I hope to see tangent space to object space conversion soon.
tangent to object (or just tangnet to tangent) is something I would like to do. It wouldn't be hard to implement but there are serious limitations around the quality of the tangent space map being converted. I would expect that old dds compressed tangent space normals will not convert well. Also, any inaccuracy in our tangent space calculations will get compounded because of the double conversion. In practice, most people have max, maya, or xnormal maps- our max and maya tangent basis are the most solid so it would probably work very well. We don't have an xnormal TB but we could look at adding it (for output it isn't particularly useful since no engines actually use xnormal's mikkspace TB).
I don't generally bake in zbrush or mudbox. Does anyone know if the maps out of both tools are X+ Y+ Z+? We are adding them to the "Baked in" menu to eliminate some confusion. handplane already accepts these maps and automatically figures out what to do with them but I had several questions about if mudbox or zbrush OS maps will work.
Hi everyone,
We just finished testing an update for handplane v1.1. There are some bug fixes along with one major simplification of workflow. We have added a new option for "baked in" that automatically detects how your object space map is oriented. This should reduce confusion. I am suggesting that everyone use this option instead of any of the listed baking tools in the drop down. Also, I wanted to point out that handplane will accept any object space map, even from applications that aren't listed.
v1.1 changes:
Fixed crash when right click closing from the task bar.
Fixed crash in obj file reader when negative indices were used.
Fixed output of non-square tga textures.
Fixed overwriting input image file when no suffix was specified.
Added auto detect setting to 'Baked In' option. This is now default.
Added mudbox and zbrush to 'Baked In' option.
Thanks for the info. What exactly do you mean by "synced normals?" I can't seem to find much info on this subject.
Also, the video is great at explaining the various modeling/smoothing/UVing techniques and options to control shading behavior, but I still didn't see in this video how Handplane specifically improves shading
Thanks for the info. What exactly do you mean by “synced normals?” I can’t find much info on this subject. Also, the video is excellent at explaining how modeling/smoothing/UVing techniques can control shading behavior, but it’s still unclear to me in this video how Handplane specifically improves the shading.
Oh man that video was great! I can't wait to see more of them. I often try to explain these topics to students that are very new to normal maps, and I find that it is a really challenging set of problems to articulate well. Thank you for your work on this project
I thought I should chime in about the issue that Quack was having a few weeks ago.
I also got a broken map out of handplane v1.1 when I fed it an os normal map that was baked out of 3ds max with default settings (+X Red & -Y Green).
To fix it, I had to force handplane to use the "Autodesk 3DSMax" option from the "Baked in" field. This means also clicking "NO" to the message that pops up asking if you would like to apply the detected settings. Once I did this, it generated a clean map.
This btw was with a map and obj from 3ds Max 2012 x64.
It's also worth noting that if you have inadvertently changed/reset/frozen your input object's xforms (scale/rotate) since baking out the input map, this can also produce a resulting map that looks similarly borked.
What an awesome tool, it fixed pretty much all issues i had with UDK / max / marmoset. It also makes manual optimization possible without re-baking, simply switch the optimized model and generate a new map with handplane, it's like magic!
Okay one of our artists dcarman in this thread has done all the tests. Looks like we are good to go, our engine is synced up to Maya and always has been. No dependencies in shading between VP 2.0 and in game. Also or triangulation always comes up correct even when we send quad models into the game. Looks like our engine did all this stuff correctly by default.
The one issue that we do have is that yes xNormal's maps have shading errors compared to the Maya maps, or the handplane converted maps which is why this tool exists so now I finally get it. We're looking into the next steps now to get the best quality map bakes and we have some other guys on the team testing out handplane to see if they are happy with it.
I've been testing out hand plane and ran into an issue, perhaps I did something wrong.
My test:
1. Bake object space normal map out of xnormal (using a custom cage)
2. Use Handplane to convert that normal map into tangent space normal map
3. Output was for Maya 2012 which is what we are using.
4. At ths point everything went well the normal map was clean with no artifacts
5. change topology of the low res mesh using cut tool
6. re-export it in .h3d format
7. re-render the tangent space normal map using hand plane
8. At this point normal map bake fixed all shading issues introduced with changed mesh, however some artifacts appeared, aligned with new triangulation.
A couple of possibilities. To me it looks like there is an issue with unwelded verts in that mesh (like your cut isn't quite connecting to the vertex correctly). You can email me your maya file and I will take a look. Also, check for unwelded verts, border edges, or invisible faces in those areas. Also, those cuts you made- where they randomly placed across the mesh like the ones in that video I did? You can end up in situations where you have extremely thin triangles or very bad automatic triangulation and a normal map cant compensate for that kind of stuff. You need a certain number of pixels to provide a reasonable gradient to match the normals.
... the baked map comes out looking more like a broken object space map ...
That's been the results of my short tests, unfortunately
Max --SBM--> xNormal OS map (Y-)
Max --FBX--> Handplane (Autodetect, output for unreal3) --FBX--> UDK (No Tangents imported, no explicit normals, no degenerates removed)
"The object space map appears to have normals that don't match the yz flip and xy directions of the input mesh. Would you like to apply the detected settings instead."
If I choose yes the baked map comes out looking more like a broken object space map. If I choose no the map comes out like a tangent space map but with triangle errors on my cylindrical shapes.
Any ideas on this? Will continue to work it out.
I am having the same symptoms - I have baked the maps with xnormal; and I have checked and doublechecked the settings and the workflow as described in the maya/xnormal/handplane video tutorial...
tried to create handplane normal maps for maya 2013 and unity, both didn´t work for me...
The same goes for anyone else having issues. Email me the related files and I will determine the cause. I don't need the highpoly, just your max or maya files, the object space bake, and ideally the FBX you have been using.
A couple of possibilities. To me it looks like there is an issue with unwelded verts in that mesh (like your cut isn't quite connecting to the vertex correctly). You can email me your maya file and I will take a look. Also, check for unwelded verts, border edges, or invisible faces in those areas. Also, those cuts you made- where they randomly placed across the mesh like the ones in that video I did? You can end up in situations where you have extremely thin triangles or very bad automatic triangulation and a normal map cant compensate for that kind of stuff. You need a certain number of pixels to provide a reasonable gradient to match the normals.
Good call! I double checked the geo and noticed that some cuts I made using cut faces tool happen to be very close to an existing vert and as a result created a micro triangle, I merged verts together as a quick fix, re-rendered using handplane and that fixed the problem
Awsome work guys. I was trying this out last night going from max->xNormal->Handplane->UDK. everything came out perfectly.
Would it be possible to make the two file targets drag and drop. having to click the button and copy/paste the path don'st take that long, but it adds up if you have to convert several meshes at a time. Also I'm just pretty lazy.
Do you have support for running from the command line? Or do you plan on adding it? Because then I could compound my lazyness and write some sort of batch bake/xNormal->convert maxscript.
Awsome work guys. I was trying this out last night going from max->xNormal->Handplane->UDK. everything came out perfectly.
Would it be possible to make the two file targets drag and drop. having to click the button and copy/paste the path don'st take that long, but it adds up if you have to convert several meshes at a time. Also I'm just pretty lazy.
Do you have support for running from the command line? Or do you plan on adding it? Because then I could compound my lazyness and write some sort of batch bake/xNormal->convert maxscript.
Drag and drop is a good idea and will get added to the features. Command line is something we have thought about and may add.
it only alters how you UV in so much that you can use fewer (or no- depending on the engine) UV/smoothing splits. The quality for all the engines is good enough (including unreal) that my workflow looks like this:
1) make my lowpoly
2) UV in the way that is most intuitive to texture, minimize UV splits
3) Split smoothing based on UVs
4) Bake to object space and make a test tangent space map- preview in engine
5) add support loops if there are errors - no need to rebake, just make new tangent space map
that workflow will work and be efficient for 99% of models.
Nice! Thanks Alec! I know it's not really a black and white kind of thing when trying to fix normal map issues. Good to know this can speed up the process and make fixing normal maps easier.
You will need to export your meshes with normals. Normals are a large part of generating the tangent basis - it's one of the elements (along with UVs) that must remain identical from the time the tangent space map is generated to the time it is rendered in your game.
our unity output works differently than the other engines in that for the time being it imports normals from the source object. We do this because unity's import settings default to import normals and calculate tangents and we wanted to avoid confusion when people are getting started with the tool. In the future I would like to add another unity output option that calcuates normals that match unity's own internal normals.
Hey Alec, could you give me some insight on these last few questions? I absolutely appreciate you're help. Hopefully I can pay it forward to someone else some day or to anyone that reads my write up.
If you use one somoothing group you won't see these massive shading errors in the mip maps/lods until you use a low resolution normal map? Are there times where these errors don't matter or come up so you can use one smoothing group without worrying about the shading errors?
How do you prevent Textools from applying a hard edge to uvs that you need to remain smooth? Like your sphere example.
You don't need a cage when using Handplane even in Max/Maya or is that just with xNormal?
Object Space maps sound like Average Projections since they also ignore the hard edges in the low poly. Any connection? What if you need to explode bake and have a normal map? You need a cage for that still?
Can you delete these edge loops after you get the Tangent Space map as long as the uvs don't change?
Hi chase,
I think you need to just get in there and try this stuff.
If you use one somoothing group you won't see these massive shading errors in the mip maps/lods until you use a low resolution normal map? Are there times where these errors don't matter or come up so you can use one smoothing group without worrying about the shading errors?
The shading errors are not necessarily massive, using one smoothign group is just hugely unnecessary since there will be UV splits and it forces the normal map to work very hard. It can lead to issus in mip maps.
How do you prevent Textools from applying a hard edge to uvs that you need to remain smooth? Like your sphere example.
I just go back in and resmooth those polygons together.
You don't need a cage when using Handplane even in Max/Maya or is that just with xNormal? For many people, the only reason to use a cage in xnormal is to get an averaged projection with a model that has smoothing splits. When you bake to object space the models smoothing doesnt affect the shading behavior of the output map. This means that you can flip the option in xnormal to smooth your low, thus get an averaged projection without needing a cage.
Object Space maps sound like Average Projections since they also ignore the hard edges in the low poly. Any connection? What if you need to explode bake and have a normal map? You need a cage for that still?
These two concepts are unreleated
Can you delete these edge loops after you get the Tangent Space map as long as the uvs don't change?
No. The tangent space map needs to match up with the toplogy and smoothing of the lowpoly used to create it.
Replies
If you're baking in XN and not triangulating, you don't really have to worry about that, but beware that you're now counting on 3 different apps to triangulate your mesh exactly the same. Also, if you're baking in XN, again like Alec mentioned, you're no longer synced to maya normals.
So, baking object space in XN and converting to Maya tangents would seem to be a very good workflow for you guys, considering how reliant on XN you currently are, and how annoying it is exporting very dense meshes from Z/Mud into Maya to bake.
However, you've really got to make sure your entire pipeline is synced up, and that the results when you bake a mesh in Maya show up the same in your game engine as well. Otherwise handplane isn't really going to help.
If your engine isn't synced to Maya, autodesk actually has some really good documentaion on Maya's tangents, and it should be very quick for one of your programmers to drop it in: http://download.autodesk.com/us/maya/2010help/index.html?url=Appendix_A_Tangent_and_binormal_vectors.htm,topicNumber=d0e215045
So again, I would suggest taking some relatively complex asset, softening the normals for it, baking it in Maya and exporting it to your game engine. If you get the same shading quality in game as you do in engine, hooray, your tangents are synced! If you don't, there could be a number problems along the way, include how tangents are handled by the shader/renderer, triangulation issues, and how the mesh is imported into your engine.
Alec and Luke put a lot of thought into how handplane works, so artists don't have to bother with knowing all of these little work arounds.
Here is the test I'll have the guys do, please check for sanity.
1.
-Bake high to low normal map in Maya, low poly 180 soft normals.
-Export to game, check consistency in shading between VP 2.0 and game render.
-If shading is different in game try locking normals after baking and send to game, see if it fixes the issue.
-If shading looks correct with locked normals then we will know the mesh is getting triangulated somewhere after it leaves Maya.
2.
-Bake high to low in xNormal, low poly 180 soft normals.
-Comepare normal maps in VP 2.0.
-If they look different try baking object space normal map and using handplane to output Maya map.
3.
-I want to avoid triangulated models all together, surely we can find a way to get the pipeline export to triangulate the mesh the same way Maya would do it.
Again, if you triangulate your mesh in Maya after you bake, the mesh normals change. So if you're baking in Maya and triangulating in Maya before export, you should lock your mesh normals.
If you're triangulating somewhere else, like on load, then you just need to make sure your mesh normals aren't being changed when it triangulates, normally this doesn't happen but its something Maya does when you go to Mesh -> Triangulate. Do a quick test bake in Maya with a mesh that has quads, preview it in the Maya viewport and triangulate the mesh, it will be visibly obvious what the issue is. Then undo it, lock your normals first, and do it again.
If triangulation in Maya before export is not part of your workflow, its not something you need to worry or even think about.
If you're doing Maya -> Xnormal Object Space -> Handplane w/ Maya tangents -> Game, the only thing you need to be sure of is that your mesh normals and triangulation match up in the mesh you load into handplane, and the mesh that gets loaded into engine(and that your engine is synced to Maya tangents of course).
Your testing method looks solid.
I simulated your workflow for Maya/Xnormal/Handplane and can clearly see how this saves time, since no rebakes are required each time the mesh gets edited.
The Handplane web site also says that Handplane can create lower vertex count assets, improve shading quality and fix projection errors. I realize that artists can employ a variety of tricks and techniques to achieve better results. It's unclear to me though, what specific features of Handplane can produce these improved results - and how. Do you have any examples? (the Maya/Xnormal/Handplane video was a great example for showing how Handplane can save time)
Thanks,
Dave
This video explains the advantage of handplane and synced normals.
[ame="
I have to say though this is an awesome tool and I hope to see tangent space to object space conversion soon.
I encountered that one yesterday and it is on the fix list to v1.1
We just finished testing an update for handplane v1.1. There are some bug fixes along with one major simplification of workflow. We have added a new option for "baked in" that automatically detects how your object space map is oriented. This should reduce confusion. I am suggesting that everyone use this option instead of any of the listed baking tools in the drop down. Also, I wanted to point out that handplane will accept any object space map, even from applications that aren't listed.
v1.1 changes:
Fixed crash when right click closing from the task bar.
Fixed crash in obj file reader when negative indices were used.
Fixed output of non-square tga textures.
Fixed overwriting input image file when no suffix was specified.
Added auto detect setting to 'Baked In' option. This is now default.
Added mudbox and zbrush to 'Baked In' option.
Download the new version here:
http://www.handplane3d.com/handplane_v1.1.rar
The installers will automatically patch your existing install. You will not lose any presets of application settings.
Also, the video is great at explaining the various modeling/smoothing/UVing techniques and options to control shading behavior, but I still didn't see in this video how Handplane specifically improves shading
Also, the video is excellent at explaining how modeling/smoothing/UVing techniques can control shading behavior, but it’s still unclear to me in this video how Handplane specifically improves the shading.
[ame="
they explain so much.
I also got a broken map out of handplane v1.1 when I fed it an os normal map that was baked out of 3ds max with default settings (+X Red & -Y Green).
To fix it, I had to force handplane to use the "Autodesk 3DSMax" option from the "Baked in" field. This means also clicking "NO" to the message that pops up asking if you would like to apply the detected settings. Once I did this, it generated a clean map.
This btw was with a map and obj from 3ds Max 2012 x64.
It's also worth noting that if you have inadvertently changed/reset/frozen your input object's xforms (scale/rotate) since baking out the input map, this can also produce a resulting map that looks similarly borked.
Hope this helps someone out there.
Cheers
The one issue that we do have is that yes xNormal's maps have shading errors compared to the Maya maps, or the handplane converted maps which is why this tool exists so now I finally get it. We're looking into the next steps now to get the best quality map bakes and we have some other guys on the team testing out handplane to see if they are happy with it.
I've been testing out hand plane and ran into an issue, perhaps I did something wrong.
My test:
1. Bake object space normal map out of xnormal (using a custom cage)
2. Use Handplane to convert that normal map into tangent space normal map
3. Output was for Maya 2012 which is what we are using.
4. At ths point everything went well the normal map was clean with no artifacts
5. change topology of the low res mesh using cut tool
6. re-export it in .h3d format
7. re-render the tangent space normal map using hand plane
8. At this point normal map bake fixed all shading issues introduced with changed mesh, however some artifacts appeared, aligned with new triangulation.
image attached:
alecmoody@gmail.com
include your object space map as well.
HUGE difference. On the right are my normals without Handdpane. On the left, with handplane. MIND BLOWING.
That's been the results of my short tests, unfortunately
Max --SBM--> xNormal OS map (Y-)
Max --FBX--> Handplane (Autodetect, output for unreal3) --FBX--> UDK (No Tangents imported, no explicit normals, no degenerates removed)
I am having the same symptoms - I have baked the maps with xnormal; and I have checked and doublechecked the settings and the workflow as described in the maya/xnormal/handplane video tutorial...
tried to create handplane normal maps for maya 2013 and unity, both didn´t work for me...
alecmoody@gmail.com
The same goes for anyone else having issues. Email me the related files and I will determine the cause. I don't need the highpoly, just your max or maya files, the object space bake, and ideally the FBX you have been using.
Good call! I double checked the geo and noticed that some cuts I made using cut faces tool happen to be very close to an existing vert and as a result created a micro triangle, I merged verts together as a quick fix, re-rendered using handplane and that fixed the problem
Thank you!
or could it be b/c Im useing maya 2013.5?
Left Handplane Right Xnormal
Looks awesome Thanks!
Would it be possible to make the two file targets drag and drop. having to click the button and copy/paste the path don'st take that long, but it adds up if you have to convert several meshes at a time. Also I'm just pretty lazy.
Do you have support for running from the command line? Or do you plan on adding it? Because then I could compound my lazyness and write some sort of batch bake/xNormal->convert maxscript.
Drag and drop is a good idea and will get added to the features. Command line is something we have thought about and may add.
Tried obj and fbx - still same problem.
Don't know where to dig.
Thanks!
Solved, - send low-poly model file into directory without cyrillic letters...
Just to clarify, cyrillic letters in the filename are causing the problem?
1) make my lowpoly
2) UV in the way that is most intuitive to texture, minimize UV splits
3) Split smoothing based on UVs
4) Bake to object space and make a test tangent space map- preview in engine
5) add support loops if there are errors - no need to rebake, just make new tangent space map
that workflow will work and be efficient for 99% of models.
- If we export an OBJ from Max with "Normals" unchecked, baking results in a grey tangent space map (with the Unity export option).
- Re-exporting an OBJ while handplane is open - handplane does not grab the new OBJ, it apparently stores the old one in memory.
We're probably sticking with OBJ's and not FBX as we've got a lot of them already exported.
If you use one somoothing group you won't see these massive shading errors in the mip maps/lods until you use a low resolution normal map? Are there times where these errors don't matter or come up so you can use one smoothing group without worrying about the shading errors?
How do you prevent Textools from applying a hard edge to uvs that you need to remain smooth? Like your sphere example.
You don't need a cage when using Handplane even in Max/Maya or is that just with xNormal?
Object Space maps sound like Average Projections since they also ignore the hard edges in the low poly. Any connection? What if you need to explode bake and have a normal map? You need a cage for that still?
Can you delete these edge loops after you get the Tangent Space map as long as the uvs don't change?
I think you need to just get in there and try this stuff.
If you use one somoothing group you won't see these massive shading errors in the mip maps/lods until you use a low resolution normal map? Are there times where these errors don't matter or come up so you can use one smoothing group without worrying about the shading errors?
The shading errors are not necessarily massive, using one smoothign group is just hugely unnecessary since there will be UV splits and it forces the normal map to work very hard. It can lead to issus in mip maps.
How do you prevent Textools from applying a hard edge to uvs that you need to remain smooth? Like your sphere example.
I just go back in and resmooth those polygons together.
You don't need a cage when using Handplane even in Max/Maya or is that just with xNormal?
For many people, the only reason to use a cage in xnormal is to get an averaged projection with a model that has smoothing splits. When you bake to object space the models smoothing doesnt affect the shading behavior of the output map. This means that you can flip the option in xnormal to smooth your low, thus get an averaged projection without needing a cage.
Object Space maps sound like Average Projections since they also ignore the hard edges in the low poly. Any connection? What if you need to explode bake and have a normal map? You need a cage for that still?
These two concepts are unreleated
Can you delete these edge loops after you get the Tangent Space map as long as the uvs don't change?
No. The tangent space map needs to match up with the toplogy and smoothing of the lowpoly used to create it.