Hi Gerrit,
Gerrit Voß wrote:
> On Mon, 2009-06-01 at 18:41 -0500, Carsten Neumann wrote:
>> some background: when running vrjuggler apps a
>> PassiveWindow/PassiveViewport are used it seems juggler always activates
>> the scissor test. This confuses OpenSG somewhat (i.e. it does not know
>> about the test being on) and currently limits my shadow maps to window
>> resolution.
>
> Which shadowmaps are these ? I might have never tried them with a
> passive window though. Will do so to get a better idea what is
> happening.
I have implemented another algorithm as a LightEngine and use it with
the DeferredShadingStage I've written. I can send you the code offline.
>> Part of the fix is to have PassiveViewport::isFullWindow()
>> always return false,
>
> Hmm, something seems odd, it looks more like the passive viewport/
> passive window do not provide the correct size information to
> the backend.
hm, the question is can they even do that? I mean since they are passive
how much do they know and can pass on?
>> but that is not enough, because in
>> RenderAction::drawBuffer, partition 0 has setupExecution() called before
>> the "child partitions" are rendered which breaks the shadow maps --
>> there is a glPushAttrib(GL_VIEWPORT_BIT) in there, I could add
>> GL_SCISSOR_BIT, but it is annotated with Quick fix, need to check GV.
>> Can you give me a hint what I should look at specifically, e.g. what use
>> cases require the partition 0 setup early?
>
> nearly all of them, you never now which stage is going to write into the
> framebuffer. So the global framebuffer setup has to be done before
> anything else. So adding the SCISSOR_BIT is in general ok. The to check
> part was to see if this is the best way, an alternative would be, as for
> the matrices to force stages/partitions to restore the correct state,
> e.g. push/pop themselves.
just an idea, but how about having a ViewportChunk and letting the state
handling deal with it
>> More generally: while trying to figure this out, I've noticed that the
>> viewport is not present in the partitions and they explicitly carry size
>> information around. What is the reason for this - or why can't the
>> Partition/DrawEnv have a Viewport *?
>
> having a Viewport is the exception rather that the rule. Nearly all of
> the internal stages don't have one so in order to work nothing can
> really reference a viewport. And putting a dummy Viewport in seems
> overkill.
ok, maybe not a dummy, but an optional Viewport* ?
>> Or was the idea to roll the
>> functionality of Viewport::activate into preRenderCallbacks on the
>> Partition?
>
> which part of activate is not present in the partition setup ?
ah, my bad, I did not mean to say something is missing, just that it
seems that VP::activate is not used now and whether the idea was to
remove it? Do we have any viewports in 1.x that do something non-trivial
in activate, I have a vague feeling there was something with the
cluster, but can't recall it right now.
> I hope my engineering nightmares are over now ;) so I have more time.
uh, oh, sounds like you had a horrible time, hope it gets better.
> Let me try to run the shadowmaps with a passive window and see what
> happens.
you should be able to reproduce it with the existing shadow map stuff or
anything that renders into an FBO larger than the app framebuffer and a
viewport on the main window that does not fill the whole window. That
should enable scissoring on the main viewport which remains active when
rendering to the FBO.
Cheers,
Carsten
------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core
