Discussion:
[Opensg-users] OpenSG2: New HDR stage
Johannes Brunen
2016-05-03 15:26:42 UTC
Permalink
Hello Carsten and Gerrit,

I have implemented a new HDR stage and I would like to ask for some help with it. I have written a test and an example for this new stage. Essentially it is working but I get some strange behavior on startup of the examples. I.e. if I start the example/test the mipmap generated texture that I use in the stage is not working correctly. After resizing the window about some amount suddenly it starts working. The problem does not show up if I do not use the cube mapped sphere in the example/test. I have tried a lot but can't locate the problem. The problem shows up on my ATI and on my NVidia platform with recent drivers. So I could really use some help for this.

Additionally, I have written a special foreground in order to allow AntTweakBar integration. The example does make use of it. In the example is a flag that allows to enable or disable the GUI. However, in order to use AntTweakBar the OpenSG example (tonemapping.cpp) does have to include and link against the library. Currently, I do setup this by hand in my VC++ project. It would be nice if OpenSG would provide CMake support for AntTweakBar. For complex stuff like the tonemapping example it does really help for testing and experimenting.

The example and the new stage is not polished and optimized in any way. But I would really like to track down the above problem first.

I have uploaded to code to ' wikisend' and you can download it with the following link:

http://wikisend.com/download/628564/OpenSG.zip

I would really appreciate some help and stay tuned to hear from you.

