kicad-developers team mailing list archive

["Torsten Hüter" <torstenhtr@xxxxxx>]

Hi Mario,

 
Orson is the current maintainer of the GAL, because I have to little ressources for that at the moment (and he does a very good job!). However, I can write somthing about my ideas:

> - Would it be possible in a near future, to detach the "glm" library from GAL (folder) and maybe make a common include file for the use glm? 
> Since the 3d-viewer is also using the glm, and last time we had problems with the define of radius in radians.. maybe it can be a way to fix 
> this issue.

> Hi Mario,

> Sure. As far as I remember, initially glm was used by GAL exclusively,
> that is why I put it in the gal/opengl directory.
 
The GLM Library seems to be well established; I've seen it used for many projects; also the MIT-license is compatible with the GPL2. Of course it makes sense if you're sharing this ressource.

> - Would it be possible in a next near future, think to reimplement some of (general) modules related with openGL to have in mind the reuse 
> in other modules in kicad? I mean, example: can we have a shader loader manager to be used by different parts in the sources and not just 
> for GAL? Or any other (openGL / gml) very general code that can be reused in other parts..? So it will not be rewritten and duplicated in the > sources..

> SHADER is already quite separated from GAL. It is just a class to load,
> link & apply shaders basing on generic OpenGL calls.
 
Indeed, this was written to be universal so I see no problems if you're using this module.

> Now more specific questions, just so I can try to understand a bit more of the openGL / GAL / Pcbnew:
>
> - openGL / GAL is not currently the default mode, does it have anything to do with openGL support? Does Kicad have any limitation policy to > not support or limit the use of openGL (I mean.. openGL versions and shaders versions in this case). (Other way to make the question:
> Does kicad want to support old-school PC plataforms / graphics board? so we can't make the full step switch)
>
> As Nick mentioned - GAL is not complete yet, so KiCad should start with
> the default canvas now. People who understand its limitations and
> features should switch by themselves.
 
Not really ideal for the release; but with the given manpower I'm guessing the legacy canvas can't be dropped yet.
We're using the unstable version of KiCad already for our boards; you have still to switch often between the the old canvas / OpenGL, because not all features are implemented. This can be pretty confusing, our working student has already complained much about that :)

> There are also people complaining about OpenGL incompatibility, even
> though the standard we use is not very modern and lowering it would defy
> its purpose.
 
Well, I'm guessing that still OpenGL 2.1 is used as minimum requirement. According to Wikipedia (http://en.wikipedia.org/wiki/OpenGL), the standard was released 2006. That's almost 9 years ago; and I think at some point you simply can't support all old hardware. So that's a good decision to change here nothing.
 
Of course a software renderer is a good alternative, if Cairo is too slow, there is also a work package for students:
http://www.ohwr.org/projects/cern-kicad/wiki/StudentProjects
 
I had the same idea; but I've given up shortly, because the investment is high and the benefit low (only for people using old hardware).

> - Do you think is would be possible to do in some way what GAL/openGL do in Pcbnew but now to display it in 3D? Would that be an appropriated way to do it for the 3D-viewer? (Ie: generate it via shaders (lines, circles, etc) VS generate it via polygon mesh)
>
> - If that makes sense, would it be eventually possible to reuse GAL/openGL code in the 3d-viewer some how? in that case?
> GAL was designed with 2.5D view in mind and so was its interface,
> including auxiliary classes. Maybe I am wrong, but changing GAL to work
> in real 3D mode would cause a lot of major changes. Apart from that,
> there is also Cairo renderer which is not capable of 3D drawing at all.
 
2.5D is a good description. However, I had also in mind that it should be possible to overlay the 3D models for checking the mechanics. But that's rather a feature for the distant future. From (my) user perspective 3D editing is in my opinion absolutely unimportant, I don't know much use cases for that. Another idea was that it's possible to mirror the whole board, such that you can edit the backside.
 
Thanks Orson for the great work,
Torsten