Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [51258] trunk/blender: Cycles: Anisotropic BSDF enabled, with tangents now computed from the active UV map.
For aniso lighting computing tangents at vertex level is a total dead-end.
Not the way to go.
You want to compute the tangents at pixel level from the underlying
parametrization chosen.
It's the best way to significantly reduce the impact of the inherent
singularities which completely destroy the per vertex averaged tangent.
On Thu, Oct 11, 2012 at 4:43 AM, Brecht Van Lommel
brechtvanlom...@pandora.be wrote:
It's working the same as blender internal currently, but I agree it
should be improved. This anisotropic BSDF node will get a tangent
input socket, and probably the geometry node should always output the
tangent from generated coordinates. I'm not sure yet where the tangent
from UV maps fits, if that should be its own node or maybe becomes
part of an existing one.
Brecht.
On Thu, Oct 11, 2012 at 2:10 AM, Daniel Salazar - 3Developer.com
zan...@gmail.com wrote:
This works really nice but I'm not sure about the implementation.
Making the assumption that if there's an UV that should be used to
generate tangents is no good. If I have UVs for a diffuse map how can
I make the aniso bsdf not use them for tangents but keep using the
default method? Also if I have multiple UV layers how can I pick the
one I want to be used as tangent source?
cheers
Daniel Salazar
patazstudio.com
On Wed, Oct 10, 2012 at 7:02 AM, Brecht Van Lommel
brechtvanlom...@pandora.be wrote:
Revision: 51258
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=51258
Author: blendix
Date: 2012-10-10 13:02:20 + (Wed, 10 Oct 2012)
Log Message:
---
Cycles: Anisotropic BSDF enabled, with tangents now computed from the
active UV map.
It's using the Ward BSDF currently, which has some energy loss so might
be a bit
dark. More/better BSDF options can be implemented later.
Patch by Mike Farnsworth, some modifications by me. Currently it's not
possible yet
to set a custom tangent, that will follow as part of per-bsdf normals
patch.
Modified Paths:
--
trunk/blender/intern/cycles/blender/blender_mesh.cpp
trunk/blender/intern/cycles/blender/blender_shader.cpp
trunk/blender/intern/cycles/kernel/kernel_montecarlo.h
trunk/blender/intern/cycles/kernel/kernel_shader.h
trunk/blender/intern/cycles/kernel/kernel_types.h
trunk/blender/intern/cycles/kernel/svm/bsdf_ward.h
trunk/blender/intern/cycles/kernel/svm/svm.h
trunk/blender/intern/cycles/kernel/svm/svm_closure.h
trunk/blender/intern/cycles/kernel/svm/svm_geometry.h
trunk/blender/intern/cycles/kernel/svm/svm_types.h
trunk/blender/intern/cycles/render/attribute.cpp
trunk/blender/intern/cycles/render/graph.cpp
trunk/blender/intern/cycles/render/graph.h
trunk/blender/intern/cycles/render/nodes.cpp
trunk/blender/intern/cycles/render/nodes.h
trunk/blender/intern/cycles/util/util_types.h
trunk/blender/source/blender/blenkernel/intern/node.c
trunk/blender/source/blender/makesrna/intern/rna_nodetree_types.h
trunk/blender/source/blender/nodes/CMakeLists.txt
trunk/blender/source/blender/nodes/NOD_shader.h
trunk/blender/source/blender/nodes/shader/nodes/node_shader_bsdf_anisotropic.c
Modified: trunk/blender/intern/cycles/blender/blender_mesh.cpp
===
--- trunk/blender/intern/cycles/blender/blender_mesh.cpp
2012-10-10 12:54:36 UTC (rev 51257)
+++ trunk/blender/intern/cycles/blender/blender_mesh.cpp
2012-10-10 13:02:20 UTC (rev 51258)
@@ -33,6 +33,28 @@
/* Find/Add */
+static float3 tri_calc_tangent(float3 v0, float3 v1, float3 v2, float3
tx0, float3 tx1, float3 tx2)
+{
+ float3 duv1 = tx2 - tx0;
+ float3 duv2 = tx2 - tx1;
+ float3 dp1 = v2 - v0;
+ float3 dp2 = v2 - v1;
+ float det = duv1[0] * duv2[1] - duv1[1] * duv2[0];
+
+ if(det != 0.0f) {
+ return normalize(dp1 * duv2[1] - dp2 * duv1[1]);
+ }
+ else {
+ /* give back a sane default, using a valid edge as a
fallback */
+ float3 edge = v1 - v0;
+
+ if(len(edge) == 0.0f)
+ edge = v2 - v0;
+
+ return normalize(edge);
+ }
+}
+
static void create_mesh(Scene *scene, Mesh *mesh, BL::Mesh b_mesh,
const vectoruint used_shaders)
{
/* create vertices */
@@ -157,6 +179,67 @@
}
}
}
+
+ /* create texcoord-based tangent attributes */
+ {
+ BL::Mesh::tessface_uv_textures_iterator l;
+
+ for(b_mesh.tessface_uv_textures.begin(l); l !=
b_mesh.tessface_uv_textures.end(); ++l) {
+ AttributeStandard std = (l-active_render())?
ATTR_STD_TANGENT: ATTR_STD_NONE;
+
+
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [51258] trunk/blender: Cycles: Anisotropic BSDF enabled, with tangents now computed from the active UV map.
In case it's not clear. What I am saying is for actual uv unwraps use
mikktspace.
For a UV parametrization such as planar, cylindrical, spherical etc. use an
analytical
tangent evaluation at pixel level.
On Thu, Oct 11, 2012 at 12:44 PM, Morten Mikkelsen mikkels...@gmail.comwrote:
For aniso lighting computing tangents at vertex level is a total dead-end.
Not the way to go.
You want to compute the tangents at pixel level from the underlying
parametrization chosen.
It's the best way to significantly reduce the impact of the inherent
singularities which completely destroy the per vertex averaged tangent.
On Thu, Oct 11, 2012 at 4:43 AM, Brecht Van Lommel
brechtvanlom...@pandora.be wrote:
It's working the same as blender internal currently, but I agree it
should be improved. This anisotropic BSDF node will get a tangent
input socket, and probably the geometry node should always output the
tangent from generated coordinates. I'm not sure yet where the tangent
from UV maps fits, if that should be its own node or maybe becomes
part of an existing one.
Brecht.
On Thu, Oct 11, 2012 at 2:10 AM, Daniel Salazar - 3Developer.com
zan...@gmail.com wrote:
This works really nice but I'm not sure about the implementation.
Making the assumption that if there's an UV that should be used to
generate tangents is no good. If I have UVs for a diffuse map how can
I make the aniso bsdf not use them for tangents but keep using the
default method? Also if I have multiple UV layers how can I pick the
one I want to be used as tangent source?
cheers
Daniel Salazar
patazstudio.com
On Wed, Oct 10, 2012 at 7:02 AM, Brecht Van Lommel
brechtvanlom...@pandora.be wrote:
Revision: 51258
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=51258
Author: blendix
Date: 2012-10-10 13:02:20 + (Wed, 10 Oct 2012)
Log Message:
---
Cycles: Anisotropic BSDF enabled, with tangents now computed from the
active UV map.
It's using the Ward BSDF currently, which has some energy loss so
might be a bit
dark. More/better BSDF options can be implemented later.
Patch by Mike Farnsworth, some modifications by me. Currently it's not
possible yet
to set a custom tangent, that will follow as part of per-bsdf normals
patch.
Modified Paths:
--
trunk/blender/intern/cycles/blender/blender_mesh.cpp
trunk/blender/intern/cycles/blender/blender_shader.cpp
trunk/blender/intern/cycles/kernel/kernel_montecarlo.h
trunk/blender/intern/cycles/kernel/kernel_shader.h
trunk/blender/intern/cycles/kernel/kernel_types.h
trunk/blender/intern/cycles/kernel/svm/bsdf_ward.h
trunk/blender/intern/cycles/kernel/svm/svm.h
trunk/blender/intern/cycles/kernel/svm/svm_closure.h
trunk/blender/intern/cycles/kernel/svm/svm_geometry.h
trunk/blender/intern/cycles/kernel/svm/svm_types.h
trunk/blender/intern/cycles/render/attribute.cpp
trunk/blender/intern/cycles/render/graph.cpp
trunk/blender/intern/cycles/render/graph.h
trunk/blender/intern/cycles/render/nodes.cpp
trunk/blender/intern/cycles/render/nodes.h
trunk/blender/intern/cycles/util/util_types.h
trunk/blender/source/blender/blenkernel/intern/node.c
trunk/blender/source/blender/makesrna/intern/rna_nodetree_types.h
trunk/blender/source/blender/nodes/CMakeLists.txt
trunk/blender/source/blender/nodes/NOD_shader.h
trunk/blender/source/blender/nodes/shader/nodes/node_shader_bsdf_anisotropic.c
Modified: trunk/blender/intern/cycles/blender/blender_mesh.cpp
===
--- trunk/blender/intern/cycles/blender/blender_mesh.cpp
2012-10-10 12:54:36 UTC (rev 51257)
+++ trunk/blender/intern/cycles/blender/blender_mesh.cpp
2012-10-10 13:02:20 UTC (rev 51258)
@@ -33,6 +33,28 @@
/* Find/Add */
+static float3 tri_calc_tangent(float3 v0, float3 v1, float3 v2,
float3 tx0, float3 tx1, float3 tx2)
+{
+ float3 duv1 = tx2 - tx0;
+ float3 duv2 = tx2 - tx1;
+ float3 dp1 = v2 - v0;
+ float3 dp2 = v2 - v1;
+ float det = duv1[0] * duv2[1] - duv1[1] * duv2[0];
+
+ if(det != 0.0f) {
+ return normalize(dp1 * duv2[1] - dp2 * duv1[1]);
+ }
+ else {
+ /* give back a sane default, using a valid edge as a
fallback */
+ float3 edge = v1 - v0;
+
+ if(len(edge) == 0.0f)
+ edge = v2 - v0;
+
+ return normalize(edge);
+ }
+}
+
static void create_mesh(Scene *scene, Mesh *mesh, BL::Mesh b_mesh,
const vectoruint used_shaders)
{
/* create vertices */
@@ -157,6 +179,67 @@
}
}
}
+
+ /* create texcoord-based tangent attributes */
+ {
+
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [51258] trunk/blender: Cycles: Anisotropic BSDF enabled, with tangents now computed from the active UV map.
Hi, Replying a bit late because it seems this mail only just got through. On Thu, Oct 11, 2012 at 12:44 PM, Morten Mikkelsen mikkels...@gmail.comwrote: For aniso lighting computing tangents at vertex level is a total dead-end. Not the way to go. You want to compute the tangents at pixel level from the underlying parametrization chosen. It's the best way to significantly reduce the impact of the inherent singularities which completely destroy the per vertex averaged tangent. Ok, I can see we have an issue with singularities, but using mikktspace does not seem ideal for anisotropic shading. There's still many cases where you can line up the tangents quite well at UV seams even if the UV's are not connected, because the tangent can still match. Also at the the top of a UV sphere you can still get smooth results if you average with two neighboring triangles, but not the ones on the other side. As I understand it mikktspace is based on comparing UV coordinates, whereas we should actually be deciding merge/nomerge based on the difference between tangents in UV space, with some threshold. I hope that's accurate, correct me if I'm wrong. Thanks, Brecht. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [51258] trunk/blender: Cycles: Anisotropic BSDF enabled, with tangents now computed from the active UV map.
Ok, I can see we have an issue with singularities, but using mikktspace does not seem ideal for anisotropic shading. There's still many cases where you can line up the tangents quite well at UV seams even if the UV's are not connected, Generally this is not the case. It goes bad at least 95% or more of all cases where you try to just average tangents from an unwrap no matter what. Borders are splits when tangents aren't aligned so odds of this going well are close to non. results if you average with two neighboring triangles, but not the ones on the other side. That's not what happens though. What happens is that all the tangents surrounding the pole get added together. What you end up doing is stretching the highlight in a very distorted way across the entire top row of triangles. As I understand it mikktspace is based on comparing UV coordinates, whereas we should actually be deciding merge/nomerge based on the difference between tangents in UV space, with some threshold. If you were to try and achieve normal mapping using this approach then I can confidently tell you it's an awful solution. The idea has been tried and done to death by many of us game developers back in the day when the concepts of tangent space were still young. My recommendation is definitely that you use mikktspace for normal mapping. You use it for aniso as well if someone wants to use unwrap based tangents. And if someone wants to use orco then you synthesize the tangents. It's the only proper/stable/good way to do it. M.Fox. spend years on aniso in blender, studying various cases, and I am sure he can tell you first hand the per vertex averaged triangles just didn't work well. He was getting errors all the time. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [51258] trunk/blender: Cycles: Anisotropic BSDF enabled, with tangents now computed from the active UV map.
Hi, On Tue, Oct 16, 2012 at 7:16 PM, Morten Mikkelsen mikkels...@gmail.com wrote: Ok, I can see we have an issue with singularities, but using mikktspace does not seem ideal for anisotropic shading. There's still many cases where you can line up the tangents quite well at UV seams even if the UV's are not connected, Generally this is not the case. It goes bad at least 95% or more of all cases where you try to just average tangents from an unwrap no matter what. Borders are splits when tangents aren't aligned so odds of this going well are close to non. It depends if you use any UV map or a UV map designed for the tangent space. If you just use a UV map that was intended to map textures to the mesh it's fairly pointless, might as well generate it based on orco's then. There's very common cases where you can avoid a seam, any object that's roughly shaped like a sphere, cylinder or torus would have a seam which we can avoid in principle. results if you average with two neighboring triangles, but not the ones on the other side. That's not what happens though. What happens is that all the tangents surrounding the pole get added together. What you end up doing is stretching the highlight in a very distorted way across the entire top row of triangles. Right, that's indeed what it is doing now. But with mikktspace you also get a discontinuity between the triangles, so neither solution is perfect. I'm trying to think of a way to do better. As I understand it mikktspace is based on comparing UV coordinates, whereas we should actually be deciding merge/nomerge based on the difference between tangents in UV space, with some threshold. If you were to try and achieve normal mapping using this approach then I can confidently tell you it's an awful solution. The idea has been tried and done to death by many of us game developers back in the day when the concepts of tangent space were still young. My recommendation is definitely that you use mikktspace for normal mapping. This is not about normal mapping, for that I 100% agree we should use mikktspace. You use it for aniso as well if someone wants to use unwrap based tangents. And if someone wants to use orco then you synthesize the tangents. It's the only proper/stable/good way to do it. M.Fox. spend years on aniso in blender, studying various cases, and I am sure he can tell you first hand the per vertex averaged triangles just didn't work well. He was getting errors all the time. Ok, I'm still convinced we can do better than either, will try to figure it out. Brecht. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [51258] trunk/blender: Cycles: Anisotropic BSDF enabled, with tangents now computed from the active UV map.
The problem is not the sphere. The problem is the general case which will almost never work well with per vertex averaged tangents in the context of aniso shading. The problem is of course that almost any case of a discontinuity will give offensive discontinuities in the lit results because it's anisotropic. You will consistently be presented with two choices 1 is to average and one is to split and you will be screwed whether you do or you don't. I promise you there is no way you can get this to behave well in the majority of cases. What will happen if you introduce a threshold is that some vertices will pop and some will split. If you follow a UV border down the seam at the surface of the mesh (something organic such as a human head) this will basically look horrendous. You'll see it switching, going from vertex to vertex, between awful distortions in the spec or hard discontinuities depending on whether or not it averaged or split. There will exist no global threshold that will give you a nice looking result. On Tue, Oct 16, 2012 at 11:56 AM, Brecht Van Lommel brechtvanlom...@pandora.be wrote: Right, for a sphere you need a singularity at the poles, but you do not need a seam between them too. Brecht On Tue, Oct 16, 2012 at 8:34 PM, Morten Mikkelsen mikkels...@gmail.com wrote: Ok, I'm still convinced we can do better than either, will try to figure it out. Can't blame a man for trying :) Food for thought though: http://en.wikipedia.org/wiki/Hairy_ball_theorem The hairy ball theorem! It basically says that a tangent field on the surface of a sphere in an odd dimensional vector space must partition somewhere. Couldn't help bring it up since it's a classic :) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