Best,
Johannes
Carsten Neumann
2016-05-09 21:45:13 UTC
Permalink
Hello Johannes,
Post by Johannes Brunen
I have implemented a new HDR stage and I would like to ask for some
help with it. I have written a test and an example for this new stage.
Essentially it is working but I get some strange behavior on startup of
the examples. I.e. if I start the example/test the mipmap generated
texture that I use in the stage is not working correctly. After resizing
the window about some amount suddenly it starts working. The problem
does not show up if I do not use the cube mapped sphere in the
example/test. I have tried a lot but can't locate the problem. The
problem shows up on my ATI and on my NVidia platform with recent
drivers. So I could really use some help for this.
hmm, after fixing some small build issues (the gcc of Fedora 22 still
defaults to C++98 and was barfing on some C++11'isms) it seems the
example is working for me. At least I can see the colors adjust based on
the brightness of the image content - I'm running without the
AntTweakBar stuff, so only using initial settings for everything.
Can you perhaps send a screenshot of the problem or describe what is
going wrong?
Post by Johannes Brunen
Additionally, I have written a special foreground in order to allow
AntTweakBar integration. The example does make use of it. In the example
is a flag that allows to enable or disable the GUI. However, in order to
use AntTweakBar the OpenSG example (tonemapping.cpp) does have to
include and link against the library. Currently, I do setup this by hand
in my VC++ project. It would be nice if OpenSG would provide CMake
support for AntTweakBar. For complex stuff like the tonemapping example
it does really help for testing and experimenting.
The CallbackAlgorithmForeground is indeed a nice addition, thanks! What
exactly do you mean by "... provide CMake support for AntTweakBar", i.e.
what is missing to make it work or work better?

Cheers,
Carsten
Johannes
2016-05-10 07:59:50 UTC
Permalink
Hello Carsten,

thanks for taking your time!
Post by Carsten Neumann
hmm, after fixing some small build issues (the gcc of Fedora 22 still
defaults to C++98 and was barfing on some C++11'isms) it seems the
example is working for me. At least I can see the colors adjust based on
the brightness of the image content - I'm running without the
AntTweakBar stuff, so only using initial settings for everything.
Can you perhaps send a screenshot of the problem or describe what is
going wrong?
Yes, I have uploaded images and small enhancements of the HDR2 stage and
the example to Wikisend:

http://wikisend.com/download/451168/OpenSG.zip

The enhancements allows me to set the mipmap level from the example. I
used that for images 6.png to 8.png.

Ok, what you can find in the zip files is:

1.png and 2.png:
I tried to not use the AntTweakBar library in order to rule it out as
the cause of my problems. But the library has nothing to do with it.
In the 1.png you see the screenshot just after I have started the
example. You can see that the colors are all much to bright. After
resizing the image about a small amount with the mouse I took image
2.png and now all rendering is as expected, i.e. correct.

3.png, 4.png and 5.png:
Know I have enabled the AntTweakBar library in order to tweak the
example a little. 3.png shows the example just after start up. Again the
colors are much to bright. Now I have changed the output texture to the
Exposure Map and you can see in image 4.png that the screen is totally
black. That means that the average luminance map is not correct. Image
4.png is taken after resizing the window and you can see that the screen
is pale gray, i.e. the average luminance map is functioning.

6.png, 7.png and 8.png:
In this set of images I have used the new functionality that allows me
to adjust the mipmap level used for lookup of the average luminance. See
HDR2Stage::genFuncGetAvgLuminance() called by HDR2Stage::genSharedCode()
which is called by HDR2Stage::genCompositeFragmentShader().
Image 6.png shows the example after startup and changing of the mipmap
level to zero. The red arrow pointing to the mirror sphere shows
artefacts that do stay at the original position after change of view
point. This can be seen in image 7.png. Lastly, image 8.png shows that
the artefacts vanish after resizing of the example window.
Post by Carsten Neumann
What
exactly do you mean by "... provide CMake support for AntTweakBar", i.e.
what is missing to make it work or work better?
What I mean is that I would like to do the same as I do for e.g. the
jpeg library. I.e. I call cmake with the following defines with respect
to the jpeg library:

-D JPEG_INCLUDE_DIR=$CompInstallDir/Install${i}/include
-D JPEG_LIBRARY_RELEASE=$CompInstallDir/Install${i}/lib/jpeg.lib
-D JPEG_LIBRARY_DEBUG=$CompInstallDir/Install${i}/lib/jpegD.lib

That is cmake knows that the jpeg library is a dependency of the OpenSG
project and ask for these entries in the cmake GUI.

Currently, I modify the MS VC project by hand, but I would like to
generate them with the AntTweakBar set up already.


Hope that my explanations help :-)

Best,
Johannes
Johannes
2016-05-17 09:25:30 UTC
Permalink
Hello Carsten and Gerrit,

I have reloaded the zip file to

http://wikisend.com/download/702966/OpenSG.zip

because the former link was expired.


Do you have had time to take a look. I really hope that you can spot the
origin of the problem. I would like to bring this stage into the
official OpenSG repository. I have dedicated a lot of time into this
piece of code and I would like to bring it to a successful end.

Best,
Johannes
Johannes
2016-05-24 07:30:16 UTC
Permalink
Hi,

I'm still hoping for some help with my HDR stage problem. I have updated
all files again to wikisend:

http://wikisend.com/download/544744/OpenSG_files.zip

You can find two zip files in this zip: OpenSG_1.zip is the original
code I send. And OpenSG_2.zip contains the requested pictures and some
minor enhancements to the code.

I would really appreciate some help here :-)

Best,
Johannes
Post by Johannes Brunen
Hello Carsten and Gerrit,
I have reloaded the zip file to
http://wikisend.com/download/702966/OpenSG.zip
because the former link was expired.
Do you have had time to take a look. I really hope that you can spot the
origin of the problem. I would like to bring this stage into the
official OpenSG repository. I have dedicated a lot of time into this
piece of code and I would like to bring it to a successful end.
Best,
Johannes
------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
Carsten Neumann
2016-06-17 18:28:59 UTC
Permalink
Hello Johannes,

sorry for the very long delay on this. I had a severe deadline that
prevented me from looking at anything unrelated to ${DAYJOB}.
Post by Johannes
I'm still hoping for some help with my HDR stage problem. I have updated
http://wikisend.com/download/544744/OpenSG_files.zip
hmm, unfortunately it has expired again. Do you perhaps have a google
drive or dropbox account (or similar) that keeps the files around
without expiration?
In any case I'm attaching two images from running the tonemapping
example (on linux) before and after performing a resize - the background
color in both cases is RGB (0, 0, 180).
I've also built with AntTweakBar to look at the various debug
visualizations and the ExposureMap always comes out as gray (not solid
black) after waiting for a moment to let the auto-adjustment settle.
I've also run the whole thing under apitrace to capture the OpenGL
commands issued, but there are around ~1000 OpenGL calls per frame
making it challenging to find the difference between what happens on
initialization vs. on a resize. Nothing jumped out at me as an obvious
problem (I was mainly looking at viewport and texture sizes in the trace).
The next two weeks should be a bit calmer for me, so I can be more
responsive ;)

