next »

[Pit]

OK, that result is really weird, why did the normals only change x-wise but not y-wise? O.o

Is this the normal map you use? Because there's something weird about that too: if you take a look at the histogram the red and green values are mainly around 0.75, whereas they should be around 0.5 (unless your door is supposed to be inclined towards the top right corner, which I doubt). The confusing part is that while the normal map points towards the top right, the normals on the screenshots seem to point towards the bottom left.

Which leads me to another curiosity: dlan was right, it should be "posLight - gl_FragCoord.xy". Your result still seems kinda correct, so is there anyplace where you do something like "1.0 - normalDotLight"? If you do, the culprit might be the normal map since it's facing into the top right corner which then turns into the bottom left corner in the shader.

A screenshot where you write the normal values to the screen (as in the shadertoy) might be useful, just to finally be sure if there's something wrong with them or not

[BorisTheBrave]

So I sampled some colours from your example normal buffer on page 1, and got rgb normals pointing roughly as indicated:

Code:

Up   = 133, 231, 202
Down = 124,   0, 230
Left = 184, 102, 248
Right = 53, 131, 240

These don't correspond to any normal mapping scheme I can recognize, but at least it's clear that rgb is xyz.

What is going wrong I expect is you are mapping the normals wrongly, so rather than pointing roughly forward, with slight deflections, they are all angled very steeply in a particular direction (with slight deflections), hence only the half of the image is lit, being the half where that direction points towards the point light. It doesn't help that you've (implicitly) placed your light with z=0, so the expected result is a very oblique lighting.

You need to go into more detail on how you got your normals. Perhaps gamma correction is messing up the screenshot you sent us?

You say you got them from blender? If so, you are using the wrong normal mapping. Use this:

Code:

vec3 n = texture(normalmap, gl_FragCoord.xy / resolution).rgb;
vec3 normal = vec3(n.x * 2 - 1, n.y * 2 - 1, n.z);

(see here for details)

[oahda]

@Boris:
How would normals pointing in the wrong direction explain that the diagonal goes across the entire image, where the texture is repeated, tho? Wouldn't that, if anything, yield an individual diagonal within each tile? No idea about gamma correction.

I'll try your idea later either way. But could you please explain why I shouldn't be doing the *2-1 for z?

As for light at z=0, I've tried other values too. Only difference is that the diagonal gets smoother the bigger the value is, but that also removes the sharpness of the normal highlights and shadows, which is unacceptable.

@Pit:
That's one of them. There's another one for the wall, of course. You can find it in the thread for Vatnsmyrkr. I actually am applying something that makes the resulting normals less contrasted, but people online said it would be an incorrect map if that were not done. But I actually tried maps generated without doing that, and it made no difference. Perhaps Boris is onto something, tho. I'll check later. Not at the PC ATM. If Boris's advice doesn't work out I'll grab a screenshot of the normal buffer for you.

@Polly:
Got your PM but I'm unfortunately not on Windows. :c

[Pit]

How would normals pointing in the wrong direction explain that the diagonal goes across the entire image, where the texture is repeated, tho? Wouldn't that, if anything, yield an individual diagonal within each tile?

Since they all use the same point light, nope, there's one diagonal going through that light (respectively it has a distance to that light relative to the z value of the light position). If it's unclear what we mean: here's a picture with the light direction vectors (red) and the assumed normal vectors (green). As you can see, the pixels in the top right corner get a dot product of 0 or smaller (except for the few on non flat areas), whereas those in the bottom left corner get a value close to 1. If everything was correct they should in fact pretty much all be roughly 0, since your light is at z=0.

But could you please explain why I shouldn't be doing the *2-1 for z?

Since on a normal map the z values are always positive anyway, some tools (like Blender) use the full range of 0-255 to store that value. So in that case the pixel value already corresponds to the normal value and you don't need the *2-1 transformation. (the results are wrong if you still do it, but it shouldn't be the reason for the diagonal)

But I actually tried maps generated without doing that, and it made no difference.

Have you tried a simple blue texture? Nothing generated, just a plain old (128,128,255) filled bitmap? (if your light is placed at z=0 that should result in a black wall)

[Polly]

Should have done this sooner .. i plugged your diffuse & normal map into my example and it seems like it's a two-tiered problem. The wall seems to look fine ( which means that something is wrong with your deferred shader ), but the fish certainly doesn't .. so either you've generated the normal map for the fish incorrectly, or something is wrong with how you do your normal pass ( perhaps related to transformed / rotated objects ).

[oahda]

Well, since the submarine is from Blender and that wall isn't I guess Boris must be right. I've yet to put it to the test. Thanks!

Have you tried a simple blue texture? Nothing generated, just a plain old (128,128,255) filled bitmap? (if your light is placed at z=0 that should result in a black wall)

Yep, some time ago. Same issue. I haven't tried removing *2-1 yet tho.

[Pit]

Don't wanna smash your hope but if in that case the line still appears removing the *2-1 most probably won't fix it: if z=1 then z*2-1 equals 1 too, it's the one case where that actually doesn't make any difference at all^^

Oh, and the normals on the submarine are by the way so over the place, I actually thought that was just some placeholder. So all in all there might indeed be some issue with your normal pass (additionally to the normal maps that seem not quite right and the reversed "gl_FragCoord.xy - posLight").

[BorisTheBrave]

I'll try your idea later either way. But could you please explain why I shouldn't be doing the *2-1 for z?

This is from the blender docs:

     Normal maps in Blender store a normal as follows:

        Red maps from (0-255) to X (-1.0 - 1.0)
        Green maps from (0-255) to Y (-1.0 - 1.0)
        Blue maps from (0-255) to Z (0.0 - 1.0)

    Since normals all point towards a viewer, negative Z-values are not stored (they would be invisible anyway). In Blender we store a full blue range, although some other implementations also map blue colors (128-255) to (0.0 - 1.0). The latter convention is used in "Doom 3" for example.

the fish certainly doesn't ..

Just to check, you baked the fish normal to a plane, or rendered the normals directly, right? If you follow the instructions that show baking a hi-res model to a low res one, it won't work with your shader.

[BorisTheBrave]

I actually am applying something that makes the resulting normals less contrasted

Rage.

This is taking so long because you are not being forthcoming with data. Editing for length is a good idea of things are very long, but you've been teasing us with incomplete shaders, and not dumping out the raw inputs and outputs. Please. Asking for help on a forum entails doing a certain amount of legwork, and I don't feel you are holding up your end.

If you dump all the inputs, and the full shader, we could actually run your code ourselves, rather than this slow back and forth. Polly has made a rather heroic attempt to run it anyway.

[oahda]

I will, but I haven't been back on my PC yet but thought I'd reply as well as I could in the meantime. Don't know yet when I'm back on the PC, but I'll post stuff then unless I manage to solve it based on what has been written so far.

Here's the node setup I followed for Blender anyhow: http://blender.stackexchange.com/questions/14044/render-entire-scene-normals

Just to check, you baked the fish normal to a plane, or rendered the normals directly, right? If you follow the instructions that show baking a hi-res model to a low res one, it won't work with your shader.

So as you can see at the link above, I didn't bake to a plane, but rendered the normals directly.

[oahda]

Okay, if I add back the old wall texture, it actually seems to work perfectly fine for me as well, so I don't think there's anything wrong with the shader, and so it seems unnecessary to post the code.

The problem is obviously with Blender. I don't want to bake stuff, but directly render the normal map, so it's all about the node setup. So what's the proper node setup to render a conventional normal map in Blender?

I'd googled a bunch before I found the now seemingly incorrect setup linked above, and I've googled some more now, but I can't seem to find anything... It's a difficult thing to google anyhow, because it mostly tries to give me results on how to apply normal maps to meshes in Blender, or how to bake normals...

