[Boards: 3 / a / aco / adv / an / asp / b / biz / c / cgl / ck / cm / co / d / diy / e / fa / fit / g / gd / gif / h / hc / his / hm / hr / i / ic / int / jp / k / lgbt / lit / m / mlp / mu / n / news / o / out / p / po / pol / qa / r / r9k / s / s4s / sci / soc / sp / t / tg / toy / trash / trv / tv / u / v / vg / vp / vr / w / wg / wsg / wsr / x / y ] [Home]
4chanarchives logo
So I keep getting this blocky normals map when I'm using
Images are sometimes not shown due to bandwidth/network limitations. Refreshing the page usually helps.

You are currently reading a thread in /3/ - 3DCG

Thread replies: 31
Thread images: 10
File: ss+(2015-12-25+at+09.44.40).jpg (80 KB, 510x512) Image search: [Google]
ss+(2015-12-25+at+09.44.40).jpg
80 KB, 510x512
So I keep getting this blocky normals map when I'm using xnormals. Any reason why this is happening? I mapped out the UVs beforehand, too.
>>
It's just padding. How does it look on the mesh?
>>
File: ss+(2015-12-25+at+09.59.46).jpg (40 KB, 646x660) Image search: [Google]
ss+(2015-12-25+at+09.59.46).jpg
40 KB, 646x660
>>506775
Like ass.
>>
File: ss+(2015-12-25+at+10.01.16).jpg (36 KB, 486x505) Image search: [Google]
ss+(2015-12-25+at+10.01.16).jpg
36 KB, 486x505
>>506777
For reference, here's the high poly.
>>
>>506777

What do your UVs look like?
>>
File: ss+(2015-12-25+at+10.06.27).png (96 KB, 742x743) Image search: [Google]
ss+(2015-12-25+at+10.06.27).png
96 KB, 742x743
>>506780
Pretty normal as far as UVs go.
>>
>>506781
I wouldn't say they are normal in a sense. You need to use your space better because i see some uv shells that can be scaled higher and also they seemed to be scaled in the wrong proportions. The head uv shell shhould be alot bigger than that and you cna lessen some uv shells because some seems won't be seen so its ok.
>>
>>506824
>I wouldn't say they are normal in a sense. You need to use your space better because i see some uv shells that can be scaled higher and also they seemed to be scaled in the wrong proportions. The head uv shell shhould be alot bigger than that and you cna lessen some uv shells because some seems won't be seen so its ok.

Gotcha, sorry. I'm not too good with UVs, to be honest. I just wanted to make sure they all had the same pixel density and ended up with that. I'll try to edit them further.
>>
>>506824
True, but XNormal still shouldnt spit out that normalmap with these UVs.

OP, check your cage mesh. Also, make sure you mark all seams as sharp, then apply an edgesplit.
>>
>>506919
>OP, check your cage mesh. Also, make sure you mark all seams as sharp, then apply an edgesplit.

Edgesplit?
>>
>>506924
The edge split modifier, set it to "Sharp Edges" while leaving the angle option unchecked.
>>
File: definitely know what i'm doing.png (589 KB, 1024x576) Image search: [Google]
definitely know what i'm doing.png
589 KB, 1024x576
>>506930
> check your cage mesh

Oh god.

Also, I'm not using Blender; what's the maya equivalent of that?
>>
>>506945
Maya equivalent referring to sharp edges and edge split modifier.
>>
>>506773
OP, do you have more than one UV set on your model?

A cage mesh is simply another version of the mesh you do an inflate for xNormal to project rays from for better accuracy. You can just select the Transform tool and pull the mesh out with the blue part of the manipulator to create the cage version to load into xNormal. Or let xNormal create it.

This definitely isn't a padding issue considering the shapes of the abs aren't even showing up.
>>
this happens because you either don't have enough pixel space for those UV segments
>>
File: holes in the cage.png (590 KB, 1280x720) Image search: [Google]
holes in the cage.png
590 KB, 1280x720
>>507020
Double checked; nope, just the one.
Also made a separate cage mesh for caging. Found this one weird error where there's 2 holes in the cage?
>>507067
Resized the UVs and that didn't do anything.

[spoiler]if you want to help me with this live, add me on skype as itwasmeallalong[/spoiler]
>>
>>507107
i only get those crappy UV's if height information is over the top or little UV pixel size
but i don't think its either both, maybe something along the way broke and you didn't notice.
make sure you have proper map size and good UV's
>>
File: ss+(2015-12-27+at+09.54.06).png (268 KB, 762x761) Image search: [Google]
ss+(2015-12-27+at+09.54.06).png
268 KB, 762x761
>>507123
>e top or little UV pixel size
>but i don't think its either both, maybe something along the way broke and you didn't notice.
>make sure you have proper map size and good UV's