Cheers,
Carsten
Johannes
2016-06-18 08:23:56 UTC
Permalink
Hello Carsten,
Post by Carsten Neumann
sorry for the very long delay on this. I had a severe deadline that
prevented me from looking at anything unrelated to ${DAYJOB}.
It is good to here from you :-) Hope that you could serve your task in time.
Post by Carsten Neumann
Post by Johannes
I'm still hoping for some help with my HDR stage problem. I have updated
http://wikisend.com/download/544744/OpenSG_files.zip
hmm, unfortunately it has expired again. Do you perhaps have a google
drive or dropbox account (or similar) that keeps the files around
without expiration?
No not currently. But I will investigate in the future. For now, I have
reloaded the last zip file to wikisend:

http://wikisend.com/download/870064/OpenSG_files.zip
Post by Carsten Neumann
In any case I'm attaching two images from running the tonemapping
example (on linux) before and after performing a resize - the background
color in both cases is RGB (0, 0, 180).
I've also built with AntTweakBar to look at the various debug
visualizations and the ExposureMap always comes out as gray (not solid
black) after waiting for a moment to let the auto-adjustment settle.
I've also run the whole thing under apitrace to capture the OpenGL
commands issued, but there are around ~1000 OpenGL calls per frame
making it challenging to find the difference between what happens on
initialization vs. on a resize. Nothing jumped out at me as an obvious
problem (I was mainly looking at viewport and texture sizes in the trace).
Maybe it is a problem that only shows up on windows? However, I do have
the problem on on different computer with differing windows versions as
well as differing graphic platforms (NVIDIA and AMD). I think that it
must somehow be related to the cube map that is used in the example. But
this guesswork and not very profound.
Post by Carsten Neumann
The next two weeks should be a bit calmer for me, so I can be more
responsive ;)
I really appreciate that.

My intention is the following:

1. Resolve the issue so that the stage is working properly.

2. Correct the code so that it follows the rules and intentions of
OpenSG. For instance, I'm a bit unsure about the HDR2Stage::changed(...)
implementation, which currently basically is empty.

3. Optimize the stage as far as possible so that it can be used without
hesitations.

For point 2 and 3 I really do need a reviewer with experience in OpenSG
land. I have undoubtedly made mistakes, but currently I'm on the
learning curve from flatland to space.


Thank you again for taking your time.

Best,
Johannes
Carsten Neumann
2016-06-21 22:58:17 UTC
Permalink
Hello Johannes,
Post by Johannes
Post by Carsten Neumann
hmm, unfortunately it has expired again. Do you perhaps have a google
drive or dropbox account (or similar) that keeps the files around
without expiration?
No not currently. But I will investigate in the future. For now, I have
http://wikisend.com/download/870064/OpenSG_files.zip
ok, got the files this time. Thanks!
Post by Johannes
Post by Carsten Neumann
In any case I'm attaching two images from running the tonemapping
example (on linux) before and after performing a resize - the background
color in both cases is RGB (0, 0, 180).
I've also built with AntTweakBar to look at the various debug
visualizations and the ExposureMap always comes out as gray (not solid
black) after waiting for a moment to let the auto-adjustment settle.
I've also run the whole thing under apitrace to capture the OpenGL
commands issued, but there are around ~1000 OpenGL calls per frame
making it challenging to find the difference between what happens on
initialization vs. on a resize. Nothing jumped out at me as an obvious
problem (I was mainly looking at viewport and texture sizes in the trace).
Maybe it is a problem that only shows up on windows? However, I do have
the problem on on different computer with differing windows versions as
well as differing graphic platforms (NVIDIA and AMD). I think that it
must somehow be related to the cube map that is used in the example. But
this guesswork and not very profound.
The HDR background image seems the biggest difference in the pictures
you sent and what I had tried to run.
I'll try to run it on linux with an HDR background image tomorrow and
see if it reproduces - somehow it seems unlikely to me that it is
OS/platform related since most of the code involved here is platform
independent.
Post by Johannes
2. Correct the code so that it follows the rules and intentions of
OpenSG. For instance, I'm a bit unsure about the HDR2Stage::changed(...)
implementation, which currently basically is empty.
The changed member function is supposed to update any derived
values/state based on which fields have changed. However, I think most
of the state depends on window/viewport sizes which are only known at
render time.
Post by Johannes
3. Optimize the stage as far as possible so that it can be used without
hesitations.
That typically means avoiding to recompute values that are still valid
from the previous frame. One thing that comes to mind in the case of the
HDR2 stage is only filling and uploading the uniform buffer if any
values have changed. I'm not sure how much difference that makes in
practice though.

