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 <spro...@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 <nlis...@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-disc...@openjdk.java.net. > >> > >> On Mon, Mar 15, 2021 at 1:50 AM Michael Ennen <mike.en...@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 <jackyguo...@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 > >>> >
