在GH中用Python实现evaluate surface功能，发现有些面法向方向反了。请问是什么原因呢？
自己编写的python代码和结果如图，有一个面的法向向量错了。正常的应该都是朝上的。
1：请提供犀牛和GH文件
2：如果不提供文件，请提供完整截图显示你的GH，同时证明这些曲面“应该”朝上
这是在rhino界面中执行“分析方向”命令的结果，以证明正面朝上。有错误的那个面，是由最右边这个面mirror而来的。发现经过mirror后的面都有这个问题。
先放一下解决方案：
请仔细观察dir命令后，最左侧曲面（你用mirror镜像右侧曲面的结果）的白色方向箭头的反向，是否有一个蓝紫色的短线。
该短线表示此曲面经过了镜像，镜像原本会改变曲面的方向，但是犀牛会自动将其反转。
反转后的法向和UV并不构成原本的螺旋定则，（紫色的那个才构成螺旋定则）
如果你使用list命令查看镜像后的曲面，会在列表中找到
“face[ 0]: surface(0) reverse(1) loops(0)”
大概在下图的进度位置
以曲面为操作对象进行NormalAt时，会返回紫色的线，也就是遵循螺旋定则的曲面“真”方向。
而使用BrepFace为操作对象进行NormalAt时，会返回白色的线，也就是曲面的“修正”方向
关于此问题的详细请查看该帖子的倒数第二个开发者回帖
注意Dale回复的代码第二段中，同时进行了BrepFace.NormalAt操作，和判断BrepFace是否反转的操作（如果BrepFace反转则反转结果向量）。该操作的结果是返回曲面的“真”法向。
对你的应用来说，如果你需要的是曲面的“修正”方向，则只需要使用BrepFace.NormalAt即可，而不用额外增加判断的操作。
2 个赞
这个问题可能会很难理解，如果有任何问题欢迎随时提问。我会尽可能解释清晰。
简单总结一下，镜像这个操作属于特殊操作：
为了满足用户的需求，让用户不至于镜像了个寂寞（镜像了但是把面给反过来了）：镜像后的新曲面的法向-U-V三者关系和原来的宇宙不同了。可以理解为，为了用户需求局部创建了一个平行宇宙。
在这个宇宙下，用户看起来这个面镜像了，方向也对的，UV也是镜像的。但其实内部逻辑已经和原来不同了。这种暂时的”错误“逻辑，在用户使用Surface.NormalAt时，会用正确的逻辑（用U和V计算右手螺旋定则）返回曲面的法向（犀牛命令中紫色短线的方向），在用户使用BrepFace.NormalAt时，会用平行宇宙的逻辑返回一个用户可以直观接受的曲面法向。也就是你犀牛中dir命令白色箭头的方向。
感谢在深夜帮忙排查问题，蓝色短线在之前给出的图片中可以被看见。所以，产生该问题的原因还是在于法线方向与“右手螺旋定则”有关。我的目标是得到跟Rhino界面一致的“修正”方向。
我自己尝试的代码如下。官方的解释文档基本上都是C#的，python的教程好少，泪目！
bf = Brep.Faces[0] #输入端用Brep类型
v = Rhino.Geometry.BrepFace.NormalAt(bf, 0.5, 0.5)
用我给的代码就可以了，既然获取了brepface为何不直接接上 normalat呢，你的第二句话完全没有意义啊。
在这句话里c和py的写法几乎是一样的。唯一的区别应该是c多了一个分号。
是的，我是新手，之前不知道这种简洁的方式在GHPython中也能行。
我给出的代码是看着Rhino开发文档的网页版一点点试出来的。在每一次按下点号时，都会自动弹出来相关命令，按下括号会提示里面的数据要求，这样对新手来说比较友好。不过后来我在python中编写一些功能的命令，对比了一下python和原装电池的速度，发现python还是有点慢，并不是自己编程就能节省计算量，坑越挖越多。 
建议将有限的时间多花一点在GH自身的功能上，当无法满足需求时再去考虑二次开发。
对于运算效率来说，不论是C#还是py运算器都会有比较大的损耗，要想减少损耗，就得用Visual Studio。
看了一下你的代码，很多计算机程序的基本概念还没有掌握，如果想坚持做二次开发，基础部分必须补上。
1 个赞