Cheers,
Carsten
Carsten Neumann
2016-06-23 22:21:30 UTC
Permalink
Hello Johannes,
Post by Carsten Neumann
Post by Johannes
Maybe it is a problem that only shows up on windows? However, I do have
the problem on on different computer with differing windows versions as
well as differing graphic platforms (NVIDIA and AMD). I think that it
must somehow be related to the cube map that is used in the example. But
this guesswork and not very profound.
The HDR background image seems the biggest difference in the pictures
you sent and what I had tried to run.
I'll try to run it on linux with an HDR background image tomorrow and
see if it reproduces - somehow it seems unlikely to me that it is
OS/platform related since most of the code involved here is platform
independent.
ok, using the HDR background image I can reproduce the problem on linux.
If I modify the tonemapping example to not create the scene on startup
(i.e. remove the call to setupScene() from Example::initialize() and
instead add the following to the switch in Example::keyboard():

case '1':
{
std::cout << "Loading scene... " << std::flush;
setupScene();
std::cout << "done." << std::endl;
_mgr->showAll();
}
break;

Pressing '1' at runtime creates the scene and then it looks as expected.
Not sure what to make of this finding.

I've spent some time looking at the OpenGL calls made as captured by
apitrace. I compared what happens on a frame before the resize and the
one where the resize happens. The only differences I could find were
the expected resize operations on the various textures.
I don't know what debugging attempts you have made so far, my basic
approach with the above has been to attempt to find what differences in
OpenGL calls there are before/after the first resize and (assuming those
can be found) work backwards from there to find where in OpenSG they
originate. Perhaps this gives you some ideas on things to try as well. I
may be able to look some more early next week.

Cheers,
Carsten
Johannes
2016-06-27 09:42:24 UTC
Permalink
Hello Carsten,
Post by Carsten Neumann
ok, using the HDR background image I can reproduce the problem on linux.
That is good to hear. I do not like errors that only show up under
special circumstances :-)
Post by Carsten Neumann
If I modify the tonemapping example to not create the scene on startup
(i.e. remove the call to setupScene() from Example::initialize() and
{
std::cout << "Loading scene... " << std::flush;
setupScene();
std::cout << "done." << std::endl;
_mgr->showAll();
}
break;
Pressing '1' at runtime creates the scene and then it looks as expected.
Not sure what to make of this finding.
Ok, that did bring me to some new experiments:

I have changed the function setupAdaptLuminanceMaterial in line 1026 in
the following way:

I replaced the following line of code (line 1041)

chunkMat->addChunk(pData->getLuminanceTexObjChunk(), 0);

with this one

chunkMat->addChunk(pData->getAdaptLuminanceTexObjChunk(!pData->getCurrentAdaptLuminanceIdx()),
0);

and the problem is gone for me. Could you check that in your setup please.

Actually, that is the line that is intended by theory. I did have used
the initial line of code for the following reason. I have first
programmed the complete example in a pure OpenGL setup without OpenSG.
There, I couldn't initialize the last adapted luminance texture without
actually rendering it first. Therefore, I fooled the setup insofar that
I initialized the last adapted luminance texture for the first 'ping',
with the luminance texture written by the luminance render target. I
expected the same must hold in OpenSG land and mapped the code accordingly.

Ok, when this also works for you, I would like to ask you if the code
can be added into the OpenSG2 code base?

Also, I would like to ask for a simple method to add the AntTweakBar
library via CMake flags to the generated projects?

Hopefully you like the HDR2 stage and it meets the standards set by OpenSG.

I do also have some other things in the pipeline for which we have to
talk a little in the near future. So I hope you are not tired for
assisting me with my problems.

Again, Carsten, thank you for taking your time. I hope that I will gain
some speed in the future to contribute good things to OpenSG.

Best,
Johannes
Carsten Neumann
2016-06-30 23:14:46 UTC
Permalink
Hello Johannes,
Post by Johannes
I have changed the function setupAdaptLuminanceMaterial in line 1026 in
I replaced the following line of code (line 1041)
chunkMat->addChunk(pData->getLuminanceTexObjChunk(), 0);
with this one
chunkMat->addChunk(pData->getAdaptLuminanceTexObjChunk(!pData->getCurrentAdaptLuminanceIdx()),
0);
and the problem is gone for me. Could you check that in your setup please.
hmm, it now is non-deterministic, i.e. sometimes it works sometimes it
does not. I suspect that is because the texture contents are indeed
undefined.
Ideally we would have a way to issue a glClearTex{Sub,}Image call to
initialize the texture content.
Post by Johannes
Actually, that is the line that is intended by theory. I did have used
the initial line of code for the following reason. I have first
programmed the complete example in a pure OpenGL setup without OpenSG.
There, I couldn't initialize the last adapted luminance texture without
actually rendering it first. Therefore, I fooled the setup insofar that
I initialized the last adapted luminance texture for the first 'ping',
with the luminance texture written by the luminance render target. I
expected the same must hold in OpenSG land and mapped the code accordingly.
Ok, when this also works for you, I would like to ask you if the code
can be added into the OpenSG2 code base?
I went ahead and added it anyway, that should hopefully make it easier
to iterate on it since it only requires sending patches instead of
entire files.
Thank you for contributing this!

Cheers,
Carsten
Johannes
2016-07-01 06:53:48 UTC
Permalink
Hello Carsten,
Post by Carsten Neumann
Post by Johannes
...
and the problem is gone for me. Could you check that in your setup please.
hmm, it now is non-deterministic, i.e. sometimes it works sometimes it
does not. I suspect that is because the texture contents are indeed
undefined.
Ideally we would have a way to issue a glClearTex{Sub,}Image call to
initialize the texture content.
Could you elaborate a little at which place do you think that this api
should be called.
Post by Carsten Neumann
I went ahead and added it anyway, that should hopefully make it easier
to iterate on it since it only requires sending patches instead of
entire files.
Yes, that makes it easier.

I have some minor nitpicking questions:

First, why do you do not accept the nullptr instead of macro NULL? Do we
really have to support such ancient compilers from the pre c++11 time?

Second, you did make a change in OSGStateOverride.cpp from a
const_iterator to a mutable iterator. What was the reason for that change?

Third, I'm still hoping for a CMake build system solution for the
AntTweakBar library, that allows me to easily integrate the library in
the generated example projects. Do you have an idea how to setup things
for that. If not, however, I will take some time to come up with a
solution, hopefully.

Thanks again!

Best,
Johannes
Carsten Neumann
2016-07-01 16:17:57 UTC
Permalink
Hello Johannes,
Post by Johannes
Post by Carsten Neumann
Post by Johannes
and the problem is gone for me. Could you check that in your setup please.
hmm, it now is non-deterministic, i.e. sometimes it works sometimes it
does not. I suspect that is because the texture contents are indeed
undefined.
Ideally we would have a way to issue a glClearTex{Sub,}Image call to
initialize the texture content.
Could you elaborate a little at which place do you think that this api
should be called.
I suspect the problem is that the texture memory is not initialized,
because there is no data specified for the OSG::Image used with the
OSG::TextureObjChunk - which is mostly fine since these textures are
used as render targets before they are read for the first time - except
for the adaptive luminance texture from the previous frame (which has
undefined content on the very first frame).
For this texture we would need a way to initialize it when it is
created. I haven't thought through all the consequences, but one way to
do this is add a field SFVector4f "ClearValues" to TextureObjChunk and
if the Image has no data issue the glClearTexImage call when creating
the OpenGL texture object in TextureObjChunk::handleTexture.
Post by Johannes
First, why do you do not accept the nullptr instead of macro NULL? Do we
really have to support such ancient compilers from the pre c++11 time?
On linux it is more about the default compiler dialect. GCC 6.1
(released 2016-04) is the first release that switched the default to
C++14 (previous C++98). So while it had full support for C++11 for a
long time it is not enabled by default.
That means system compiler for distributions that are widely used at
this point in time need an extra compiler switch to compile C++11 code.
Post by Johannes
Second, you did make a change in OSGStateOverride.cpp from a
const_iterator to a mutable iterator. What was the reason for that change?
The overload of std::vector<T>::erase() that takes a const_iterator
overload is a C++11 addition, before erase() required a iterator
argument, see http://en.cppreference.com/w/cpp/container/vector/erase
Post by Johannes
Third, I'm still hoping for a CMake build system solution for the
AntTweakBar library, that allows me to easily integrate the library in
the generated example projects. Do you have an idea how to setup things
for that. If not, however, I will take some time to come up with a
solution, hopefully.
I haven't gotten around to that. If you want to take a stab at it that
would certainly be appreciated. It should be possible to model this
after the existing external dependencies (e.g. image format libs). So
add a OSG_CONFIGURE_ANTTWEAKBAR macro to
CMake/OSGConfigurePackages.cmake and call find_package() from there. For
more details I'll have to dive back into the build system myself, been a
while that I looked at it.

Cheers,
Carsten
Johannes
2016-07-13 11:41:40 UTC
Permalink
Hello Carsten,
Post by Carsten Neumann
I suspect the problem is that the texture memory is not initialized,
because there is no data specified for the OSG::Image used with the
OSG::TextureObjChunk - which is mostly fine since these textures are
used as render targets before they are read for the first time - except
for the adaptive luminance texture from the previous frame (which has
undefined content on the very first frame).
For this texture we would need a way to initialize it when it is
created. I haven't thought through all the consequences, but one way to
do this is add a field SFVector4f "ClearValues" to TextureObjChunk and
if the Image has no data issue the glClearTexImage call when creating
the OpenGL texture object in TextureObjChunk::handleTexture.
I will take a look into this.
Post by Carsten Neumann
On linux it is more about the default compiler dialect. GCC 6.1
(released 2016-04) is the first release that switched the default to
C++14 (previous C++98). So while it had full support for C++11 for a
long time it is not enabled by default.
That means system compiler for distributions that are widely used at
this point in time need an extra compiler switch to compile C++11 code.
I would not bother with that. C++11 and C++14 are such a huge leap that
it would be a shame to stick to old C++03, at least for the long time.
However, I will of course respect your decision :-)
Post by Carsten Neumann
The overload of std::vector<T>::erase() that takes a const_iterator
overload is a C++11 addition, before erase() required a iterator
argument, see http://en.cppreference.com/w/cpp/container/vector/erase
I didn't know that.
Post by Carsten Neumann
Post by Johannes
Third, I'm still hoping for a CMake build system solution for the
AntTweakBar library, that allows me to easily integrate the library in
the generated example projects. Do you have an idea how to setup things
for that. If not, however, I will take some time to come up with a
solution, hopefully.
I haven't gotten around to that. If you want to take a stab at it that
would certainly be appreciated. It should be possible to model this
after the existing external dependencies (e.g. image format libs). So
add a OSG_CONFIGURE_ANTTWEAKBAR macro to
CMake/OSGConfigurePackages.cmake and call find_package() from there. For
more details I'll have to dive back into the build system myself, been a
while that I looked at it.
You can find a patch file that contains the CMake build system
adaptation for AntTweakBar on Wikisend:

