Implementing a shader API

[Jacky Guo]

Regarding the shader API, if an error occurs during shader compilation,
should it simply default to the basic Phong shaders or throw an Exception
(likely in a new package with other shader stuff)?

I'm also very clueless as to how JavaFX links D3D shaders at runtime. Can
someone give me a quick rundown on that?

On Wed, Mar 17, 2021 at 9:06 PM Dan Howard <sproket at videotron.ca> wrote:

> This is cool. You should like up with Almas Baimagambetov
>
>
> https://github.com/AlmasB
>
>
> On 3/15/2021 10:12 PM, Jacky Guo wrote:
> > Regarding uniform parameters (i.e. variables set from Java and called on
> > the shader):
> > Since OpenGL's data passing uses locations, you could simply store a map
> of
> > uniform parameters (or whatever their JSL equivalent is) to their
> > locations, and call the required methods and perform the necessary
> > type-safety checks.
> > For D3D, you would still use the parameter map, but only for type safety.
> >
> > This is assuming I understand how the APIs work and I am not overlooking
> > something crucial.
> >
> > On Mon, Mar 15, 2021 at 4:51 AM Nir Lisker <nlisker at gmail.com> wrote:
> >
> >> I've thought about this too for a bit. My question would be how to tell
> >> the CPU what data to pass to the shader. Take OpenGL for example:
> writing
> >> an API to pass a shader and compiling it in runtime is not hard, but you
> >> need the CPU side to feed the shader its parameters. You would need an
> API
> >> for arbitrary data that the shader has been preconfigured to handle.
> That's
> >> quite an undertaking.
> >> And what level of flexibility is this going to give? The shader might
> >> require data that the public Java API does not expose, so you are
> limited
> >> in that regard too. When I wrote the enhancements for the shaders, I
> also
> >> had to change the Java side, which you won't be able to do.
> >> On the D3D side, the shaders are precompiled, so it's a slightly
> different
> >> story.
> >>
> >>    - Can high school students sign the OCA? (I saw the job title field
> >>> on the form and wasn't so sure I was legally allowed to sign it)
> >>
> >> Maybe ask on adoption-discuss at openjdk.java.net.
> >>
> >> On Mon, Mar 15, 2021 at 1:50 AM Michael Ennen <mike.ennen at gmail.com>
> >> wrote:
> >>
> >>> I messed around with adding features to JavaFX's "JSLC" (Java Shader
> >>> Language Compiler) which currently is only used
> >>> at compile-time for JavaFX to convert "JSL" shaders to various platform
> >>> dependent shader languages (GLSL, HLSL, etc.).
> >>>
> >>> In my opinion the ideal way to implement a public shader API would be
> to
> >>> extend JSLC to be able to be used either
> >>> at user application compile time, or more ideally, at application
> run-time
> >>> to dynamically generate platform dependent shaders
> >>> depending on what platform JavaFX is running on. Then a JavaFX
> application
> >>> developer can write platform independent
> >>> shaders in JSL. This would be quite a large undertaking and have a high
> >>> burden of maintenance to keep it current with
> >>> fast moving shader languages.
> >>>
> >>> I was able to convert JSLC grammar to antlr4 (from the previous antlr3
> >>> version) in this merged commit (pre-dates the move
> >>> to Github):
> >>>
> >>>
> >>>
> https://github.com/openjdk/jfx/commit/52adea7c3635656421db766641416ff28213928f#diff-9c8e9478200eb2c014c196feec63537046751c0d6fe80f90b8506b11abfcc2f7
> >>>
> >>> I then took advantage of a new feature in antlr4 which allows for
> >>> extracting embedded actions from the grammar definition file to a
> visitor
> >>> class:
> >>>
> >>>
> >>>
> https://github.com/openjdk/jfx/commit/8889330cc30a47361d47519be2ec662fb5ebe856#diff-9c8e9478200eb2c014c196feec63537046751c0d6fe80f90b8506b11abfcc2f7
> >>>
> >>> I then, in a test repository did some work in fleshing out what it
> would
> >>> take to implement more features for JSLC which you can find (as messy
> >>> commits) here:
> >>>
> >>> https://github.com/brcolow/jslc
> >>>
> >>> That's just my two cents on how a public shader API should best be
> added
> >>> to
> >>> JavaFX, by building on previous work that exists in the source code
> >>> repository but is only
> >>> used in a very limited and small way - but there is much potential
> there
> >>> and I believe the original author of JSL's intent was to have it be a
> >>> public API feature to allow
> >>> JavaFX developers to write platform independent shaders in JSL.
> >>>
> >>>
> >>> On Sun, Mar 14, 2021 at 3:32 PM superminerJG <jackyguo579 at gmail.com>
> >>> wrote:
> >>>
> >>>> Hi everyone.
> >>>>
> >>>> This problem might have been discussed numerous times, and has been
> held
> >>>> off for quite a while.
> >>>>
> >>>> Although we are starting to see lighting improvements added to
> JavaFX, I
> >>>> feel that it's necessary for JavaFX to have some kind of custom shader
> >>>> pipeline. However, nobody has gotten around to doing it, so I thought
> >>> that
> >>>> I could lend a hand. Before I get into things, I would like to know
> how
> >>> and
> >>>> what I can contribute. The questions are at the bottom of the email.
> >>>>
> >>>> Thanks!
> >>>> - jgcodes
> >>>>
> >>>> Questions:
> >>>>
> >>>>     - Can high school students sign the OCA? (I saw the job title
> field
> >>> on
> >>>>     the form and wasn't so sure I was legally allowed to sign it)
> >>>>     - When I  implement the shader API, should it use some kind of
> GLSL
> >>>>     mapping, or should I try to extend JSL to work in 3D?
> >>>>     - Should I have sent this email to another mailing list?
> >>>>
> >>>
> >>> --
> >>> Michael Ennen
> >>>
>