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

Name
Options
Comment
Verification
4chan Pass users can bypass this verification. [Learn More] [Login]
File
  • Please read the Rules and FAQ before posting.

08/21/20New boards added: /vrpg/, /vmg/, /vst/ and /vm/
05/04/17New trial board added: /bant/ - International/Random
10/04/16New board for 4chan Pass users: /vip/ - Very Important Posts
[Hide] [Show All]


Janitor acceptance emails will be sent out over the coming weeks. Make sure to check your spam folder!


[Advertise on 4chan]


File: eyes.png (1.41 MB, 1765x1287)
1.41 MB PNG
I have this problem of wanting the iris to be a flat image projected onto a 3D mesh of an eyeball, but also, that loses the 'bowl' like effect of how an iris catches light.

At the moment, I have the vectors of the normal flipped along an axis decided by the bone that controls the eyeball: E.g., the "forward" direction of the iris is preserved, but down becomes up, and left becomes right.

This works to create the bowl effect, but it has a requirement: Each eye must have its own material, individually connected to each eye bone of each armature. Effectively speaking, it cannot be scaled up without loads of work.

How does Blender actually handle normals when geometry moves? Ideally I could bake the flipped iris, but when the eyeball moves, it doesn't preserve it. Only by rotating the geometry normals along the eye bone axis does it correctly work. Has anyone else dealt with something like this?
>>
File: eye normal.jpg (597 KB, 2508x1949)
597 KB JPG
This is what I mean by rotating along a bone.

The top eye, in weird colors, is how the driver shader flips the normals based on where the eye bone is looking, and works correctly.

However, I cannot bake a normal map (or don't know how) that will do this automatically for me. As I understand it, the normal simply looks at how much the geometry protrudes or depresses relatively to the surrounding geometry, then bakes the angles onto the faces.

Since it's a sphere, it doesn't do that. The normal map is just a blank lavender, which means it's doing nothing. I cannot bake the above eye image and plug that into normals, because it's effectively adding a second normal vector on top of the world space light calculation.

E.g., the eye rotates at 45 degrees along the Z axis (say, looking left). The ~ACTUAL~ normal, relative to the iris, is < 0.707, 0.707, 0 >. It's color, if normals are made as RGB values, will be 0.707 red, and 0.707 green. However, the color map will also rotate, which adds 0 red, and 1 green, making the final normal < 0.707, 1.707 > so it's just bad math

~~~

I'm looking how blender bakes normal maps, and a flat surface is 0.5 R, 0.5 G, 1 B, which I cannot understand fucking at all. A flat surface points straight up, which is Z, right? I am thinking of just baking a flat circle on a plain color image of said lavender value, but flipped. How on earth do I flip that?
>>
File: eye_flip.png (559 KB, 1911x1014)
559 KB PNG
If you connected the modified normal to the shader that's set to be the output during baking, baking a tangent space normal map should work. I did pic related, is that what you're trying to achieve? I was baking with the "Mix" node's output plugged into the "Normal" input of the shader. And then plugged the baked result into the normal again to test. The only gotcha is that you need to bake in the rest position, because the axes are aligned with world space only in that position.
+Make sure the image is set to XYZ/Linear/Non-Color mode and NOT sRGB. Normal maps are linear.

That's just a default cube, subdivided twice and spherified. I delimited the "iris" by raw y position since it's basically -1 to 1 in all directions, so assuming you have a character you'll have to use your texture as the blending factor instead of that. You shouldn't need to use your bone rotations for baking at all, assuming you just want to flip two axes you can just do it manually in rest position.

Basically, every vertex stores a normal and a tangent. Along with the derived binormal (by crossing the other two) the three define the X, Y and Z "orientation" of every vertex. If all you want is basic normal-dot-light shading, you only need the normal: you have a light direction and the linearly averaged normal of every pixel within the polygon. But for normal maps, you need the tangent as well - because otherwise you'd not know where left/right and up/down are. Normal mapping bends the interpolated normal along its axes, according to the values on the normal map. Neutral is "lavender" because red and green are 0.5 (meaning 0, as image colors range from 0-1, while axes go from -1 to 1) and blue is 1 because it points straight up.

Also, do irises really catch the specular that way because they "dip" that much inwards? I thought that was because there's actually a transparent "pill" over the iris that visibly "pops out" and catches the spec just like a soap bubble would.
>>
>>1029985
>which I cannot understand fucking at all. A flat surface points straight up, which is Z, right?
normal vectors are actually -1 to 1 but textures can't do that so it's instead bounded to 0-1 with 0.5 being neutral
so you're right, it's a tangent vector sticking straight out of the mesh surface at any given point

the way you baked it seems fine to me (plugging mix into normal vector input) since you're starting with the normal vector and your baked texture looks fine in the bottom left but obviously something weird is going on in the viewport. i'm not particularly experienced with making those kinds of eye shaders though so i'm not sure what's wrong with it :)
maybe look up how game eye shaders work because plenty of games use the same 1 sphere eye technique (vs a cornea mesh + concave iris/sclera mesh) and still get the iris depth effect
>>
File: eye context.jpg (1.17 MB, 2508x3926)
1.17 MB JPG
>>1029989
>normal vectors are actually -1 to 1 but textures can't do that so it's instead bounded to 0-1 with 0.5 being neutral

Thank you so much, that explains it

>baked texture looks fine in the bottom left but obviously something weird is going on in the viewport

The shading is weird because my normal map wasn't implemented correctly >>1029987 so the diffuse is warped and broken.

>maybe look up how game eye shaders work because plenty of games use the same 1 sphere eye technique

Well, the trouble is, basically all source game imported eye shaders have the weird effect you noticed. They're ALL broken in the same way. Hence I wanted to build something of my own from scratch to actually learn program is doing

>>1029987
Pic related is what I'm trying to achieve, it's a big image but it should clear up context/confusion

>do irises really catch the specular that way because they "dip" that much inwards?

Real eyes "catch" light that way from subsurface scattering. This creates an effect that a convex bowl of geometry can spoof, which is much lighter weight and doesn't require raytracing. I thank you for showing me how to bake Normals correctly. It's not working for me thought, and if you could look at what my setup is (I tried copying you precisely, but mine is a sphere, yours a cube) and if you have the time, let me know why it isn't working out. Ill include an image in a post right after this
>>
File: eye spoof.jpg (265 KB, 1715x1167)
265 KB JPG
>>1029987
>>1029993
For whatever reason, the normals won't bake correctly unless the eye is black? idk. Where you see the iris, it is white, and black on the sclera. I'm guessing that's screwing with the bake, but idk why. Your bake is this nice rainbow wheel, I have this yellow greenish disk, which I know is likely why it doesn't work. I will try again after work, but if you have any insight on why this wouldn't go through, do let me know. Thanks.
>>
File: weirdeyenormal.png (48 KB, 512x512)
48 KB PNG
>>1029985
i didnt pay enough attention to what your shader is doing to understand it, but i understand normals
blue is "meaningless". its like, height. you can just ignore blue for now.
red and green describe a pixel's "tilt". red at 0.5 is no tilt, 1 is tilted 45 degrees upways, and 0 is tilted 45 degrees downways
green 0.5 is no tilt, 1 is 45 degrees right, 0 is 45 degrees left.
together the red and green are describing the combined tilt of the pixel
NOW we can explain why its all kinda faded purple - its because that's the pixel tilt relative to the face's normal vector. RELATIVELY the UV map is saying "this pixel points wherever the face points". in the shader editor you can use a UV map node and set it to object or global space instead, but that makes things messy.

if it helps, try starting with a bump map and using photoshop or gimp to convert it to a normal map. this is just a flattened dome extruded from a flat plane (white blob on black background)
>>
File: weirdeyenormal2.png (351 KB, 1504x872)
351 KB PNG
is there a reason you cant just use a custom normal map?
>>
>>1029994
Nah, that setup isn't quite right, you're plugging the output of the "Mix" node where you're blending the actual flipped normal with the unmodified one. You need to connect the mix node to the "Normal" input of the "Diffuse BSDF" node directly and bake from that.

The "Normal Map" node expects a tangent space normal map (the "lavender" texture), not the actual normal you want your geometry to have.
Basically just remove the top "Normal Map" node and connect the "Mix" node directly to "Normal", and try baking again.
>>
Just color the Iris texture. Are you animating the fantastic voyage? How many pixels high will your irses be on screen at any given time?
>>
File: IT FUCKING WORKS.jpg (170 KB, 1633x1149)
170 KB JPG
>>1029995
>>1029997
AAAAAAAAAAAAAAAAAAAA IT FUCKING WORKS AAAAAAAAAAAAAAAAAAAAAAA
>>
>>1030007
Nice, way to go!
>>
File: WhyMakeGood3Ddurr.jpg (491 KB, 2560x1440)
491 KB JPG
>>1029999
I don't want to be too vitriolic anon, but this attitude you have is so common, and so stupid

>why not just paint the color on? Surely you won't be using too many pixels

What if I want to do multiple shots?
What if the scenes are different and thus have different lighting?
What if I'm making an actually large image?

I am a degenerate gooner, but the amount of trash I find online is mind-boggling. Sketchfab is a nightmare of frankenstein rigs, broken shapekeys, texture ripping, etc. Youtube tutorials are dominated by people who have no clue what they're doing, yet they learned how to speak with strong language and ooze confidence. The actually good tutorials are impossible to find, and I lucked out by finding anons here. Idc if you judge me, I had to go to reddit; they were no help. Blender forums, no help. I cannot believe random anons helped me finally get this. The youtube tutorials are dominated by obvious porn brains, and while I cannot judge my fellow coombrains, they are terrible, but the algorithm pushes their trash content to the top, because it's softcore porn and everyone's clicking on it.

I don't want to make trash that gooners will fap to because their standards are so low. Yes I'm making goonbait, but I want the eyes to work, I want them to work in multiple scenes with different lighting, I want them to not suck my memory and make my computer slow to a crawl, and if someone sees my content and doesn't care to goon to it, I WANT them to SAY, "Wow, that's an excellent model, look at how beautiful and deep her eyes are, how her skin glows, how she's posing". I want to blow people away.

So uhh no, I'm not going with a half-assed solution from a faggot who doesn't actually know how to do anything



[Advertise on 4chan]

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.