[Solved] Blender Face weighted normals (controlling bevel weights?)
polycounter lvl 3
So I'm attempting to implement face weighted normals within Blender on a basic modular level kit.
http://polycount.com/discussion/154664/a-short-explanation-about-custom-vertex-normals-tutorial/p1
https://www.reddit.com/r/starcitizen/comments/3ogi3o/im_an_tech_artist_in_the_industry_and_id_love_to/
That post seems to be a bit inactive so I figured I should just post this question independently from the face weighted normals thread.
I've run across a use case that I'm having some difficulty working around.
Essentially the issue is construction of a modular level kit where the outer edges of the mesh need to be sharp. However when implementing face weighted normals, if the outer edges are not beveled (bevel weight of 0) the rest of the surrounding faces receive incorrect shading. Help would be much appreciated if any of you have suggestions!
Here is an example of what I mean: http://i.imgur.com/mmjNDBP.jpg
Thank you!!
http://polycount.com/discussion/154664/a-short-explanation-about-custom-vertex-normals-tutorial/p1
https://www.reddit.com/r/starcitizen/comments/3ogi3o/im_an_tech_artist_in_the_industry_and_id_love_to/
That post seems to be a bit inactive so I figured I should just post this question independently from the face weighted normals thread.
I've run across a use case that I'm having some difficulty working around.
Essentially the issue is construction of a modular level kit where the outer edges of the mesh need to be sharp. However when implementing face weighted normals, if the outer edges are not beveled (bevel weight of 0) the rest of the surrounding faces receive incorrect shading. Help would be much appreciated if any of you have suggestions!
Here is an example of what I mean: http://i.imgur.com/mmjNDBP.jpg
Thank you!!
Replies
I'm a Maya user but I assume that you want something similar to the right object in this screenshot:
http://i.imgur.com/EHSs74A.png
Same View but with Hard Edge visualisation enabled:
http://i.imgur.com/PD8ORJZ.png
Both set to Area weighted normals rather than Angle & Area weighted. Just to compare with yours.
I'm not sure how you're getting the odd shading appearing in only the top part of the mesh. Unless it's just your camera angle.
Does this help? I'm trying to work on understanding peoples problems since I often run down the wrong track.
The stack of modifiers that I currently have on each piece is as follows Bevel, Triangulate, data transfer. data transfer is what is grabbing the Face weighted normals from the low poly copy of the mesh and forcing the normals on the high poly to adhere to their tangents. Let me dig around the auto smooth and see if I cant get a result that allows me to not have to bevel the outer edge of the modular piece. this would really help save on vert count.
Flat shaded with the triangulate modifier disabled.
Tris enabled
Smooth shaded without tris
Smooth shaded with tris. So after all this was unfortunately not able to solve the issue with having an interior window ledge that has a bevel and and outer edge without a bevel. I'm not sure if this is a limitation of using Face weighted normals in blender with the data transfer method, but I really want to get to the bottom of this. Adding a microscopic bevel to the outer edges just to get correct shading seems like the incorrect method. For comparison Here is what the fully beveled mesh looks like (this has a bevel weight of 1 on the window ledge and a bevel weight of .004 on the outer edge that will snap to other walls etc.):
You can see the inner window ledge is tagged with a full bevel weight (1.0) as it is displayed in orange. The outer edges are a thicker black edge denoting a very tiny bevel weight (0.004). you may need to zoom in on the image to see that, but its there. Hopefully these images help to illustrate further what I'm talking about. I can get a macro close up if needed.
I don't understand what you are trying to do. So : what exactly are you trying to do ? Please describe your end goal as succinctly and precisely as possible.
I also don't understand your use of the data transfer modifier. There are little python addons dedicated to running FWN on a model in one operation (assuming that this is what you are trying to achieve of course) :
https://github.com/meta-androcto/blenderpython/blob/master/scripts/addons_extern/mesh_weighted_normals.py
I am using a py script to run a FWN action on my low poly copy of my model to force my higher poly beveled copy of the model to use the same normal weights. (Maybe this is an unnecessary step and maybe I should ditch the data transfer and set the normals just with the script?)
I am not familiar with the intricacies of the SC workflow (although I would assume that this is just a matter of decals and carefully edited normals) so maybe I am missing something. But regardless, the following two points do not make much sense to me :
• "The idea is that by using a low poly version you can circumvent having to set the normals manually throughout the modeling process" > Setting the normals of what ?
• "The data transfer modifier will simply copy the normals to your high poly for you." > I don't know what you mean by "highpoly" here.
Therefore I would invite you to reformulate your question as clearly as possible, and preferably without referring any other related threads or game title. What exactly are you trying to achieve technically speaking, and what is currently not working about it ?
If so, try detatching the side faces so they're not affected by the bevel and data transfer. You can join them afterward but don't weld vertices
In the third image you can see in the use case where you need to have edges that are not beveled in conjunction with others that are using the fwn from the sharp copy, the shading goes haywire. The reason you would need edges like this would be in something like a modular asset kit where there are specific edges that need to snap together. Ultimately I would like to avoid adding in additional edge loops on a bevel when the bevel wouldn't even be needed since the edge would be sharp anyway. I hope this helps to clarify.
Thanks everyone!
For instance (pardon the crude analogy) : if your break a paintbrush, you don't explain that to the art store clerk by showing them an unfinished canvas - you show them the broken paintbrush itself
I also don't understand what the issue is to begin with - you mention low polies, high polies, transferring normals data, and so on ... whereas the SC technique seems to merely involve running a face weighted normals script on simple models.
This might also just be a misunderstanding about what FWN actually means. FWN does not involve any surface data transfer, it just (more or less) means that the vertex normals of a model get edited in a way that favors large areas.
All that said I could be completely mistaken ! I am sure someone will chime in with the right answer
Here's an attempt at distilling this into a single sentence. I'm picking up what you're putting down, but I guess I hadn't boiled it down far enough. So here goes.
I want to have a nondestructive method for adding face weighted normals to only specific faces of a mesh so that the outermost edges of a mesh can be kept sharp for the purpose of snapping/aligning to other modular parts.
The workflow I'm referencing specifically does relate to face weighted normals and running a fwn script to recalculate those normals. However, it is exactly that video that I posted when you asked a few comments back that implements the data transfer as a "non destructive" method of adding face weighted normals.
What I don't understand is the way you mention running a FWN process on the proxy model you then grab normals data from. What's the point of that ? The reddit post about SC and AI doesn't mention any of that - it just looks to me that they are simply running one of the many FWN processing solutions on their models, like this :
But as said I could totally be missing on some of the more subtle steps of their workflow ! (and I don't have much experience with modular workflows to begin with XD).
Are you applying the FWN script first then doing sharp edges, or the other way around? Because it looks to me like it's not taking your sharp edges into account at all.
I agree with pior about not being sure of the purpose of a high poly target. While this workflow should work with baking normal data down, the SC guys are utilizing FWN specifically to avoid baking unique normal maps.
I think I may have found the solution to my problem though. I did another test on the data transfer target mesh and it seems to be topology related. So I'm going to try adjust some of my edge loops to see if I can eliminate the incorrect normal shading.
Run your FWN script. Then select your edges and edge split, should work, hopefully? I'm basing this of my bare minimum knowledge of Blender right now.
This should not make too big a difference if you're doing this in real-time, since I think most real time engines simplify the geometry so each vertex has only one normal anyway (that means sharp edges get split anyways).
Edit; It might make data transport difficult if you intend on bringing it into other programs though
So the modifier stack is just a way to replicate FWN without using an external script - you want to do it this way for sake of non destructive. You're using highpoly and lowpoly in regards not for normal map baking but rather lowpoly to control weighted normals which threw me for bit of a loop. Personally I think it's silly when you can just duplicate your mesh off, apply modifiers, run a fwn script and find out then go back to old mesh for further bevel modifier adjustments. Rather then having to play around with a proxy model (low poly as you called) then when you modelled that having to duplicate it, set up layer stack, then if you find you need to say move the window border down you have to delete the entire hipoly, modify low poly and then repeat the process of duplicating and creating a modifier stack again.
So the problem is that you're trying to have edge splits remain and data transfer is destroying the vertex normals outside the area you want to be effected. This should work
Now there's plenty of different ways to solve it. EDIT: Nvm I was wrong, these solutions sucked.
- You can set up your data transfer to apply to only apply to selected verts by creating a vertex group which will be affecting which verts receive in the transferring of normals. Along with mark sharp and autosmooth+custom normals
- Simpliest way, just tell your model to flat shade. That way all edge normals on the base model are split, data transfer will join those normals beveled effected back together which is what the ugly shading on the edges that you want sharp are doing. But I can't guarantee it'd work in all situations.
- Best way is to probably add marked edges sharp edges along with storing custom split normals. That way you can change your mind if you want an edge split or not on parts of the mesh not being bevelled.
Left is proxy
2nd from left is model smooth shaded and modifier stack
3rd - Mesh flat shaded and modifier stack
4th - Mesh smooth shaded with custom vertex normals edge split data (marked sharp edges)
When I say add custom split normals this is what you need to tick. (They're both enabled in pic below which is what you want) -
EDIT:
There's so much I don't understand why you're doing though
Like
Low poly should be flat shaded, doesn't need to have scripts run on it. Infact any smoothing will cause issues on the model.
Now there could be other reasons this isn't working for you.
In regards to example https://us.v-cdn.net/5021068/uploads/editor/ux/63kcdd4pfo8w.png
In the above is your proxy mesh located in the exact same position as your high poly, if they're offset there will be issues like in the image there will be issues. But since I can't see your layers Idk if you've just simply hidden them.
Sometimes data transfers tab will need to have it's visibility toggled on and off to refresh info, so if you're testing solutions they might be the answer but you haven't refreshed the model.
Sometimes models retain bad normal information and you may need to clear it. Especially when dealing with normal scripts.
Actually you both are right to be apprehensive of this method. This is the first time I've attempted using face weighted normals in this way and I do agree with your criticisms of the proxy model method. Its just as you say Pior, that the SC and AI teams undoubtedly were not using anything like a proxy and were running a fwn script on the model as they modeled to completion.
Zeist, that was me incorrectly remembering the workflow for the proxy model. You're right it does not require the script to be run since the proxy would be flat shaded anyway. Clearly I need to reevaluate my process here and check out the methods you've listed.
I do admit that when I found this data transfer technique a couple nights ago that it seemed pretty tedious and cumbersome. Until I began using it for simple modular pieces that would not be as complex as something like SC's starships. Thus, something that is easy to adjust and would benefit from a non-destructive approach. Though as I said, I'm not totally sold on building it this way. it very well could be the wrong/an inefficient way to approach this.
I definitely have not seen a production model created this way, but maybe there is some reason to use this over a normal fwn workflow in some cases. So i'll try a few more ways and see if this really has any merit.
As always, thank you guys for the input/feedback!!
But is it possible that you are trying to use the process I described here? http://polycount.com/discussion/comment/2363637/#Comment_2363637
If so, I might be able to help.
Process is not up to date, I adjusted it a bit, but the basic idea is the same. Currently using it for this model http://polycount.com/discussion/188333/macross-destroid-defender-battletech-rifleman-wip#latest
I`ll write a bit more details and add some screenshots later if interested.
Btw. use a matcap or at least flat shader to show your problem. It's impossible to see what the actual issue is on some screenshots.
On the off chance did you use duplicates of the default scene cube for your models? It's probably irrelevant but it's strange to me why this is happening to just that mesh and I don't know what's causing it.
In this the first model is the default scene cube & a duplicate, modifier stack and then it all breaks.
The second attempt works exactly how it should and is created to the same form, added in just a default cube. So what's the scene cube contain that the default cube doesn't
So the question is what's being contained on that default scene cube that breaks normal's and how's it different to the default cube you can add in. It's consistently breaks on the default scene cube but works fine on any other mesh for me. There's something there that afaik the data transfer is obtaining that's contained in that mesh that's causing this.
Personally data transfer modifier tends to be a bit fickle and I generally don't like it, better off using a workflow without it.
Edit:
Also bugger what I've been saying, some of it a bit wrong
Mark sharp doesn't do anything and I was wrong to suggest it. Vertex group assigned in the data transfer tab seems to be the only way to do it reliably as data transfer has issues on edges and receiving the right info causing bad normal info depending on shape. Sharp is a process that comes before not after, data transfer will over-write it - dunno what I was thinking. And vertex group probably won't work well in quite a few cases Sharp is still needed for certain forms/shapes or autosmooth if you want
Another edit:
In regards to having to re-do modifier stack upon changing proxy.
Alternatively you can use ctrl+L to make Link between the mesh with Object Data. Modifiers work independent of that and you can have bevel on one, along with data transfer, etc. And if you need to modify shape, editing either one will modify the other. Will need to unlink it to assign smooth shade/flat to one another but quicker then modifying and duplicating, etc.
Playing with this, really seems too fiddly and restrictive. Sorry man.
edit: also yeah good idea on the matcap.
may this help!
https://blenderartists.org/forum/showthread.php?393179-Addon-Yet-Another-Vertex-Normal-Editor-(Y-A-V-N-E-)
This is just one way how to work with custom normals and for sure not the holy grail, but works well on specific models, like my example.
With YAVNE you have more possibilities.
1. before starting actual modeling create a linked duplicate of your object
2. add a "split edge" modifier to the duplicated object, turn off "edge angle"
2. user auto smooth at 180, make sure all face are set to smooth always
3. add a "bevel modifier" to the original object, switch limit method to "weight"
4. add a "data transfer" modifier to the original to transfer custom normals and pick the duplication as a source of course. I usually switch to local space and place the objects next to each other on separate layers
5. start editing your object, define bevel weights to the edges you want to bevel and set all beveled edges to sharp.
Because the objects are linked, you don't need to edit them separately, you actually cannot. Making sure that all bevel edges are also marked sharp is crucial.
Tbh it is a bit difficult to understand what you are writing.
If I understand you correctly now, you are trying to combine hard edges and chamfered edges with custom normals?
With the above process you need create a vertex group of the once you want to exclude from the data transfer.
But it's a bit tricky, you get shading errors (circled) if the hard edges connect to beveled edges, if they run parallel it is ok.
and well.... it just works now? I haven't uv mapped it, but it looks promising. I'll have to return to my original file to see why it was acting up.
Also @Prime8 dont you mean to have the data transfer on the target mesh and pick the original as the source? and definitely yes about the local space. I'm not 100% sure why in that video the guy makes a point of having them occupy the same space when you can just toggle that off.
(above) So here we see the hard edged source mesh (previously referred to as the Lowpoly mesh) and in front of that is the smoothed target mesh that will receive the bevel and data transfer modifiers (previously referred to as the Highpoly mesh). The target mesh has auto smooth enabled and set to 180. We'll see shortly that this may actually be an unnecessary step.
(above) Here we are seeing that once the link between the two mesh objects has been set we lose our auto smooth on the target mesh. This however appears to be totally okay.
(above) Here we can now see that the modifiers have been added to our target mesh and our source mesh selected in the data transfer to transfer our face weighted normals to the target mesh.
(above) Here I've sharpened the interior edges to tag them to be beveled. In the next image I've exaggerated the bevel amount and also added in more edge loops to mimic the topology of my previous test models in the modular level kit scene shown in previous comments in the thread.
So there it is? I'm not sure as of right now why this worked and my other mesh's had issues, but that is another mystery to solve. At least now I am certain that this is possible to accomplish. Now to return to my other file and figure out what is even going on there.. Hope this helps!
Their topology is identical. I have no idea what is even going on with the old mesh. I've linked them. I've made their auto smooth angle 180. I've made sure to remove doubles many many times. I've checked mesh lint just to be extra sure. They should have the same result, but they don't.
Too much text and too many screenshots, try to keep it short, otherwise people don't read it.
Autosmooth is necessary to define which edges are sharp and to make sure curved surfaces are smooth.
You lost the autosmooth because you linked to the mesh which didn't have it active. If you use a linked clone from the start this wont happen.
Your result is now flat shaded not smooth and without the additional vertices on your final mesh, this will cause shading errors.
Ohhhhhhh, I walked back through your post to make sure I understood your steps. Its the same exact way that I was doing it, but in reverse. the end result is the same. its just that in your way you are working mainly with the duplicate instead of the original. In mine I am setting my hard edges and all that on the original.
Still I need to figure out what is happening with my old mesh. I suppose I could rebuild it because it is a super simple object, but if this happens again in the future I would like to understand why.
I do however see the benefit of using a vertex group exception in the instance that you need soft curved surfaces in addition to sharp edges as well as bevels. In the example I posted above however that was not needed in order to create the faceted copy with fwn normals.
We've gotten a bit off track. Ultimately with the scene I had it appears that there was some kind of corrupted data and rebuilding the simple modular pieces from new cubes solved the odd normal shading. Which makes sense that the issue would have effected many but not all pieces as many were created from duplicating one piece and altering it.
Have a good one @Prime8
I reply later with more information on the issue.
Rest assured that I am most definitely reading the help that I am given very carefully. I take it very seriously and I definitely don't take it for granted. I'm well aware that we all have better things to do or at least things we would rather be doing.
So yes, thank you very much for the clarification. Maybe it will shed some light on why my other geometry seemed to have become bugged.
- its just that in your way you are working mainly with the duplicate instead of the original. In mine I am setting my hard edges and all that on the original....There isn't any benefit over using the linked duplicate versus the linked original because as you have said editing one or the other affects both.
Yes right, they have the same mesh data, doesn't matter which one you edit. I work on the original mesh (the one with bevel and datatransfer modifier) to see the result directly.
- Its the same exact way
It is not exactly the same because in your green prime8 example you are not using sharp edges and vertex groups where needed, that's why you get the shading errors.
I looked at the method using flat shading again and found a couple of issues. It will cause errors on any curved surface, even though you might not use one at the moment, might be an issue later. On flat surfaces it causes shading errors as well, depending on the topology it can seem random, maybe that's what makes your other meshes seem to be bugged?
Same as before, with flat shading and without vertex groups for exception.
Closer look at the windowlike shape, that is closed to your wall mesh.
When duplicating you get kind of random shading artifact, which seem to have to do with triangulation, because they change if you change the triangulation method as well.
Depending on how your walls should look finally, you might be better of using Y-A-V-N-E instead of this method.
That's just a way to comfortably create custom normals. You "copy" the normal information from the surfaces of the hard edge object to the one with the beveled edges. Basically weight the face normals according to the faces of the other object.
You can use a subdivided mesh instead of one with hard edges as well, but there is no benefit, except in some cases where you have a lot of bend surfaces, they are a bit tricky anyway.
example
The normals, from inside out, sharp edge, beveled and bevel with transfered data.
It transfers the face normal (cyan) to the face corner/vertex normal. To my understand the new face normal than again is calculated by the transfered vertex normals.
I'll give it a shot!
Thanks again
You can do this by editing your first post.
edit: So after all was said an done, it appears that these meshes just have something intrinsic about them that has resulted in incorrect shading on some faces. I tried using a vertex group in my data transfer modifier. Both using a bevel and data transfer on the original mesh and vice versa on the linked duplicate and the faces remain warped. So not truly a fix, but recommended that people in the future either avoid using this method or rebuild their base mesh... I'll update if anything changes.