Feature request: (better) built-in management of tangent-space vectors

[Epihaius]

From what I gather from recent posts on the forum, new users tend to expect geometry generated with CardMaker to have tangent-space vectors (at least optionally), which doesn't seem all that unreasonable to me.
It might be worth adding this feature to CardMaker in particular (through a method called something like set_has_tangent_space_vectors), although it would probably make more sense to implement it for geometry in general, whether it's loaded from disk or generated procedurally.

But tangent-space management in Panda seems to be lacking in other ways, too.

For example, users might want to replace a normal map on a model with one that has a different direction along one or both texture axes. In this case, there should be a simple way to flip the corresponding tangent-space vector(s).

Another thing I've noticed (and this may actually be considered a bug), is that tangent-space vectors are not affected by a texture rotation. So if one calls set_tex_rotate(normal_tex_stage, 180.), then the apparent depth looks inverted (bumps look like dents and vice-versa), since the light source doesn't change position or orientation, but the shading seems inverted due to the rotation.

So in short, the following seem useful to have:

1. a NodePath, GeomNode or Geom method to compute tangent-space vectors (and extend the vertex format with the necessary columns), e.g. NodePath.compute_tangent_space();
2. NodePath, GeomNode or Geom methods to flip tangent-space vectors, e.g. NodePath.flip_(bi)tangent_vector();
3. automatic update of tangent-space vectors when a texture rotation is in effect.

Not sure if the realization of any of these suggestions is feasible, but I thought it was worth bringing this up anyway.

[Moguri]

I would just like to add that 1 would be very useful for panda3d-gltf and likely other importers that are not based on EGG/ptloader.

[rdb]

Definitely not opposed to adding set_has_tangents to CardMaker and to a way to automatically generate tangents given a normal and texcoord set.

We may want to consider #546 and how it will impact this, since it may add a different scheme for storing tangents. Do we then only support the new scheme, or offer a choice of what scheme to use?

[Moguri]

I think 1 is unaffected by #546, but this does raise an interesting idea. Can the munger also generate a tangent column if one is missing and the shader needs it? Whatever function the munger uses to calculate tangents could also be exposed for users to call manually when generating a column themselves.

[rdb]

1 is affected by #546 inasmuch as we would need to decide whether it makes sense to support computing tangent space using the new scheme only, or using the old scheme, or perhaps to offer a choice.

Your idea to have the munger automatically generate it is interesting. (The munger could generate or convert the right set depending on whether the shader uses the tangent4 scheme or separate binormal/tangent, too). However, the munger would need to know which texcoord set corresponds to the normal map. It could probably fish this information out of the TextureAttrib. That does mean that right now, this feature would only be supported with the shader generator, not with custom shaders.

[Moguri]

Taking a better look at #546, I see that it does affect 1 since we go from a vec3 for tangent to a vec4. I was just thinking of the changes to binormal storage.

As for munging, I agree that we could compute the correct tangents and binormals based on the presence and type of p3d_BinormalN and p3d_TangentN. Could we also use the N portion of the uniform name to determine which texture coordinates to use? If vec4 p3d_Tangent0 is requested, then we can use the tangent4 scheme and use the data that would get sent to p3d_MultiTexCoord0. If no N is specified we could check to see how many UV sets are available. If one, just use that. If more than one, then raise a warning (or maybe an error) that we couldn't figure out the right thing to do. I think without covering this last case, this feature could still be very useful and handle most people's use case.

[rdb]

2. NodePath, GeomNode or Geom methods to flip tangent-space vectors, e.g. NodePath.flip_(bi)tangent_vector();

We currently have scale_color in GeomVertexData. I would suggest that we added a more generic scale_column.

3. automatic update of tangent-space vectors when a texture rotation is in effect.

I think this should be the responsibility of the shader. If you have a super-simple sample program to reproduce this, please file a separate issue report.

[Epihaius]

We currently have scale_color in GeomVertexData. I would suggest that we added a more generic scale_column.

Sounds like a good solution to me.

I think this should be the responsibility of the shader. If you have a super-simple sample program to reproduce this, please file a separate issue report.

Done.