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 >> >
