<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">Mike Erwin <<a href="mailto:significant.bit@gmail.com">significant.bit@gmail.com</a>> wrote:<br>
> For the GL_FLAT task do you mean the screen space derivatives in fragment<br>
> stage? I think it's better handled earlier in the pipeline, by using flat<br>
> interpolation and per-primitive normals. There needs to be some agreement<br>
> between a flat shader and the mesh data feeding it to get the right results.</span></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">Brecht Van Lommel <span dir="ltr"><<a href="mailto:brechtvanlommel@pandora.be" target="_blank">brechtvanlommel@pandora.be</a>></span> wrote:<br>
</span>I think that if we can handle it in the fragment shader with<br>
derivatives, that would be the simplest solution? What would be the<br>
benefit of handling it earlier in the pipeline?</blockquote><div><br></div><div>More efficient, better results, and matches old glShadeModel behavior.</div><div><br></div><div>If the caller knows it wants flat shading, it can specify the flat version of the shader then feed data differently.</div><div><br></div><div>Or what you're saying: specify flat version of shader and feed the *same* data to it. Handle it in the shader.</div><div><br></div><div>Dammit, did I just volunteer for the GL_FLAT task? :)</div></div></div></div>