[ 3 / biz / cgl / ck / diy / fa / ic / jp / lit / sci / vr / vt ] [ index / top / reports ] [ become a patron ] [ status ]
2023-11: Warosu is now out of extended maintenance.

/3/ - 3DCG


View post   

File: 724 KB, 2985x2355, IMG_5914.png [View same] [iqdb] [saucenao] [google]
966997 No.966997 [Reply] [Original]

I deconstructed a normal map into its R, G and B components. Red seems to represent horizontal info, Green seems to represent vertical info, and Blue seems to represent depth/height info. With this I can essentially paint normal maps. Obviously not saying that this hasn’t been done before, but I don’t think it’s common today.

>> No.966998

>>966997
This might not be interesting if you already know this, but as someone who didn’t I found it to be so.

Now you might be thinking “what kind of caveman would paint normal maps instead of generating them?” Me. I would.

>> No.967017

>>966998
you aren't supposed to do this even to fix baked normal maps
yet, good find. and that's the same way texture packing is done

>> No.967018

>>966997
>So I deconstructed a normal map into its R, G and B components
Anon i.....

>> No.967020
File: 9 KB, 164x159, Screenshot from 2023-12-13 02-34-42.png [View same] [iqdb] [saucenao] [google]
967020

>>966997
Have you considered that XYZ is color coded

>> No.967033

>>966997
You need to renormalize your texture if you're going to paint. Krita supports this as a filter.

>> No.967053

>>967017
Good point. For me this is less about the result/technique and more about discovery.

>> No.967054

>>966997
>Red seems to represent horizontal info, Green seems to represent vertical info
no, it's tangent info.
>inb4 object-space tangents
no one uses object-space tangents anymore, fuck off.

>Blue seems to represent depth/height info
no, it's normal direction and almost always flat. because it's tangent space, duh.

>with this I can essentially paint normal maps
no, you can't.
you can combine them with other normals though.

>buh-buh why does this brick normal texture match what I said, ch-checkmate, chud!???
because it's a fucking flat plane, where the x and y tangents in 3d match 2d absolute coordinates.

>> No.967058
File: 802 KB, 946x720, cgjishu-1709155951859868127-20231003_053828-vid1.webm [View same] [iqdb] [saucenao] [google]
967058

>>966997
I liked this webm

>> No.967059

>>966997
We have photoshop tools for this purpose. We don’t need to spend hours editing images when the artist can let photoshop do it.

>> No.967060

>>966997
tangent space, object space, or world space normals?

>> No.967061

>>966997
Anon this isn't exactly rocket science
>but I don’t think it’s common today.
It's literally just the matter of looking at normal map channels in photoshop, It is essential when you are implementing an asset into a game that does shit like moving a channel of a normal map to alpha or when you need to invert green

>> No.967068

>>967054
give him a break, he's probably a blendlet

>> No.967075

>>967058
does the RG channel specify the values in degree rotation while B channel is in height position? Or are all of them specify XYZ position (but normalized in a sphere boundary)?

>> No.967079

>>966997
>>967075
Normal Maps are normalized (= if you treat channel values as ranging from 0-1 the vector you get from combining all three channels is always length 1).
The blue channel is completely redundant because the third component of a vector can be reconstructed from the other two if the length is known, that's why a lot of normal map compression algorithms discard the blue channel entirely and only encode R and G.

>> No.967082

>>967068
I admit, I am.

>> No.967084

>>967079
what i mean is...let say the channel value goes between 0 and 255 for Red and Green. Does the value 255 means 90 degree away from prependicular (straight up) or does it mean the "position" of the normal's target the pixel is pointing to? (if that makes sense)

>> No.967102
File: 482 KB, 1920x1080, i01.gif [View same] [iqdb] [saucenao] [google]
967102

Some dude named RUX supposedly hand paints his normal maps. Haven't seen him actually post any of the normal maps. https://roggiero3d.artstation.com/

>> No.967105

>>967084
The former. With normalized vectors "direction" is the only correct interpretation, "position" is nonsensical unless you only care about points on a unit sphere.

>> No.967106
File: 161 KB, 700x700, Nrmlmap_ao.jpg [View same] [iqdb] [saucenao] [google]
967106

>>967105
ahh ok. i think i get it. so in the case of when you force the normal to *not* normalized to 1, you'll get 'unnatural' lighting? like how some games use the B channel with shorter normals to simulate a baked in AO like picrel?

>> No.967107

>>967106
In your picture the B channel is separated from R and G and goes through a completely different shading process to get that AO look. It's not some clever math trick, shading with unnormalized normals gives complete bogus values and looks like garbage.

>> No.967131

