[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vr / w / wg] [i / ic] [r9k / s4s / vip / qa] [cm / hm / lgbt / y] [3 / aco / adv / an / asp / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / qst / sci / soc / sp / tg / toy / trv / tv / vp / wsg / wsr / x] [Settings] [Home]
Board
Settings Home
/3/ - 3DCG



Thread archived.
You cannot reply anymore.



File: wnormals.png (63 KB, 720x360)
63 KB
63 KB PNG
I would like to love face weight normals, but one thing gives me a headache:

How do I do FWN and triangulation? When I generate the normals and afterwards triangulate my mesh, it sometimes looks worse than before normals generation.

Should i just "skip" triangulation for baking normals?
>>
>Should i just "skip" triangulation for baking normals?
yes
>>
>>611633
When doing FWN you don't triangulate the mesh at all... technically speaking, your mesh is always triangulated in some way for it to even display on your monitor, it's just hidden from view. How you can view the triangulation depends on your editor, but setting up edges doesn't really do anything other than force tris to form a specific way, although you can do the same thing just by flipping the tris around manually.

>Should i just "skip" triangulation for baking normals?
Not sure what you mean here, usually if you're using FWN it's because you don't want to bake anything. If for some reason you intend to bake anyway, just remember that the topology of any surface being baked is completely irrelevant. If it renders/shades properly, it's going to bake properly, regardless of whatever bullshit topology you have underneath.
>>
>>611657
You are an absolute idiot. Triangulating a mesh may not alter geometry (it does if you plan to subdivide) but it definitely impacts calculation of normals. Normals are defined per-polygon, and those triangular inner edges can get screwed up and form visible seams.
>>
>>611662
>starts an argument with "You are an absolute idiot"
Your parents or teachers never taught you how to properly talk with people, huh?
>>
>>611657
With "triangulate" I meant what this guy >>611662
said but not as rude. Try running FWN generation with a triangulated mesh and compare it to the original one. You will notice differences.

What I mean by "not triangulating" is that normally when I bake my finished mesh, I triangulate the whole thing. If I'd do FWN now, I would skip that mesh and let e.g. TB3 do the job. This, as you said, would lead to the effect that some engine may triangulate the mesh in a different pattern, thus rendering the normal map erroneuos.

I mostly use FWN to get rid of smoothing errors, enabling me to get more UV into one UV island.
>>
>>611662
>Normals are defined per-polygon, and those triangular inner edges can get screwed up and form visible seams.
Normals are defined per-vertex, and they don't care about whether the content between them is a quad or a pair of tris. Your quad is a pair of tris anyway, which you can check by enabling whatever your software does to edit tris instead of polys. As long as your workflow respects the triangulation you set, you don't have to do anything yourself; for example, exporting FBX from Max into UE4 always results in expected shading even if the entire side of a surface is one big n-gon. If there are quirks to using FWN outside of Max and UE4, then I'm not aware of them, as this is the only combination I use.

>>611684
The main effect topology can have on FWN is whether or not you're doing soft shading, in which case you do actually want your model to have a fairly even distribution of polys so that it looks right, otherwise you'll get artifacts from long tri strips.
99% of the time I use hard shading by setting normals from face direction instead of weighting, so topology has absolutely no effect on the surface shading as long as the surface is flat or curves along one axis.
>>
File: FrostSoft_doc-3.png (163 KB, 689x293)
163 KB
163 KB PNG
>>611692
Normals are NOT defined per-vertex. that is only the case if you unify your normals. i.e. enable smooth shading. Each vertex can have multiple normal vectors, one for each polygon that is attached.

Importantly, the normals of the underlying geometry play a role in defining the tangent space basis. When you use a tangent space normal map and change the normals of your underlying geometry, you are going to get different (probably incorrect) results from your normal map. The FWN step after triangulation destroys this.

The 100% proper way to bake a map for a triangulated mesh is to triangulate first, then bake. If you triangulate afterward, you may get slightly different normal map computation. Now if you're doing the baking inside Max, then the triangulation step for baking and the triangulation for export will be the same, so that itself is probably not the issue. However if you bake first, then triangulate, THEN alter the normals on the triangulated mesh, you will be applying the normal map to an object that is totally different than it was created for.

Lucky you that you have not run into normal map errors with your particular Max->UE4 workflow. But your answer to OP's question that "you must not be doing anything wrong because I think it sounds kinda like what I'm doing and it works for me" is completely wrong. Absolute idiot.