http://wikisend.com/download/506872/org.patch

Besides, it contains additional changes to CMake build system in order
to support some other libraries.

1. I added the Qhull library. Currently it is not used at all, but I'm
planning to use it in the OpenSG Base library in the near future.

Link: http://www.qhull.org/
https://github.com/qhull/qhull/wiki

2. I added the glm and vmath libraries. I do not intend to use them in
any OpenSG libraries nor in any example, but here and then I use them in
my examples for testing some code fragments. They are used a lot in the
OpenGL community and sometimes it is quite useful to have them at hand.
If the libraries are not present nothing awful will be happen. I would
really appreciate support for these. The changes are really minimal.

Remark 1: AntTweakBar, glm and vmath only show up in the Simple examples
targets.

Remark 2: I'm not that proficient in the OpenSG CMake build system that
I can testimony that the changes are correct for every platform. I only
work on the Microsoft Windows platform and do not know the rules for
Linux, OSX, etc. On my Windows platform everythink is working fine, so.

I hope that OpenSG can support these four libraries in the way I do need
them.

Best,
Johannes
Carsten Neumann
2016-07-30 22:09:06 UTC
Permalink
Hello Johannes,
Post by Johannes
You can find a patch file that contains the CMake build system
thanks! I've committed the AntTweakBar related changes.
Post by Johannes
Besides, it contains additional changes to CMake build system in order
to support some other libraries.
1. I added the Qhull library. Currently it is not used at all, but I'm
planning to use it in the OpenSG Base library in the near future.
Link: http://www.qhull.org/
https://github.com/qhull/qhull/wiki
hmm, to me in general it is preferable to add dependencies when they are
used...
Post by Johannes
2. I added the glm and vmath libraries. I do not intend to use them in
any OpenSG libraries nor in any example, but here and then I use them in
my examples for testing some code fragments. They are used a lot in the
OpenGL community and sometimes it is quite useful to have them at hand.
If the libraries are not present nothing awful will be happen. I would
really appreciate support for these. The changes are really minimal.
Perhaps I'm misunderstanding something, but if the code is not going
into OpenSG or examples why does the build system have to know about
these libs in the first place? If it's just for something you are
hacking on it seems easier to just hardcode the include path into the
cmake file - especially given that these libraries seem to be header
only. Anyway, if you feel strongly about this let me know and we can add
them.

