macOS status update about atomes HOT 21 OPEN

I know that the 'GtkGlArea Widget' has evolved from version 3 to 4,
I had an exchange with Emmanuele Bassi on Gnome discourse about some issues I have with transparency (no time to check that so far) ... and I need to fix the shader to correct this.

Just so you know there are few bugs (that I can't fix so far with Gtk4):

1. No markups in menus ... spend lots of time on this without success, my last question on that subject on Gnome discourse did not even get any answer :-(
   In Gtk4 menus are supposed to be handled using XML files but with dynamics (allocated/deallocated for many reasons) menus in Atomes this cannot work, so I coded everything but the instruction that is supposed to work for that ... just does not :-(
2. Selection in tables has issues (see measures: wrong lines are picked)
3. No way to moves lines in tables (curves edition and crystal builder)
4. Add widgets to menus is impossible, ex: color selections, menus evolved tremendously between Gtk3 and Gtk4,
   as a consequence I had to re-write entirely Atomes GUI, but still this is not complete because of functions still lacking
   in Gtk4 ... not even sure that I will be able to reproduce the Gtk3 behavior anymore (for the color selection in particular)
5. Transparency with the GtkGLArea widget
6. Trouble to update menus, for instance if you want to display 'clones' then you need to update the menu
   to add the corresponding 'checked' symbol on the check button menu item, then very often the program freezes,
   no clue what is going on (and debbuged it all the way trough though, it is a Gtk4 bugged it seems)

from atomes.

Apparently it is not a gtk 4 vs. 3 issue, because I can reproduce the exact same color issue with a gtk-3 build.

What is weird is that it was working with your sources one year ago, when I tried it. I do not know what has changed, if it is a macOS/Gtk issue.

from atomes.

Does it behave like that for all types of colouring (press the 'a' button on the opengl window, or check the 'opengl -> Color scheme(s)" menu to change it ... I confirm that I do not have this issue on Linux

from atomes.

All color schemes are weird, supersaturated. It looks like the kind of thing that happens when facets are drawn with non-normalised normal vectors:

PS: but I see you are using GL_NORMALIZE, so this should not be the case. Hum…

from atomes.

Yes I agree with your assessment ... the thing is how come does it behave like that on OSX and not on Linux ... to be honest I have no clue where to look ... there is one thing that you could check is to change the GLSL version to be used in the shaders:
in the file 'srcc/opengl/ogl_shaders.c'
line 22 you can comment the line (with 150 that was for OpenGL v3) if you have v4.* you need a 4*0 number.

Forgot about one big issue/bug with Gtk4, will update the list above ;-)

from atomes.

I am able to change the GLSL version to 330 or 410, and it compiles and runs, but the bug is still there. (Version 430 however errors out at runtime.)

from atomes.

Can you try run the 'gtk-demo' and try the GtkGLArea to see what happens ?

from atomes.

Can you try run the 'gtk-demo' and try the GtkGLArea to see what happens ?

It works.

from atomes.

Ok, next step then,
I checked the difference between shaders for the demo and atomes, and then modified (to try) something in atomes
shaders (ogl_shaders.c), so far everything looks fine on Linux.
So you can try it out and let me know if it changes anything, I am not that confident in that change,
but why not try it ... if that does not change anything I will likely revert to the previous version since I wrote
the shaders a long time ago, so I would need to do this carefully to be sure not to mess it up ;-)
Also something else came to my mind, in Atomes can you change the lightning engine,
see what happens (opengl -> Materials and lights) top of the first tab ...

from atomes.

With this change:

** (<unknown>:70574): WARNING **: 23:23:28.742: Compile failure in fragment shader:
ERROR: 0:2: Use of undeclared identifier 'gl_FragColor'
ERROR: 0:2: Use of undeclared identifier 'gl_FragColor'

Lighting mode set to “no” gives flat colors, which is the expected result (I think):

from atomes.

I think I found it! By default there are 3 lights. If I remove lights 2 and 3, to keep only light 1, I get this:

It appears to be specifically "point lights" that create trouble. Whenever I add one back, it becomes horrible.

from atomes.

Ok, first thing first I corrected the shaders this morning, also when building the code with your new Makefile,
the compiler detected few things that it wasn't seeing before so I took care of that as well, thanks ;-)
Now for the lights, I think we need to see what is going on when the lights are initialized, I would suggest
to compare the numerical values you get with the points lights (for the first images of the thread) then I will
compare with what I have on Linux, to do that open the coordinates file, the 3D window, then "opengl -> Material And Light(s)",
then change tab to the "Configure light sources" tab and check the numerical values for each lights ... also please send me the
coordinates file so I could do the same, note that if you are using a project file from the start, lights data are saved in this file,
so when you open it again it will remain bad, so if the initialization of the lights has an issue it will be easier to check by
importing atomic coordinates, or creating a structure from scratch in atomes following the same procedure on both sides,
and then compare our results.

from atomes.

• I am testing on this PDB file: https://www.dropbox.com/s/eqypd2xl7pyluky/HKUST-1_nowater.pdb?dl=0
• I run atomes HKUST-1_nowater.pdb to load it directly
• The lights by default are:

from atomes.

Ok, well exact same thing on my side, so no idea, yet, about what is going on ... thanks for doing this again ;-)

from atomes.

Maybe there is an issue in the code path that is specific to light type == 1 (point light)?

I think it's the intensity calculation and attenuation that goes wrong. The lights 2 and 3 are way too bright, with a super high base intensity (100 times larger than light 1).

from atomes.

Yep I noticed the same thing, only I am not sure why it does not go wrong with Linux or Win,
I reduced intensities for L2 and L3 to the same factor as L1 and in Linux and it does not change
anything so I suggest to do just that, because indeed lights 2 and 3 really seems way too bright.
I will check the code to see if I found anything, then correct it.

Well in 'w_advanced.c' I read:

Light init_light_source (int type, float val, float vbl)

...
double intensity = (type == 1) ? 100.0*DEFAULT_INTENSITY : DEFAULT_INTENSITY;
... 

I wrote that so long ago no way to remember why I decided to do this, so I will just comment it
and correct it:

Light init_light_source (int type, float val, float vbl)

...
double intensity = DEFAULT_INTENSITY;
... 

Let me know if it's better ;-)

from atomes.

Run some tests, see attached, for O atoms (isolated):
Intial code (x 100):

Modified code:

[EDIT]
I think I should have provided more info here about the parameters that I used:

• vdW radius
• Diffuse material
• Ligthning model Cook-Torrance-CGX
• 100 for quality

[/EDIT]

There is a difference actually, and it get bigger depending on the material used for the rendering,
I guess my initial tests were not so bad, even though I am still wondering how/what/why I did ;-)

