@Momoko_Fan said: @gouessej: glAlphaFunc is a special case... There are many people who still use it in the RenderState even though they shouldn't cause its gone in OGL3 and Android. All of the jME3 core shaders do it properly by using an alpha discard threshold and do not rely on glAlphaFunc. On the other hand for OpenGL1 we have bindings that allow you to bind the alpha discard threshold parameter into the fixed binding which ends up in a call to glAlphaFunc.
We can support it on desktop, by checking if the GL is GL2 and if so enabling alpha func. However I think we should have some sort of warning shown so that users know not to rely on it in the future.
The problem is that it won't work if someone uses a forward compatible profile, you see what I mean. I will follow your suggestion even though I think it should be completely removed.
@erlend_sh said:
Btw @gouessej , feel free to tell @sgothel he's more than welcome to join us in this thread ;) It seems the two of you are actively communicating, which is great, but it'd be even greater if his input was provided in this thread directly. That way there's less branching of the discussion and fewer details left out.
Yes of course, Sven knows he's welcome here.
@pspeed said:
Slightly off topic: Unshaded does not have an alpha discard threshold. It should probably be added... and BitmapFont's loader should probably be setup to turn it on so that text doesn't z-fight with itself.
As it is, alpha test is still required in some cases.
@gouessej said:
The problem is that it won't work if someone uses a forward compatible profile, you see what I mean. I will follow your suggestion even though I think it should be completely removed.
If they use a forward compatible profile, none of the jME3 shaders would compile. I don't think this is very likely to happen until we port all shaders to GLSL 1.5.
@Momoko_Fan said:
If they use a forward compatible profile, none of the jME3 shaders would compile. I don't think this is very likely to happen until we port all shaders to GLSL 1.5.
Is JMonkeyEngine 3.0 able to support several versions of the same shader?
@gouessej said:
Is JMonkeyEngine 3.0 able to support several versions of the same shader?
There are two ways of handling this. jME3 materials support multiple techniques, so you can have one technique that supports GLSL 1.5 and another that supports GLSL 1.0.
Another way is to have a single technique requiring GLSL 1.0, and then detect what is supported by the GPU in the shader itself using #ifdefs and thus using these features. In this case the problem is that the shaders vary way too much between GLSL 1.0 and GLSL 3.3 and higher, so extensive work is required to have a single shader support both of these versions.
Btw i tested again the TestMultiPostWater and there is still some lag when you move around (when the filter effect gets in the view). thatās areally strange issueā¦
also the skybox is not drawn, i guess this has to do with cubeMaps handling.
Iām sorry, I was a bit busy, Iāve just found a new job. I need to pay the bills, you know what I mean
@Momoko_Fan said: @gouessej: There are many issues I've noticed in the JOGL renderer .. I am using Windows 7, 64 bit.
In NEWT display:
1) GLWindow.setPointerVisible(false) doesn't seem to do anything
2) Key release events are not being raised. I press the key but I never receive the key release event.
Please run TUER. If you still see the mouse pointer when you're in the museum, it means that something is really wrong under Windows. I'm going to check that today.
You can fix the second bug by updating JogAmp (we broke something when implementing InputEvent.isAutoRepeat() but it has been fixed). If it doesn't solve the problem, let me know whether you use AWT or NEWT.
@nehon said:
Btw i tested again the TestMultiPostWater and there is still some lag when you move around (when the filter effect gets in the view). that's areally strange issue...
also the skybox is not drawn, i guess this has to do with cubeMaps handling.
Cool!
You'll notice the issues in TestMultiPostWater : the lag is very noticeable when the 3 water pools are in the view.
Also you'll notice that the sky is completely black for the second issue.
Thanks.
@nehon said:
Cool!
You'll notice the issues in TestMultiPostWater : the lag is very noticeable when the 3 water pools are in the view.
Also you'll notice that the sky is completely black for the second issue.
Thanks.
I think I messed up something the frame buffer code, in the attachments as you supposed. I'm looking at it now.
@normen said:
No need to be sorry for anything man, you already help us immensely. Nobody in the core team found as much time for this yet as you did already :)
Thanks. I would like to fix some minor bugs so that some other developers in the core team obtain a stable renderer in which they will be able to add new features without major troubles.
@Momoko_Fan said: @gouessej: There are many issues I've noticed in the JOGL renderer .. I am using Windows 7, 64 bit.
In NEWT display:
1) GLWindow.setPointerVisible(false) doesn't seem to do anything
2) Key release events are not being raised. I press the key but I never receive the key release event.
I'm silly, you already told me your problems came from NEWT. I went to my former desktop today, I wanted to run TUER under Windows Vista but Sourceforge returned an error message 503 Service Unavailable when I was in the test room. I'm back home and I have no machine under Windows to test it again. I will ask some JogAmp contributers to tell me whether GLWindow.setPointerVisible(false) works on their machines under Windows 7. Please can you try to reproduce your second bug under GNU Linux? I would like to know whether it comes from my port of the renderer, the Java part of NEWT or its native code.
@Momoko_Fan Iāve succeeded in running TestCameraNode with NEWT by modifying JmeDesktopSystem to use the display based on it, the mouse pointer correctly disappears when I press the mouse button and reappears when I release it. Iām going to update JogAmp.
@Momoko_Fan If GLWindow.setPointerVisible(false) doesnāt work even with this update, please try to reproduce your bug with one of our unit test and fill a bug report if it is still broken.
I have removed a minor useless check but Iām not sure it really impacts the performance. I fear that the symptom of the bug in the use of frame buffers canāt be easily understood with a profiler.
Edit.: I will probably need some help to fix it despite my efforts.