So, again, this is the node setup I'm currently using in Blender: http://blender.stackexchange.com/questions/14044/render-entire-scene-normals

[BorisTheBrave]

I agree with your assessment, just that we might have got it earlier.

Anyway. I've never rendered normals with Blender, just baked them. I fired it up and your stack overflow link seems entirely correct. So your node setup is fine I think.

Did you spot that comment in the stack overflow link about gamma adjustment? Could you give that a shot?

Edit: Just tried it myself and can confirm it's necessary to get anything useful out of blender. I'm disappointed, Blender's never let me down so hard before.

[oahda]

Holy... I'm embarrassed that I missed that the first time I found that link.

It seems to have done the trick:



Highlight/shadow contrast gets sharper the smaller the z position of the light now, so that's a nice tool for fine-tuning the look too. It's at 100 here.

Thanks to everybody who tried to help, and sorry for having being less helpful than perhaps I could've been. I always get the impression that people prefer that one asking for help tries to isolate relevant code and so on instead of uploading the whole codebase, so I didn't want to throw too much at you either and risk no replies at all.

But it was solved, it seems!

[joseph ¯\_(ツ)_/¯]

Hey this is wandering off topic a bit, but: I'd be interested to hear why you're jumping through rendering hoops instead of just baking the normal maps.

Baking has a lot of advantages -- you can bake matching diffuse/specular/alpha (alpha is probably most useful in your case, if you're making 3d models to sprites), it's easy to control scale and guarantee consistency, it's easily portable between different computers/blender installs, it's usually easy to set up scripts for, etc.

If it's just unfamiliarity keeping you away it's probably worth a day or two of learning time to save you future problems like this and streamline your process.

[oahda]

Since I'm using the normal render (disabling nodes) as the colour map (since the game is really a 2D game using normal maps to look 3D), it's convenient to quickly get the normal map in the exact same format and position by turning nodes on and rendering again. Then I can just open them both as perfectly aligned layers in GIMP and crop and edit them simultaneously. I prefer this workflow for my uses.

[joseph ¯\_(ツ)_/¯]

Since I'm using the normal render (disabling nodes) as the colour map (since the game is really a 2D game using normal maps to look 3D), it's convenient to quickly get the normal map in the exact same format and position by turning nodes on and rendering again. Then I can just open them both as perfectly aligned layers in GIMP and crop and edit them simultaneously. I prefer this workflow for my uses.

Okay, cool. I'd still recommend setting a plane up to bake to -- baking to a plane is exactly the same as what you're doing, with the plane taking the place of your camera, and less steps each time you re-render. In most workflows it will speed you up (one click to bake n maps with arbitrary settings) and make changes (changing  map needs, different render settings, different asset resolutions, etc) significantly easier down the line.

However, if your setup is fast enough for you and will be easy to scale up or automate if necessary: whatever works!

[BorisTheBrave]

Thanks to everybody who tried to help, and sorry for having being less helpful than perhaps I could've been.

I didn't mean to be too forceful. It's a difficult line to walk between too much and too little. But I'm glad things are resolved.

Rendering rather than baking makes sense for a 2d game, imho. I'm surprised Blender has no real support for doing what you want. I tried "bake to plane" instead, but then I remembered blenders baking tools are pretty crap too

[oahda]

…

Yeah, if it starts to get tedious and I need to change the settings between renders all the time I'll have to set it up differently. But now it's literally just one step between rerenders: check/uncheck the box that turns nodes on or off.

Thanks to everybody who tried to help, and sorry for having being less helpful than perhaps I could've been.

I didn't mean to be too forceful. It's a difficult line to walk between too much and too little. But I'm glad things are resolved.

Rendering rather than baking makes sense for a 2d game, imho. I'm surprised Blender has no real support for doing what you want. I tried "bake to plane" instead, but then I remembered blenders baking tools are pretty crap too

Well, I could copy the object to two render layers and modify the node setup to render only one layer as normals if I wanted to render them side by side, both colour and normals, but that would only save me seconds, so it's fine.