[Bf-viewport] OpenGL refactoring tasks

[Brecht Van Lommel]

Cycles and Blender Internal render non-planar n-gons tessellated into
triangles, so there's no need to have a single normal per n-gon I
think? For me flat normals means matching the actual geometry.

It just seems easier if we can always use the same geometry data,
except for cases where all faces in a mesh are flat and we can leave
out the normal data and save a little memory. If the shader requests
vertex attributes it is easy to keep the logic in the shader code
without the geometry code needing to be aware.

Efficiency could be a problem, dFdx / dFdy might have a significant
performance impact, though I wouldn't expect it.


On Fri, Dec 11, 2015 at 10:30 PM, Antony Riakiotakis <kalast at gmail.com> wrote:
> Handling it earlier means we get correct flat ngon normal support.
>
>
> On 11 December 2015 at 22:10, Brecht Van Lommel <brechtvanlommel at pandora.be>
> wrote:
>>
>> On Fri, Dec 11, 2015 at 9:55 PM, Mike Erwin <significant.bit at gmail.com>
>> wrote:
>> > For the GL_FLAT task do you mean the screen space derivatives in
>> > fragment
>> > stage? I think it's better handled earlier in the pipeline, by using
>> > flat
>> > interpolation and per-primitive normals. There needs to be some
>> > agreement
>> > between a flat shader and the mesh data feeding it to get the right
>> > results.
>>
>> I think that if we can handle it in the fragment shader with
>> derivatives, that would be the simplest solution? What would be the
>> benefit of handling it earlier in the pipeline?
>> _______________________________________________
>> Bf-viewport mailing list
>> Bf-viewport at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-viewport
>
>
>
> _______________________________________________
> Bf-viewport mailing list
> Bf-viewport at blender.org
> http://lists.blender.org/mailman/listinfo/bf-viewport
>