Cheers,
Carsten

------------------------------------------------------------------------------
Johannes
2016-07-13 10:30:43 UTC
Permalink
Hello Carsten,
Post by Carsten Neumann
I suspect the problem is that the texture memory is not initialized,
because there is no data specified for the OSG::Image used with the
OSG::TextureObjChunk - which is mostly fine since these textures are
used as render targets before they are read for the first time - except
for the adaptive luminance texture from the previous frame (which has
undefined content on the very first frame).
For this texture we would need a way to initialize it when it is
created. I haven't thought through all the consequences, but one way to
do this is add a field SFVector4f "ClearValues" to TextureObjChunk and
if the Image has no data issue the glClearTexImage call when creating
the OpenGL texture object in TextureObjChunk::handleTexture.
I will take a look into this.
Post by Carsten Neumann
On linux it is more about the default compiler dialect. GCC 6.1
(released 2016-04) is the first release that switched the default to
C++14 (previous C++98). So while it had full support for C++11 for a
long time it is not enabled by default.
That means system compiler for distributions that are widely used at
this point in time need an extra compiler switch to compile C++11 code.
I would not bother with that. C++11 and C++14 are such a huge leap that
it would be a shame to stick to old C++03, at least for the long time.
However, I will of course respect your decision :-)
Post by Carsten Neumann
The overload of std::vector<T>::erase() that takes a const_iterator
overload is a C++11 addition, before erase() required a iterator
argument, see http://en.cppreference.com/w/cpp/container/vector/erase
I didn't know that.
Post by Carsten Neumann
Post by Johannes
Third, I'm still hoping for a CMake build system solution for the
AntTweakBar library, that allows me to easily integrate the library in
the generated example projects. Do you have an idea how to setup things
for that. If not, however, I will take some time to come up with a
solution, hopefully.
I haven't gotten around to that. If you want to take a stab at it that
would certainly be appreciated. It should be possible to model this
after the existing external dependencies (e.g. image format libs). So
add a OSG_CONFIGURE_ANTTWEAKBAR macro to
CMake/OSGConfigurePackages.cmake and call find_package() from there. For
more details I'll have to dive back into the build system myself, been a
while that I looked at it.
Attached you can find a patch file that contains the CMake build system
adaptation for AntTweakBar.

