[prev in list] [next in list] [prev in thread] [next in thread]
List: flightgear-devel
Subject: Re: [Flightgear-devel] Allowing OSG to generate normals
From: James Turner <james () flightgear ! org>
Date: 2020-04-28 14:50:36
Message-ID: C98973E7-BF6B-43C6-9F37-B4C5462F1B77 () flightgear ! org
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> On 28 Apr 2020, at 15:17, James Hester <jamesrhester@gmail.com> wrote:
>
> Let me explain why I think this is minimally intrusive. First of all, there are \
> currently only 3 effects in fgdata/Effects (mirrored in Compositor/Effects) that \
> request normal generation, and none of them use those generated normals in the \
> shaders so the normal generation is pointless. It is true that third party aircraft \
> could define Effects that request normal generation. However, in that case they \
> would use those normals in a vertex shader that was distributed with fgdata (I \
> assume Aircraft cannot provide their own shaders?). A grep for 'attribute' in the \
> fgdata/Shader directory reveals plenty of binormals and tangents, but never \
> normals.
Aircraft can supply their own shaders actually - potentially even a scenery model \
could, although it would be a little unusual.
> I understand the desire to be conservative when making such changes. How about a \
> less intrusive change that in all cases delivers the model/terrain supplied normals \
> to the Geometry, but if the Effect requests that normals are generated then those \
> generated normals are used for the binormal and tangent adjustment and are made \
> available as a separate attribute for Shader use?
That can work, but we might be careful about shaders where we're near the maximum \
number of attributes (16)
>
> On Tue, 28 Apr 2020 at 21:48, James Turner <james@flightgear.org \
> <mailto:james@flightgear.org>> wrote:
> I was hoping some aircraft developers who know the Effects system better might \
> respond, because unfortunately my feelings are a bit negative:
> - usually ‘explicit' normals are ‘better' and should take precedence over TSG \
> normals (this allows a modeller to have fine control, the TSG ones will always be \
> in the averaged location)
> And under the original proposal the explicit normals would continue to take \
> precedence, *unless* there was an explicit request to do otherwise by requesting \
> that TSG generate normals.
Ah okay, that part I missed. I agree it's much lower impact then.
> Certainly a new flag would be possible. I just have a feeling that it would be \
> unnecessary clutter as normal generation is currently a logical no-op, so any \
> current use of it is pointless.
I think this comes down to what degree we can be sure, it's really an no-op: if it's \
purely the places in FGData then I'd agree, but let's check at least the aircraft in \
FGaddon to get a better idea.
Kind regards,
James
[Attachment #5 (unknown)]
<html><head><meta http-equiv="Content-Type" content="text/html; \
charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; \
line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote \
type="cite" class=""><div class="">On 28 Apr 2020, at 15:17, James Hester <<a \
href="mailto:jamesrhester@gmail.com" class="">jamesrhester@gmail.com</a>> \
wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" \
class=""><div class="">Let me explain why I think this is minimally intrusive. First \
of all, there are currently only 3 effects in fgdata/Effects (mirrored in \
Compositor/Effects) that request normal generation, and none of them use those \
generated normals in the shaders so the normal generation is pointless. It is true \
that third party aircraft could define Effects that request normal generation. \
However, in that case they would use those normals in a vertex shader that was \
distributed with fgdata (I assume Aircraft cannot provide their own shaders?). A grep \
for 'attribute' in the fgdata/Shader directory reveals plenty of binormals and \
tangents, but never normals.</div></div></div></blockquote><div><br \
class=""></div><div>Aircraft can supply their own shaders actually - \
potentially even a scenery model could, although it would be a little \
unusual.</div><br class=""><blockquote type="cite" class=""><div class=""><div \
dir="ltr" class=""><div class="">I understand the desire to be conservative when \
making such changes. How about a less intrusive change that in all cases \
delivers the model/terrain supplied normals to the Geometry, but if the Effect \
requests that normals are generated then those generated normals are used for the \
binormal and tangent adjustment and are made available as a separate attribute for \
Shader use?</div></div></div></blockquote><div><br class=""></div><div>That can work, \
but we might be careful about shaders where we're near the maximum number of \
attributes (16)</div><br class=""><blockquote type="cite" class=""><div class=""><div \
dir="ltr" class=""><br class=""><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Tue, 28 Apr 2020 at 21:48, James Turner <<a \
href="mailto:james@flightgear.org" class="">james@flightgear.org</a>> \
wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div \
style="overflow-wrap: break-word;" class=""><br class=""><div class="">I was hoping \
some aircraft developers who know the Effects system better might respond, because \
unfortunately my feelings are a bit negative:</div><div class=""><br \
class=""></div><div class=""><span style="white-space:pre-wrap" class=""> </span>- \
usually ‘explicit' normals are ‘better' and should take precedence over TSG \
normals (this allows a modeller to have fine control, the TSG ones will always be in \
the averaged location)</div></div></blockquote><div class=""><br class=""></div><div \
class="">And under the original proposal the explicit normals would continue to take \
precedence, *unless* there was an explicit request to do otherwise by requesting that \
TSG generate normals. </div></div></div></div></blockquote><div><br \
class=""></div><div>Ah okay, that part I missed. I agree it's much lower impact \
then.</div><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div \
style="overflow-wrap: break-word;" class=""><div class="">Certainly a new flag would \
be possible. I just have a feeling that it would be unnecessary clutter as normal \
generation is currently a logical no-op, so any current use of it is \
pointless.</div></div></blockquote></div></div></blockquote><br class=""></div><div>I \
think this comes down to what degree we can be sure, it's really an no-op: if it's \
purely the places in FGData then I'd agree, but let's check at least the aircraft in \
FGaddon to get a better idea.</div><div><br class=""></div><div>Kind \
regards,</div><div>James</div><div><br class=""></div></body></html>
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic