Hello Gerrit,
"Gerrit Voß" <[email protected]> schrieb im
Newsbeitrag news:[email protected]...
>
> hmm, these are leftovers and not in the code path anymore. The whole
> handling is done in the backend. These functions are marked for
> removal.
>
You are right. I didn't use the debugger but only read the code. My fault.
Actually, the PassiveViewport::activateSize function is not called in my
OpenSG 2.0 setup. This is good news, as I can now remove my
EnhPassiveViewport class which was a hack anyway.
> As to OpenGL code outside the scene graph. The renderaction leaves the
> viewport / scissor state as it was found when window->render was called
> so it should not influence what happens outside. If it does it is a bug
> in the backend. Similar the outside code has to make sure the setup is
> what it needs.
>
yes, that is what I do expect.
> As for the passive viewport the pixel size information is queried from
> the context during render so it relies on the app to do the correct gl
> setup before calling render. So this is kind of circular, except if one
> treats it as a helper for the app to setup the gl viewport state.
>
yes.
>
> you can pass a callback to init which does the additional initial
> modification of the gl state.
>
Not that easy (but not impossible) as my OpenSG code is decoupled from my
old app OpenGL code.
>
> that is stuck as work in progress. I'll have a look. But I'm still
> not sure about some of the things involved. The problem is currently the
> passive window becomes a very special case which you can't easily swap
> for any other opensg window anymore and that worries me a little.
>
As I already said, I can live with the current situation. I do not have an
overview over all the things which have to be bring together.
>
> Ideally I would forbid any direct gl access to the application and
> provide the infrastructure so that the app can schedule tasks if it
> needs to so that the OpenSG infrastructure 'knows' when the app is
> accessing the context. This works for all of the windows except the
> passive one.
>
This scenario does imply(?) that the OpenSG render call starts the render
process. In my situation it is the other way around. I have a lot of (old)
OpenGL code and have somewhere in between a call to the OpenSG framework. I
would like to have all of my rendering in OpenSG, but I have some parts in
my application for which I currently do not see an easy translation into the
scene graph world.
1. line rendering:
I must be able to render ten thousends of lines which can have arbitrary
display modes and which must all be pickable. Additionally, I have tight
memory constraints to satisfy. Using geometry node/cores for each line imho
is not feasable. What I have in mind here for the future is to use classes
of geometry cores each rendering bunches of lines with some intelligence for
selection setup...
2. highlight rendering:
I have a very dynamic complex highlight rendering scheme which allows
selection of the front and back faces and edges of my solid geometry.
However, this is all work in progress with respect to an sole OpenSG
solution. All I can say is that with the current OpenSG framework (1.8 and
2.0) it is possible to realize most of my demands in an App-OpenGL / OpenSG
setup. One place I couldn't come around was the introduction of multiple
OpenSG viewports into my graphic window. For instance, I did implement a
special viewport handling a tripod for user interactions. This works fine
until the moment the user does switch into my dynamic highligh mode. The
reason that this fails was that the depth buffer handling got out of sync
between my app OpenGL code and the OpenSG framework.
But do not get bored. I'm very satisfied with the OpenSG framework.
Additionally, I can say that the transition from 1.8 to 2.0 was quite
successful and I can everyone encourage to make this step.
What I really like about the OpenSG 2.0 framework is
- cmake build system
- Smart pointer handling
- the drop out of the beginEditCP/endEditCP stuff.
- compile time
- debuggability on msvc
- I could map all of my 1.8 code into 2.0 code, nothing dropped out
Best,
Johannes
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