Besides, it contains additional changes to CMake build system in order
to support some other libraries.

1. I added the Qhull library. Currently it is not used at all, but I'm
planning to use it in the OpenSG Base library in the near future.

Link: http://www.qhull.org/
https://github.com/qhull/qhull/wiki

2. I added the glm and vmath libraries. I do not intend to use them in
any OpenSG libraries nor in any example, but here and then I use them in
my examples for testing some code fragments. They are used a lot in the
OpenGL community and sometimes it is quite useful to have them at hand.
If the libraries are not present nothing awful will be happen. I would
really appreciate support for these. The changes are really minimal.

Remark 1: AntTweakBar, glm and vmath only show up in the Simple examples
targets.

Remark 2: I'm not that proficient in the OpenSG CMake build system that
I can testimony that the changes are correct for every platform. I only
work on the Microsoft Windows platform and do not know the rules for
Linux, OSX, etc. On my Windows platform everythink is working fine, so.

I hope that OpenSG can support these four libraries in the way I do need
them.

Best,
Johannes
Johannes
2016-09-29 14:32:49 UTC
Permalink
Hello Carsten,
Post by Johannes
Hello Carsten,
Post by Carsten Neumann
I suspect the problem is that the texture memory is not initialized,
because there is no data specified for the OSG::Image used with the
OSG::TextureObjChunk - which is mostly fine since these textures are
used as render targets before they are read for the first time - except
for the adaptive luminance texture from the previous frame (which has
undefined content on the very first frame).
For this texture we would need a way to initialize it when it is
created. I haven't thought through all the consequences, but one way to
do this is add a field SFVector4f "ClearValues" to TextureObjChunk and
if the Image has no data issue the glClearTexImage call when creating
the OpenGL texture object in TextureObjChunk::handleTexture.
I will take a look into this.
I have implemented that, but it does not solve this particular problem. :-(

I have no further ideas and will leave it in the current state.

Best,
Johannes



------------------------------------------------------------------------------
Johannes Brunen
2016-08-01 07:43:59 UTC
Permalink
Hello Carsten,
Post by Carsten Neumann
Post by Johannes
1. I added the Qhull library. Currently it is not used at all, but I'm
planning to use it in the OpenSG Base library in the near future.
Link: http://www.qhull.org/
https://github.com/qhull/qhull/wiki
hmm, to me in general it is preferable to add dependencies when they are
used...
I understand that, it was only that I just did the CMake build system stuff and I hoped that I could close this topic for now.
Post by Carsten Neumann
Post by Johannes
2. I added the glm and vmath libraries. I do not intend to use them in
any OpenSG libraries nor in any example, but here and then I use them in
my examples for testing some code fragments. They are used a lot in the
OpenGL community and sometimes it is quite useful to have them at hand.
If the libraries are not present nothing awful will be happen. I would
really appreciate support for these. The changes are really minimal.
Perhaps I'm misunderstanding something, but if the code is not going
into OpenSG or examples why does the build system have to know about
these libs in the first place? If it's just for something you are
hacking on it seems easier to just hardcode the include path into the
cmake file - especially given that these libraries seem to be header
only. Anyway, if you feel strongly about this let me know and we can add
them.
I'm used to make OpenSG examples for my stuff that are not of interest to the public. For these examples I sometimes use vmath and glm. If I would have support for these libraries, I could always easily add my examples to my local OpenSG distribution copy and everythink is in place for productive working. What I do not like is to have many patches, that I have to apply to the official code base after I have taken it from the net, in order to get going. Adding some files to the OpenSG code base is fine for me but changing any official file by patching it is not ok. Additionally, in that case license issues would pop up. So these two libraries are a little bit special but since the changes are so minor I hope that you could do me this favor.

Best,
Johannes

P.S.: Since my thunderbird news client that I use for list communication has problems to show up all send messages I could not answer directly to your message. Probably my answer will be llisted into the wrong place. Sorry for that.
Loading...