>>967106
In your picture they use the RG channel as a "compressed" normal map, and since the B channel is free they store another map inside it, they're completely unrelated processing wise.

>> No.967174

>>967102
you can just paint black and white height maps and convert them to normals using blender

>> No.967221
File: 426 KB, 1773x837, img-2023-12-15-12-33-43.png [View same] [iqdb] [saucenao] [google]
967221

>>967107
>>967131
Yeah i also know that you can keep the normalized RG map, but include a totally unrelated B map that is used for a separate lighting calculation. You use RG channel (with in-engine calculated B channel) for normals shading, and then the baked B channel for AO multiplying/darkening.

But what im asking is somewhat different. Perhap i should add the context from Polycount Wiki (picrel) here:

http://wiki.polycount.com/wiki/NormalMap#Ambient_Occlusion_into_a_Normal_Map

What it suggest here is, if you use an unnormalized renderer, you can take a grayscale AO map, and then apply it with a multiple/darken blending mode onto the normal map. It doesnt specifically mention whether to blend it only to B channel, or all RGB, but im guessing (and judging from the pic) it should be all RGB, because it doesnt make sense to use blending mode on an 'empty' B channel, might as well just swap the whole B channel with the AO map.
It also specifically mention about 'shortening your normals' to receive 'less light' on crevices.

So if i understand it right, a normal vector distance of 1 gives correct lighting, -1 gives flipped normal, and less than 1 will give less light?

Because if that's the case, i think that is kinda a clever trick that you normals and AO in just one calculation instead of a separate AO pass.

Or am i completely wrong, and by that extension, that polycount wiki is also wrong and incorrect?

>> No.967223

>>967221
*you can shade normals and AO in just one calculation

Also if the Polycount article is correct (in the way that i understand it), i still dont know any example of games that uses this "normal shortening" trick. Any examples would be great. Im guessing its probably some kinda stylized/toony game from the PS3/X360 era.

>> No.967231

>>967221
>http://wiki.polycount.com/wiki/NormalMap#Ambient_Occlusion_into_a_Normal_Map
Ah, I see, they actually shorten the normals, you were right.

I'm afraid this technique won't work in a lot of today's game engines since a lot of them re-normalize their input maps to get slightly better lighting quality, and I'm not 100% sure what the benefits are over simply swapping the B channel.

>> No.967235
File: 76 KB, 243x531, img-2023-12-15-17-51-57.png [View same] [iqdb] [saucenao] [google]
967235

>>967231
im actually seeing a two-fold benefit, one is getting a simulated AO together during normals shading, and two, you can skip calculating for proper renormalized channels. probably it would save time on older hardware? but like ive said, theres no example of games using this (maybe proprietary engine devs dont talk about it) so its hard to judge the visual results other than the polycount example.

i wonder how this trick would look if it is also paired with half-lambert shading. probably looks good for stylized rendering to simulate cheap fill light together with AO.

>> No.967246

>>967231
Light maps usually have lower resolution than normal maps. That's why they're left separate.

>> No.967250

>>967246
The map in question is not a lightmap, it's an AO map, that's a completely different workflow.

>> No.967252

>>967250
No.

>> No.967273
File: 135 KB, 1890x876, handpaintedNormals.jpg [View same] [iqdb] [saucenao] [google]
967273

>>966997
I've hand edited normalmaps and done special effects that would be hard or impossible to accomplish in 3D a long time.
There is nothing wrong with manually editing normals as long as you understand what you're doing.

Most normal maps you make will be 'tangent space' normal maps and therefore it it usefull to have a normalization filter availible to extract your blue channel as
that one is complicated to create manually. The process for creating a correct manual normal map is as follows;

Create your XY component for the Red and Green channel, combine them and leave the Blue channel white. Run a normalization filter to generate the Blue channel.
Copy the blue channel and use 'levels' on it to extract a more aggressive variant of it, combine this with your RG data and renormalize this.

Reason you do this is because a normal map seek to provide a 'normal'; a XYZ 3D vector/direction with a combined lenght of exactly 1 'unit lenght'.
Your shaders will normalize your normalmap internally as no RGB vector is exactly 1 due to the '256' steps per channel generating roundoff errors,
You can get away providing only XY information for this reaosn but the closer you are to provide a true normal vector in the map the higher your quality your results will be.
IF you don't account for the blue channel in your map your results will look a lot flatter than a good normalmap that can have a lot of depth.

Pic related is another technique that can be utilized to provide exact normal data to textures that only exist as quality diffuse data.
I posted it here many years ago when people where telling me all about how I absolutely could not be doing what I did.

>>967054
>no, you can't.

You absolutely can anon, try it and you'll see for yourself.

