Check it out on itch.io here: https://award-games.itch.io/normalpicker

Since I'm always second-guessing myself about the colors when editing a normal map, and all the PNG helpers online aren't very good at conveying direction, I decided to make a little project to help assure myself that I'm painting with exactly the right color on my normal maps. For now I've just named it NormalPicker.

If xyz sees this post, they might recognize their grid shader. What license would you put on that, btw?

I'm trying to figure out the best way to be able to directly set an x, y, or z normal value and have the other two adapt. Looking for any suggestions. I could just find the nearest rotation which gets me that value. Or, since mostly only the front side of the sphere is cared about anyways, I could do a flat xy projection when I modify x or y. Then I'd update z accordingly and only the other of x/y if it would go outside the circle. Then maybe just do nearest rotation if z is modified?

Also not sure what the best control for that would be. Sliders?

I'll release this open source once I've finished it up a bit.

  • xyz replied to this.

    award You shouldn't be painting RGB encoded normals manually. That's kind of insane 😃. Use some tool with 3D brushes and realtime mapped preview.

    That said, for picking, a planar projection of the spehre is fine I guess, but you always need to specify at least two of x, y, z and calculate the third one.

    award If xyz sees this post, they might recognize their grid shader. What license would you put on that, btw?

    At godotshaders.com it says CC0. I think it means you can do whatever you want with it.

          xyz

          I'm doing it for low res 2D sprites. Not going for photorealism. All the tools I've tried have given me very muddy results.

          • xyz replied to this.

              award Ah, ok then. Might make sense to have something line this. But then why not make a tool where you draw pixels and have immediate normal mapped preview? Shouldn't be too hard to do. Although one of those advanced sprite editors might already have something like this.

                  xyz That's not a bad idea. I've been using Photoshop at the moment because the layer masks let me paint an "angle" and then adjust that angle all at once. If a sprite editor had your suggestion one might expect it would have layer masks as well. I should keep looking.

                    award You should make it interactive even when mouse is outside of the sphere. Position the cone at the very rim, closest to mouse arrow. Also print the actual normal vector components.

                        xyz Good idea. I can probably do that with just a quad rotated to line up with the rim.

                        • xyz replied to this.

                            award Beware that the plane the quad lies in doesn't go through sphere center. In fact its offset from center varies depending on camera distance from the sphere. You'll need to calculate it.

                              I think I figured out the math for it but I'm getting weird results so I'm not sure where I'm messing up.

                              I have my quad and my camera attached to the same rotating pivot, which means I just need to get the Z value of where the quad should be based on the Z value of my camera. If the center of the sphere and the position of my camera are treated as antipodal points on another sphere, then where those two spheres intersect should be the tangent.

                              Since I'm only interested in the Z value and my sphere is at 0,0, I can use these equations:
                              https://mathworld.wolfram.com/Sphere-SphereIntersection.html
                              i.e. x=(d2-r2+R2)/(2d). (except that x is z for my purposes)

                              Because my r and d are equivalent, this reduces down further to just R2/2d

                              so all my code boils down to is:

                              var r:float = %Camera3D.position.z * .5
var R := .5 #sphere radius
z = (R * R) / (r + r)

                              which is so simple that it worries me. And like I said, I'm getting weird results, but that could also be due to bad math after handling the mouse events on the quad. Does my math for the quad placement seem correct though?

                              • xyz replied to this.

                                award You came to (almost) the right formula by a wrong assumption. r and d are not equivalent in the case of tangent because that would mean that PO and PT in your picture are the same length, which is not the case. However d² - r² in the sphere intersection formula is actually equal to R² (in the case of tangent). This boils the formula down to 2R²/2d, and further to R²/d. Your code for some reason divided d by two and then added it to itself to cancel that. So it actually does R²/d, which is correct.

                                The same can be devised using trig. Angle at P in triangle OPT is same as angle at T in triangle OQT. The sine of this angle is then OT/OP in first triangle and OQ/OT in second. We can establish the equivalence OT/OP = OQ/OT. If we write it using R and d, we get R/d = z/R, where z is our wanted distance. So z = R²/d. It's the same thing we've gotten from spheres/circles intersection formula.

                                All that said the z you calculated should be correct. The problem is likely elsewhere.

                                  award changed the title to NormalPicker - a 3D tool for picking normal colors. .