So you might want to create an OSX flag like:

#ifdef OSX
  double intensity = DEFAULT_INTENSITY;
#else
  double intensity = (type == 1) ? 100.0*DEFAULT_INTENSITY : DEFAULT_INTENSITY;
#endif

I will try to find some OpenGL guru to ask for his/her advise on the matter ;-)
Let me know what you think.

from atomes.

Single oxygen atom, with default lighting:

and the 100 factor removed:

The size of that "pure white" spot appears to be solely related to the “attenuation” parameters. Bigger attenuation => bigger white area. Smaller attenuation => smaller area, like this:

from atomes.

Seems I forgot few info in my previous message to explain how I obtained the rendering, corrected that.
OpenGL tweaking is not my strong suit, for that reason I decided to let as many options as possible available,
hence it is possible to tweak and adapt pretty much everything in the GUI,
In 'w_advance.c' I will get rid of the line:

double intensity = (type == 1) ? 100.0*DEFAULT_INTENSITY : DEFAULT_INTENSITY;

and change it to:

double intensity = DEFAULT_INTENSITY;

Anyway it is possible to adjust anything in the GUI so why bother ...
I guess it was too hot in my office this afternoon a because of the heat I was fouled by this color thing,
no need to hurt ourselves more with that :-)

PS: note that I will anyway take any advise you may have regarding OpenGL ;-)

from atomes.

Just to be clear: the current state, with DEFAULT_INTENSITY for all lights, still gives this kind of default visualisation:

from atomes.

Ok, I had no idea it is still so different from Linux, could you please let me know for which value the intensity seems to be ok.
Because it really seems that we need to add an OSX flag of some sort here.

from atomes.