Hello Johannes,

On 2016-06-18 03:23, Johannes wrote:
> On 17.06.2016 20:28, Carsten Neumann wrote:
>> 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

ok, got the files this time. Thanks!

>> 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.

> 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.

> 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

------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Reply via email to