-
Notifications
You must be signed in to change notification settings - Fork 146
JDK-8217472: 3D-API - Attenuation-coefficients for PointLight #256
Comments
What you are looking for are attenuation factors. These need to be added at the native graphics pipelines level, which is a good amount of work. I can help with the D3D pipeline, but someone else has to do the others. As a workaround, you can find all the nodes a certain distance from your source and add them to the light's scope. It's not perfect, but it's something. Lighting and materials in general can use a lot of work, like adding directional lights and spotlights, an emissive component etc. |
Thanks for your reply, it would be very appreciated if you could help out with the D3D pipeline. The idea with adding the nodes to the scope came up to me as well, though the core problem of the light-emission still remains, with only the nodes in the scope being affected then of course. Well, i would gladly try my luck to work on these missing components then, since it is also in my interest to enchance the capabilities of my favourite framework :) |
SW is the software pipeline and it doesn't support 3D. Note that Apple are phasing out OpenGL support in favor of Metal. We'll need:
One thing that caught my eye while I was looking at the D3D implementation a while back was that the point light implementation is a custom one and not the point light given by the D3D API. I don't know why that is, maybe to unify the behavior across platforms. I'll re-ask about releasing Prism internal documentation. In any case, if you intend to work on OpenJFX you'll need to sign the OCA if you haven't done so already. |
I asked for the Prism documentations, but it's not guaranteed we'll get any. Meanwhile, I'll do some experimentation in d3d with the point light and see what kind of mayhem it causes. If you can try to meddle with the OpenGL pipline we'll get an idea of what we are up against. |
Evening, sorry for my long absence, job and building up the working environment. Also i sent the OCA to Oracle, approval stil needs to be given, after that i will public something here so you can check out my findings. Else i am working on this case, just to let you know. Cheers! |
Regarding the Apple's pipeline-change, we should try to settle this as fast as well, since it will surely affect how we should tackle our own matters. To add to that i would tend to Vulkan + MoltenVK, simply for the reason that by going this route we ensure a higher portability. |
Not really. It's not a formal agreement. One of the things the co-leads evaluate when we ask for permission to implement this is if someone will be able to maintain it. Otherwise, people will add their code and leave, leaving technical debt. If you plan to stay around (I certainly do) I guess it will be fine, but they will decide.
Good. It will take some time to be approved, but we can work meanwhile. It just stops you from submitting a PR/patch.
If I understand you correctly, the ES2 pipeline defines a custom point light instead of using the OpenGL functions? That's the case for D3D. The thing is, the material (I guess what you call shader) and lighting are coupled, so if I use the D3D PointLight implementation it won't affect the material. Is this what you mean?
Not sure which is worse :) The first one is more flexible and we might avoid inconsistencies between the pipelines, the second one has ready-to-use implementations but seems more ambitious.
Yeah, the graphics discussion has been brought up several times in the past, it will probably be brought up again when we start this discussion, and I'm guessing it will be brought up again after the work is done... #193
That's great. This week might be loaded for me but I'll try to squeeze in a research at an adequate level to get a better idea of what needs to be done on D3D. |
Then this wont be much of a problem.
ES2 surely uses the regular OpenGL light-sources, there should be no custom implementation of any lightings, as far as i know. But i proposed, that we could utilize the said "native OpenGL"-lightings via the shader (i recall it was possible to create light-sources in that way too) and thus "just" use the native lightings in OpenGL.
The materials are generally affected by the lights in a 3d world, if i am not mistaken. And a shader is basically a "little program" that is given to the GPU to execute (graphical) effects/results. And what i meant was that ultimately the shaders respsonsible for the lightning lack the attenuation factors in the calculation for the final output, so they either have to be added to the corresponding shaders or we add new shaders that extends said functionalities (unlikely and unfavoured for the moment)
I cannot speak for D3D, but for ES2 it should be enough to be able to retrieve all the necessary datas to set up its attenuations factors, the rest of it will be done via the said shaders. How exactly would you go on about working on your said options though?
The suggested route of the switch to ANGLE seems quite interesting... (http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-June/021973.html)
Same here, time is not benefical to me either. |
Just updating that after I discussed this with Ambarish (one of the Oracle devs), he gave me some reading material, so I'm doing the reading now. |
Happy new year! On my side, I worked out some modifications for the shaders, which was nothing great to be honest. Anyway, if possible i would like to modify my solution to be compatible with yours, if needed. Also could you provide me the said reading material you got as well? Thanks! |
Not sure on what level you are talking about. On the shader level, I passed the world coordinates from the vertex shader to the pixel shader. Then I mocked a light position and calculated the distance between them and divided the diffuse color value by the distance (up to a constant). I didn't do anything outside of the Prism 3D3 graphics pipeline yet as I was working towards a POC only. The solution requires to upgrade the shader models from 2.0 to 3.0, which is parallel to upgrading DirectX from 9.0 to 9.0c. This will require authorization by Kevin/Johan as it's a backwards compatibility issue.
Definitely. We need to think about the end result first. Attenuation is used only by some light types (https://docs.microsoft.com/en-us/windows/desktop/direct3d9/light-types):
So only they should have them. We will need 3 attenuation parameters (https://docs.microsoft.com/en-us/windows/desktop/direct3d9/attenuation-and-spotlight-factor) and a range parameter which is a hard cutoff for attenuation calculation. These will be The mathematical behavior for each light should be (in pseudocode):
Where the last 2 lines mean that the attenuation factor multiplies whatever the calculation was before. Optimizations not included. As for the Java side, I can take care of it, or at least most of it. Last time I looked I didn't foresee any problem there.
It's a collection of some very general to specific HLSL related links:
I'm going to start a discussion in [email protected], please follow it and chime in when needed. |
Some experimentation with SpotLight implementation: The red dot is the light source location. The light direction is +z (directed at the surface directly). The inner angle is 30 deg, below which the surface receives maximum intensity; the outer angle is 60 deg, above which the surface receives no light; the part between them is governed by a quadratic falloff using the formula given by Direct3D. Here the light direction is (1, 0, 1) (45 deg between +x and +z). Distance attenuation was not included for simplicity. |
I was interested in how you realized your POC, since you already established a way to render JavaFX property-changes to the D3D-renderer.
Sounds like a plan, i agree with it. The mathematics used in your shader seems solid, though with non-included optimizations: are you hinting to gamma issues by chance?
Fine by me.
Long due after my long absence. Gladly! |
Already on the next light type. One is having fun here as i see :P |
Actually I didn't tie it to the Java side yet, but that's not difficult. The attenuation and range numbers are passed to the native code just like all the other parameters such as light position and color.
Yes, the Java side is the same up to some point near the native calls. That part I'll do. When it diverges we might not be able to use a complementary structure because the native level could be very different, will have to look.
Not sure what is "the functionality of processing attenuation factors". The attenuation factors are passed as floats to the native level and only there processed.
How can you attenuate a light that has no position? What is the reference?
I looked at gamma correction, but didn't think of implementing it yet. We could look at it.
It's the angle. I do have a problem, though, with not illuminating other faces of the cube with this light, which could be a vertex shader issue.
The discussion is at: http://mail.openjdk.java.net/pipermail/openjfx-discuss/2019-January/000092.html |
Alright, i will leave the Java side to you then. From my side the ES2 shader-stuff is ready to be used. About to prepare some nice pictures of it too ;)
Skip what i said, i needlessly foresaw conflicts where there might not be some.
I think it was used as a way to change the general brightness if i recall correctly, so it acted kind of as a "light power" for ambient light. It is said that ambient light does in fact have a position, but one that isn't determinable anymore, since the light scattered off in all directions too many times (that's how it is stated at least) But this can already be achieved by providing a darker color to the light in JFX and we can skip it, just found the usage case curious.
Sure, i will help you out. Maybe the reference for how its done in OpenGL can help: https://www.tomdalling.com/blog/modern-opengl/07-more-lighting-ambient-specular-attenuation-gamma/
Not illuminating the other faces could have to do with the spot-light's ambient light component, since spot-light is supposed to use it partially.
Got it. |
We got the green light for attenuation factors and additional light types. We're starting with PointLight attenuation as discussed previously. Iv'e submitted JDK-8217472. There are 3 subtasks - I'll do 1 and 3, you are responsible for 2. You don't need to do anything in JIRA (as I said, the paperwork is on me), just open a pull request with the same name as the subtask and add a link to it. Your OCA should be approved by now, is it? There's still some coordination we need to do regarding the transition between the joint Prism layer (task 3) and the Prism pipeline-specific layer (tasks 1 and 2). We also need to choose names for the properties, which differ between specifications. |
I have my changesets ready. We need to decide on the exact public API, which is mostly the names of the new properties we're introducing. I plan to submit task 3 first, then I'll provide a test program (similar to the one in the images above) so we can make sure the effects look the same. |
Good day, had quite a long week.
Sounds good, then we will just test if my changes work on your program as well. |
What would be the other points we would have to clarify then? |
@kevinrushforth We need some help here.
Kevin, can you look into this please?
They have to conform to the Java naming conventions. So, we can do
Iv'e added the required parameters to
I think this was done because of a limitation of the D3D shader model. The number of variables that can be passed from the vertex shader to the pixel shader is limited, though it was capped at 3 where there was space for 1 more. After upgrading to Shader Model 3 we should be able to have 5. I could look into calculating the position of the lights on the pixel shader, which will allow dozens of lights, but I'm not sure about the performance change there. |
Found myself on the list today, seems everything is clear now.
Then how about just "constantAttenuation", etc.?
I see, so you practically did my work already :P
I remember you were addressing this issue on the JDK Bug System. |
That could work. I'll suggest an API (methods + their docs) in a followup comment. Once we approve it I'll submit a CSR.
Yes, the D3D and ES2 pipelines are the only ones that support 3D.
We'll probably need to write some tests. We'll see which when we get the patches ready. In the meantime, can you open a PR titled "[WIP] JDK-8217477: Add attenuation for the es2 pipeline" and put the link https://bugs.openjdk.java.net/browse/JDK-8217477 in the first comment? It doesn't have to compile yet, but it should once the connection between
That would be good. I'm not familiar enough with performance considerations. Though, are 4 or 5 lights per mesh not enough? Remember that it affects only meshes that are in the |
Sure, i will try to tackle this matter at weekend, as i do with the other matters here on GitHub.
It depends a lot on the complexity of the scene, for not so big or complex sceneries 4 to 5 lights would suffice definitely. Also surely we could move some of the work to the Java-side as well, but this surely will prove to be not very performant. I try to prepare everything needed in a short (as possible) time, so that we can finally have the first presentable results ready for other to use. |
Here is my proposed API. It will be accompanied by an update to the class documentation.
And similarly for |
I think this is a good start at the API for this, but need to review in more detail. I have a couple comments:
|
I added Point 3 is interesting. I would say:
So I see reasons for |
@FalcoTheBold Do you have any update? @kevinrushforth Can we continue with the review? |
@nlisker On it to upload content soon. |
@nlisker Alright, i built up a seemingly working flow from the JavaFX-side to the ES2 pipeline, albeit for the PR i will leave these JavaFX-parts out. In order for a PoC i modified the java/javafx/scene/LightBase-class, by adding the 4 properties with the previously discussed named convention (range, constantAttenuation, etc.) I will commit the ES2 changes to the PR later when i am back at home. |
@nlisker I created the PR now, though i made it a draft for the moment since smaller fixes need to be done yet. |
@nlisker At a later point today i will add the remaining Fragment-shader files, had them on another location and can upload them only after i got them from there. |
@FalcoTheBold
These changes are part of the Java layer, which I'm taking care of. I understand you need to make those too so you could test your changes in the native layer. I should have posted my changes so we could have the same framework to work with, it needs to go into review first anyway and it's been sitting waiting for the docs review, but we don't need the docs for this. In any case, your changes look very similar to mine, so that's good.
This is also part of the Java layer. They are chose to the attenuation is 1 to preserve backwards compatibility:
Good. This is the important part since this is where the actual visual behavior is and we need to make sure our implementations produce identical results.
I think so. The calculation is done for each light:
|
I presume you mean for the API (since the implementation is still WIP). Yes, that seems fine.
In that case, I prefer Once we have agreement on this, then the specification section of the CSR can be updated to indicate that the changes are for the |
Exactly, or at least to make sure i get a compilable result for the PR (which i havent yet, as seen in the PR)
Interesting, if by any chance the JavaFX-graphical quality would benefit thanks to that then i see no reasons not to consider such aspects 😀
Yeah, you are right, there i was thinking a little too high for this case.
All done, default values were changed and the shader-files added, albeit i am sure they will have to be edited again at a later point, since i took the same approach of calculating the position in the fragment-shader for the moment.
} Alright, thanks 👍 |
Sorry for the late reply, I've been busy recently.
I've started to lean towards @FalcoTheBold Please find here the patch files for the shared Java layer. There is a git diff patch file, or inside the Webrev you can find the rt.patch file and browse the changes. Whichever works for you. I remind you that the Also in that folder you will find the package "lighting test" which includes a test program consisting of 3 java files. Just compile and run them with the modified OpenJFX. The application will show a box and a light source as shown in the images above (the light source starts inside the box, so move the box back). Mouse drag pans the camera and holding control while dragging will rotate it. The rest you modify with the sliders or text fields. It's not pretty but it's functional. We will probably want to decide on some critical values and post what each sees using these values. though it would be best if someone has 2 machines side by side for comparison. |
That's fine, too. |
@kevinrushforth Iv'e put the CSR up for proposal. |
@nlisker Finally managed a working build for the pull request. I hope it is okay for you that i included your code for the Java-side as well, it wasn't building else for me.
Also thanks for the sources again. For the ES2MeshView, no problem, my old setup handled your changes without flaws.
I can provide that, i have both systems at my disposal (one lacking a monitor at the moment though). |
Yes, the Java side code will be submitted first anyway, so only after it is merged will you need to finalize your code.
The So if the box has color (0.5, 0, 0) and we shine a light of color (0.5, 0, 0), if the attenuation is -1 (let's say
I didn't have specific numbers in mind, but each property should be tested independently. So For this comparison I will have to give you the d3d patch as well. |
I wanted to comment on one point:
No, this needs to be done as a single unified contribution. I don't want to see the API and pipeline-independent implementation go in without the specific implementations for both D3D and ES2. Otherwise we would be committing a partial feature. In addition to that not being something we typically do, until we have solid implementations for both rendering pipelines we can't be sure that the common code won't require changes. |
For similar reasons, the CSR should not be finalized until after the code review is mostly done (it's in good enough shape for the "Proposed" state, but it is likely that the code review might cause some changes). |
OK, so one of us will need to send their code to the other and submit it as a single patch? |
@FalcoTheBold The Java + D3D patch is here. Combine it with your ES2 changes and we should have the full first version of the patch. |
@nlisker @FalcoTheBold - Yes, a combined patch will be needed. And both of you will be listed as contributors for the patch. A pull request might be the easiest. |
@nlisker @kevinrushforth The combined changes are in the PR #384. |
You can start a formal review whenever you feel it is ready. It will likely take a bit of time to complete it. Prior to doing so, please fetch/merge the latest changes from the upstream develop branch. I might also recommend squashing the commits into a single commit and then force-pushing to make a clean slate for reviewers, but that's just a suggestion (after starting the review, please do not force push). |
I'm starting the preliminary review on the PR. |
@nlisker Morning. |
Sounds good. What was the issue with testing in your environment? Will you be able to compare both pipelines? We should remember that if we want to add the other light types to the next version (13), and whatever tests that are required, we will need to move slightly faster. Around early July is the deadline. |
The issue was: i wasn't at home 😄
Sure, seems doable. The foundational work is done, we know by your tests that these changes are possible now, so nothing will stop us in that regard.. |
@FalcoTheBold I filed #440. I would like you to do the GL pipeline (I'll show you my d3d changes if it helps). That enhancement is not related to this one. |
Good evening folks,
while playing on a 3d scene, i noticed that the PointLight (very specific, maybe other use-cases for it might come up too) lacked a way to set the radius of how far the light is emitted from the light-source.
Regarding this i was hoping there would be a operation like the "setInfluencingBounds"-method (hence the title) as in the predecessor Java3D available, since the PointLights-emission procedure seems to also rely on its BoundTransforms.
Sadly there is no way of modifying this bit and therefore the PointLight seems rather limited because of it, because not every lamp or similiar light-entity emits light in the same manner.
Maybe i overlooked certain steps and someone might take some time to elaborate on how to take on this issue, but else i would assume it to be a missing feature.
Thanks in advance!
The text was updated successfully, but these errors were encountered: