Hi Paul, On Monday 16 November 2009, Paul Martz wrote: > With the typecast fix in place, I crash at line 479 with a NULL viewport > pointer. I am running: > > export OSG_WINDOW="10,30,800,600" > osgoit dumptruck.osg > > I'm using current svn head compiled for GL1/2 compatibility (the default). > > Are you seeing the same crash? No. On UNIX this appears to work. I remember that I wanted to verify that there already is a viewport just past the realize() call. I just /hoped/ that this is the case on WIN32 ... So, looking into a better mechanism ...
Anyway good to hear that somebody else is working on that too. I was just promising to provide that demo. And now that we just released our software I found the time to move that code from a proof of concept to something you can actually use as a demo. Just a side node for a comment of you on osg-users: Depth peeling is a very good example for the need of a shader compositon infrastructure. You remember that you were somehow voting against a shader composition infrastructure that can put together shaders for the fixed pipeline state? Sure, I see well the complexity of that topic. I see the amount of code that is in the drivers to do that. I see well that driver writers do not want to do that in the long term. I also see the execution time complexity of compiling and optimizing shaders on the fly for every state change in OpenGL, but: >From my point of view this kind of global rendering technique like Depth Peeling is one of the best examples that we need something like that. So what you want to do is just load an arbitrary model and insert that required second depth test into the state from the top of your viewer. You can do that with the fixed function pipeline. That was the reason I am sticking with that 'old style fixed function implementation' in our application. You can do that with the virtual shader approach where you might define an 'earlyZ' virtual shader function to put an additional z test agains tha already peeled layers. But with a plain 'just have a singe shader that replaces everything' approach, you are really lost. You will have to modify all shaders in your application to match those requirments. You are then lucky when you have all the models in your hands. But for the typical vis-sim case where you import all the models with plugins that just add a blob of unstructured GLSL text to the leaf nodes you can just forget doing such global rendering techniques... So, looking forward to have something like the virtual shader approach available to finally make GLSL usable *without* touching every local and may be inaccessible shader implementation for such global rendering technique changes... So, back to the oit contribution: the example as such exercises some codepaths in osg that have been introduced recently. So testing them might be good. But feel free to replace that demo with something that works better... ... ok, if I can ask for a feature of that example, I would like to insist on being able to use that example as you can use osgviewer and as you can use osgoit now, in the sense that you can just provide an anoymous model file :) Greetings and thanks Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