It looks alright, matchup-wise. Honestly, I'm not sure what's going wrong. Should I just redo the UVs completely?
>>
>>507128
Try doing a quick bake with Maya's TransferMaps to see if it's just you screwing up xNormal's workflow.
>>
File: ss+(2015-12-27+at+10.28.17).jpg (23 KB, 394x515) Image search: [Google]
ss+(2015-12-27+at+10.28.17).jpg
23 KB, 394x515
>>507129
Dammit.
>>
>>507132
Just upload your high and low poly to mega.nz or something and give us a link and I'll take a look at it. Cause desu this isn't a model anybody would steal and use :P
>>
>>507140
https://drive.google.com/file/d/0B7HaJzvN5VUraS1XNTJMalI1ZG8/view?usp=sharing
and
https://drive.google.com/file/d/0B7HaJzvN5VUraTB1NGU5Ny1jbXM/view?usp=sharing
>>
File: garblegarble.png (85 KB, 418x691) Image search: [Google]
garblegarble.png
85 KB, 418x691
>>507142
I opened your file and it was a garbled mess. Your issue seems to be that you have a huge Undo History on your mesh. It's good practice in Maya to "Delete History" on your object when you feel you don't need to adjust settings on past operations anymore. The longer your history chain gets, the more chance for error there is in exporting or reopening the file.
Opening in MayaLT seems to be alright though.

So try going Edit>Delete by type>History. And also Modify>Freeze Transforms, on both your high and your low (import the high poly into your Maya scene to make sure they match up in scale).
>>
>>507144
>I opened your file and it was a garbled mess. Your issue seems to be that you have a huge Undo History on your mesh. It's good practice in Maya to "Delete History" on your object when you feel you don't need to adjust settings on past operations anymore. The longer your history chain gets, the more chance for error there is in exporting or reopening the file.
Ah, gotcha! Thanks!
>>
>>507144
>ndo History on your mesh. It's good practice in Maya to "Delete History" on your object when you feel you don't need to adjust settings on past operations anymore. The longer your history chain gets, the more chance for error there is in exporting or reopening the file.
>Opening in MayaLT seems to be alright though.
>So try going Edit>Delete by type>History. And also Modify>Freeze Transforms, on both your high and your low (import the high poly into your Maya scene to make sure they match up in scale).
AWW, HELL YEAH! GOT IT TO WORK! THANKS!
>>
File: Blendertut_smoothing.png (488 KB, 1872x1100) Image search: [Google]
Blendertut_smoothing.png
488 KB, 1872x1100
>>506930

no
>>
>>507169
You're wrong about there not being extra verts on right side. Creating a hard-edge on your surface normals will ALWAYS duplicate the verts along that edge so that the shading interpolation can be altered. This is why if you make hard edges, then you should always do UV splits on those hard edges.

https://www.youtube.com/watch?v=ciXTyOOnBZQ
>>
>>507169
It seems neither you nor the guy who made this """"""info"""""" graphic understand how split normals work. Also:
>UDK
>glitches
>using edgesplit with angles instead of marked edges
>messes with other modifiers in your stack

Literally only a problem if you're a braindead retard.

>>507170
is right.
>>
>>507107
maybe i'm retarded but shouldn't the cage occupy the same space as the model instead of next to it?
>>
>>507107
>>507202
Yeah, I giggled when I saw the error, but then I was surprised that it wasnt acted on.

When you export your object, it will likely not be centered around the object pivot point. To help make sure it will look fine, put their pivots at exactly (0, 0, 0). I assume that it's at the bottom between the feet, just as it should be.

This happened to me before. I'd have one model to look at and one to work on.
>nope.avi
They must overlap as perfectly as possible in the xNormal viewer, which I see you know how to open.

TLDR: Low poly and high poly must overlap at the time of export, because they also must overlap in xNormal at the time of baking.
>>
>>507220
>TLDR: Low poly and high poly must overlap at the time of export, because they also must overlap in xNormal at the time of baking.

YES. Like, if you wanted to trace a picture, you'd want to your tracing paper to lay perfectly on top of the source image, not splayed out next to it
Thread replies: 31
Thread images: 10

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

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.
If a post contains personal/copyrighted/illegal content you can contact me at [email protected] with that post and thread number and it will be removed as soon as possible.
DMCA Content Takedown via dmca.com
All images are hosted on imgur.com, send takedown notices to them.
This is a 4chan archive - all of the content originated from them. If you need IP information for a Poster - you need to contact them. This website shows only archived content.