Hi Carsten,
Post by Carsten NeumannThis one is at the center of what I'm currently working on. We would
hmm, is the patch you sent complete? I started converting it into a
series of commits, but noticed that there are only changes in
Source/Base/Base - in other words there is no user of LiSPSMTechnique in
the tree at this point; is that intentional?
As I said, it is work at progress. It is a building block and I
considered it as base technology. The other stuff is mainly in base
because I did have to extend Plane, Line and Volume. I do not think that
it is hurting to have this stuff in Base. I would like to bring
self-contained building blocks into the master so that I can concentrate
on the next step. For instance if you do not accept my changes to the
base elements, I have to reconsider my course of action from the ground
up. That would not be feasible in a later state of the development. It
is my objective to come up with a suitable LiSPM shadow solution of high
quality to be part of public OpenSG. However, it might be that I fail
with that undertaking. In that case it would be easy to remove the
LiSPMTechnique class if that is desirable. The other Base extensions
should imho stay in Base in any case.
Post by Carsten NeumannThat also seems to mean that there is no user of the GL addititions in
part 5 (yet)?
The part 5 is concerned with the change of how the GL symbols and
dependencies are to be used in OpenSG (*). Currently, we have a pull
strategy. That is any newly used symbol/dep are added to the OSGGLEXT.h
and OSGGLFuncProtos.h files. I did propose to regular sync with the
current official Kronos OpenGL headers. That way you always have the
currently correct specs at hand. I really do not like to have to add
these things to the OSGGLEXT.h and OSGGLFuncProtos.h by hand during the
development. Because then I have to recompile the whole libraries. On
the other hand if I patch the my clone with my own OSGGLEXT.h and
OSGGLFuncProtos.h, I do not know which symbols/deps are missing in the
master without an additional compile cycle (or search procedure). That
is the reason why I insistently try to convince you to change procedure.
As I have already written, this is controversial at least between Gerrit
and me. I did try to bring up an additional argument but that did not
get answered:
http://www.mail-archive.com/opensg-users%40lists.sourceforge.net/msg15347.html
http://www.mail-archive.com/opensg-users%40lists.sourceforge.net/msg15364.html
https://sourceforge.net/p/opensg/mailman/opensg-users/thread/1842b7a0-6f1f-3437-f2e8-43de7377a921%40DataSolid.de/#msg35398135
I would like to find a solution that pleases all of us. If it can't be
found, I will go on with the patching procedure of my working clone.
So Carsten, let me end this long mail with my appreciation to take the
work of managing the library.
Best,
Johannes
(*) I'm missing 'OpenSG2: Accumulated changes... part 5: gl' from the
mailing list. It has possible be filtered due to the attachment(?)