So answer is:
- Triangulate before baking your map, though that might not be crucial if you're doing everything in Max.
- After you bake, do not touch the object normals again.
>>
why you guys make such a big deal out of something that takes exactly 2 seconds to accomplish?
maybe the bevel bake thingy requires abit more work, but that's about it
>>
>>611717
>Normals are NOT defined per-vertex. that is only the case if you unify your normals. i.e. enable smooth shading. Each vertex can have multiple normal vectors, one for each polygon that is attached.
...except unified normals are the entire reason to use FWN, it's literally the only reason this technique is useful. When a vertex has multiple normals, you really end up having as many vertices superimposed on one another as there are discreet faces. Max or Maya will tell you that a plain cube has 8 vertices, but as far as your GPU is concerned, it has 24. By utilizing chamfers, putting the whole mesh into a single smoothing group, and manipulating the normals to not look like shit as a result of doing so, all adds up to increased efficiency as you get beveled edges for the "same" geometry load as without.

In any case, I continue to not see the reason why you keep throwing the word "bake" around, as it's the antithesis of FWN. If you're going through the trouble of potentially increasing the vertex count of your mesh by 30~50% to model in detail you may otherwise have utilized a normal map for, why would you then bake that down? Just use the tried and true high-to-low poly method in the first place.

>>611728
Something tells me that someone or other is confusing concepts or terminology here. FWN or "medium poly" as it's also called is designed to be used in a game engine as-is, you model something and throw it right into the engine, no maps or baking required. Modern game engines have no problem handling hundreds of millions of tris on screen, while textures still present an issue if you take into account the detail required on big screens, so it's a decent trade-off to increase poly count and use tiling textures, rather than unique baked ones, especially on large-scale objects and structures.
>>
>>611733
The main purpose of FWN is to save texture space by relying on tileable textures and decals/trim sheets, rather than baking unique textures.
>>
>>611799
Texture space can be saved on using tiles and trim shim sheets regardless of the modeling method, games like Sunset Overdrive use trim sheets very aggressively for most assets, however it does not utilize FWN at all, all edge smoothing comes entirely from normal maps (also in the form of trim sheets).
>>
please forgive my ignorance, what is the difference between a texture atlas and a trim sheet?
>>
File: image.jpg (261 KB, 1200x737)
261 KB
261 KB JPG
>>611828
Both are basically a texture that you crop out details from to reuse, but the difference is that an atlas is designed to encompass entire surfaces, while a trim sheet is designed for details.
For example, pic related is an atlas with a building facade and it uses complete chunks of object detail. A trim sheet meanwhile would look like a bunch of variable-width strips that are mapped as specific components, rather than entire surfaces.
>>
File: image.jpg (322 KB, 1040x844)
322 KB
322 KB JPG
>>611838
And a template of a trim sheet. Unlike the atlas, the trim method relys on laying out details, you can then create more variety in the engine shader by blending other materials over or adding decals.
Unlike the atlas method, trim sheets are also useful for normal maps, as you can create a map containing every type of bevel you might need, and then just UV them into place. For curved objects you just straighten its UVs and assign them to a strip, the texture will then curve with the object, so there is no wasted texture space.
>>
File: partyHard.gif (3.69 MB, 640x356)
3.69 MB
3.69 MB GIF
>>611838
>>611839
>>
>>611907
That's what she said!
>>
>>611633

Can someone show the proper way to UV unwrap bevels like this? Like can you separate top and bottom then unfold a strip or when unwrapping do you include the small panels for most sides? What do you leave separate islands and when not?
>>
>>612197
Leave them together. Less seams is better than lots of UV islands. Unless there is texture distortion, then you want to separate the islands.
>>
>>612206

Okay, so basic unfold-style layout is what you are getting at?
>>
File: BevelcubeUV.jpg (36 KB, 538x562)
36 KB
36 KB JPG
>>612212
>>
>>612197
FWN lends itself well to a UV-less workflow, you just throw on a cube unwrap with its size set to the grid snap of your project to set the scale, and then use triplanar mapping in-engine for the base texture. Additional details can be added as blends, decals or vertex paint; you can also use floating geometry.
I should mention here that lightmaps are a nightmare to configure for FWN objects, so if you're planning on using this technique for static objects within the environment, you'll have to go all-in and utilize entirely dynamic lighting.
>>
>>612266
There is no problem with lightmaps if you have a separate UV for them without overlapping.
Its the floating decals that create problems.
>>
>>612277
It's still arguably more trouble than it's worth, I've spent a lot of time trying to get some assets to bake lighting properly and it's just too hard when you have so many tiny triangles in your mesh that essentially end up as sub-pixels. Even with unreasonably high-quality maps it's not enough to clean everything up.
I guess it depends in part on the complexity of your model, but I think it's still a better idea to either just not use FWN too extensively for static meshes, or to not have to deal with baking at all and use GI. All existing games that feature FWN have fully dynamic lighting, so I think it's better to trust the experts than trying to beat a square peg into a round hole.




Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.