Hello Carsten!
Thank you again for your support.
Regarding the clustering problem, I solved it by using the
commitChangesAndClear().
The lost changes that were made during the render() were probably used by
the new render iteration; committing changes before clearing was sufficient
:)
Regarding the lighting problem, it does not reproduce in the test program...
IMHO it seemed better before, even if it was wrong (the terrain went
progressively darker as the camera moved away from the terrain)...
As you desumed, the problem regards the applied shader, but I do not know
if the problem lies in the shader code or in the generated normal map (IMHO
the shader code, probably...)
Christian Bar
--------------------------------------------------------------------------------------------------------------------------------------
Hello Christian,
On 07/22/2014 05:21 PM, Christian Bar wrote:
> Thank you Carsten!
> The example now also works for me!
>
ok, thanks for testing!
BUT... going on with the implementation in my software, I noticed two
> more problems:
>
> 1) Terrain lighting (and/or normals) is not right, because the terrain
> lighting changes as I move the camera (the camera is in the origin and
> the world moves by its inverse transform, indeed).
>
Hmm, does this reproduce with your test program? Note that there the
terrTrans node is below the lightBeacon, so lighting should in fact change
when moving the terrain - because the terrain changes position relative to
the light source.
Anyway, I think the shader was missing a transformation of the light
position from eye space to model space (i.e. multiply with
gl_ModelViewMatrixInverse). Attaching a new patch (contains the changes
from the previous one), and a .zip with the individual commits from my tree.
With that patch the lighting with shaders (setPerPixelLighting(true)) is
practically the same as without, so that seems an improvement to me ;)
2) The terrain is not correctly rendered in a cluster environment.
> In the program I have a WIN32Window (local viewport) and
> a MultiDisplayWindow (for cluster visualization).
>
> 2a)
> In my render loop I usually did things in this order:
>
> MasterApplication::update()
> {
> changeTheScenegraph();
> Thread::getCurrentChangeList()->commitChanges();
> MultiDisplayWindow->render();
> WIN32Window->render();
> Thread::getCurrentChangeList()->clear();
> }
>
Hmm, not sure if that makes any difference, but you can set your local
window as: mdw->setClientWindow(win32win); and it will be rendered without
the explicit call.
If I do this, the result is a wrong rendered terrain: the geometry and
> the triangles are not correct. You can see the result by looking at one
> of the screenshot I made:
> https://www.dropbox.com/s/49sgu7ywf2oqwkt/screenshot000.jpg
> https://www.dropbox.com/s/4h681pqcpo9lc29/screenshot002.jpg
> https://www.dropbox.com/s/q8kio1cquyzdsea/screenshot007.jpg
>
>
> 2b)
> In the case I change the loop to:
>
> MasterApplication::update()
> {
> changeTheScenegraph();
> MultiDisplayWindow->render();
> WIN32Window->render();
> Thread::getCurrentChangeList()->commitChangesAndClear();
> }
>
> , the terrain is correctly rendered (except for lighting) on the
> WIN32Window, but on the MultiDisplayWindow the terrain still looks like
> in the screenshots.
>
Well, the latter is 'better' anyway. Since rendering can in fact cause
things to be modified (cache data mostly) you could loose (i.e. not commit)
those changes when just calling CL->clear() after rendering.
For the actual meat of the problem, I'll have to hack up a cluster example
to use the QuadTreeTerrain, which will take a day or two.
Cheers,
Carsten
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
