Hi, On Tue, 2009-06-02 at 09:21 -0500, Carsten Neumann wrote: > 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.
would be good as moving the original stage based shadow maps is still on my list so I can make sure I don't break yours to much ;) And I hope to get back to finally finish up all the shader infrastructure too. > >> 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? hmm, good argument, but than there are quite some functions which take size information as parameters. So we might have to distinguish more between passive and not passive setups. If the passive window/viewport don't reliable supply size information I guess the only solution is to query for these bits in case we run a passive environment. > >> 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 hmm, it's not really something I would expect to change per object so it would just be a chunk which is just there, I still would handle it more like the transformation stack which is also done outside the chunk part. > >> 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* ? hmm, I don't really see this would help. If the values derived from the Viewport are wrong as they seem to be now, carrying the Viewport around should not make a difference. It seems more the problem that the state is not carried over correctly (e.g. the scissor test info). > >> 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. yeah crimping cables is not necessarily my favorite past time, as is dealing with dodgy network hardware and drivers and all the other stuff to keep the presentation setups running ;) > > 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. ok, I'll have a look. kind regards, gerrit ------------------------------------------------------------------------------ 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