>> No.967274
File: 68 KB, 1018x853, handpaintedNormals3.jpg [View same] [iqdb] [saucenao] [google]
967274

>>967273
There's a side by side so you can tell what is geometry and what is normalmap in that example.

>> No.967277
File: 283 KB, 1346x852, handpaintedNormals4.jpg [View same] [iqdb] [saucenao] [google]
967277

>>967274
This image highlights the process for how to mask off areas and how to paint to get very exact falloff to describe curvature on surfaces. It's a process inspired by classical airbrush techniques for painting shape using only masks and falloff.

>> No.967279

>>967273
>extract your blue channel as that one is complicated to create manually

the blue channel in tangent-space normals is literally 1. full blown vga blue. it's literally the equivalent of the geometry normal vector as seen from the "uv camera" and it's always 1.
if it isn't, then either your UVs and/or your quads themselves aren't properly flattened.

>You absolutely can anon
you "can" as in nothing technically prevents you from doing so, it doesn't mean it's a good idea.
you're basically trying to "sculpt" geometry, but having no reliable way to actually judge depth.
imagine trying to physically sculpt on the flattened uv geometry and trying to judge depth solely by how dark the shadow becomes. like drawing, but stupid, and the shadow is a shade of purplish green and changes depending on the angle.
can you do it? yes, but why? it's a dumb thing to do when you could be LITERALLY working in 3D, instead.
I love how you think you're so smart by intentionally gimping yourself and making your life harder for literally no reason at all.

>> No.967282

>>967252
Yes.

>> No.967283

>>967279
>the blue channel in tangent-space normals is literally 1
No. It is the value that is needed to bring the total length of the RGB vector to 1.

>> No.967284
File: 145 KB, 1382x1416, whyBlue.jpg [View same] [iqdb] [saucenao] [google]
967284

>>967279
>The blue channel in tangent-space normals is literally 1.

Incorrect. Only time your blue channel is supposed to show a length of 1 in the Z axis is when the length of the Red and Green channel XY is exactly zero.
For any other value blue/Z should decrease such that the length of the vector described by the normal map has unit length.

Think of the normal map as a vector. A neutral surface normal has direction XYZ(0,0,1) in a tangent space map this is RGB(127,127,255).

Your shader will import the normal map and unpack it depending on what tangent space you use.
MikkTspace is common these days (but legacy with tangent and binormal mesh information stored is the best for quality).

Say we want a normal that points 45 degree upward towards Y in our normal map. How long is this vector?
If you set it up in any 3D editor you'll find it's XYZ(0,0.707,0.707). That maps to RGB(127,191,127).
If you send your 3D software white in the blue channel it decodes as XYZ(0,0.707,1). Create that vector and measure it.
It's longer than 1 unit, so when your shader normalize this vector it no longer describe a slope of 45degrees but a more shallow one.
Meaning your normals will end up looking a lot more flat than they do in a quality map.
>I love how you think you're so smart by intentionally gimping yourself and making your life harder for literally no reason at all.

It's not very important how smart anyone think they are, it's more about the quality of what we put out there.
I didn't chose your post in particular to belittle you in particular by showing just how wrong you are.
You've been chosen as an example of all these false experts out there who unwittingly end up misinforming
people about things you don't understand that well yourself.

Anyone who has this tool in their skill-set has options and capability other artist won't.

>> No.967351

Epic Games made normal maps obsolete with Nanite. it's over. this thread is over.

>> No.967363

>>967351
memite

>> No.967365

>>967351
Epic games made your fatass mom manageable with nanite.

>> No.967366 [DELETED] 

Can't wait to download terabyte games because thanks to nanite every shitty barrel is a sculpt and it's mesh alone is 500mb, at least I can finally see that 3d detail!

>> No.967371

>>967351
Epic Games wasted 10s of billions on their game store which doesn't even get regular generic AAA slop releases anymore.

>> No.967381

>>967351
Oh yeah, whatever happened to nanite? It's been several years now, have anything substantial been released that actually uses it?

>> No.967465

>>967279
>the blue channel in tangent-space normals is literally 1
Setting aside how redundant and pointless it would be to store a constant value in a color channel when you could put those bits toward higher precision in the other channels or simply save them entirely, you can literally visually see it isn't always maxed out if you've ever looked at a normal map before and aren't blind

>> No.967474

>>967381
I don't remember any substantial game being announced at all, besides GTA6 trailer which I didn't even bother to watch

>> No.967477

>>967474
Substantial as in complete game AAA studio type production. All I've seen is demos.

GTA6 isn't unreal, Rockstars games run on their own inhouse 'RAGE engine'.

>> No.967494

>>967351
No they are not, normal maps still help for tiny details. You just don't need normal maps for large details with nanite/mesh shaders.