Hi Robert,
2009/3/23 Robert Osfield <[email protected]> > Hi Maciej, > > I'm replying to both osg-submissions + osg-users as ongoing general > discussion is likely. > > On Mon, Mar 23, 2009 at 1:11 PM, Maciej Krol <[email protected]> wrote: > >> Glad to hear that You like it. I was suprised that it works for almost all >> scene state setups that I use. It would be quite simple to extend it with >> osgShadow support if we could only detect shadowing state of geometry. > > > osgShadow is mostly shaders already so I'm not sure it should be needed. > Where there specific parts you were thinking of? > For me osgShadow is very hard to use. It uses one ubershader for whole ShadowedScene. To handle different state sets (diffuse texture, normal texture, fog, ...) simultaneously one has to write giant ubershader with many switches. In ShaderGen shadows could be handled the same way as lighting or fog. The problem is that there is no StateSet mode for shadows. Maybe some certain uniforms could be tracked? > > > > >> On WinXP NVidia Quadro NVS 320M I did not notice any performance drops. >> Maybe shaders are not properly cached? > > > It's not the GPU that was the issue, but the OSG's CPU overhead. We're > talking about quite large models, 10' of thousands of obejcts so they tend > to be gated by CPU overhead anyway, so shaders just add more ovehead. It > still got a solid 60Hz hertz though ;-) > > >> IMHO in OSG 3.0 state attributes and modes should be abstract - not tied >> to actual OpenGL implementation. High level attributes and modes could be >> mapped to different rendering implementation (GL 1.0; GL 2.0; GL 3.0; ESGL). >> This would be a major change, breaking compatibility with existing OSG >> application. > > > This pretty well what I have had in mind, this is the approach I was > advocating for OSG-3.0. > > >> Open discusion in osg-users is required. I am thinking about >> implementation for a long time, but my customers are not willing to pay for >> it. I could start implementation in my free time. It mainly depends on OSG >> 3.0 goals. >> > > This type of general refactoring work is not so easy to sell - supporting > OpenGL 3.0 for instance is a worthy cause but it won't actually be a game > changer in terms of delivered features. OpenGL ES is a different mattter > though, I believe this does offer real differences that could make a > difference to end user application delivery i.e. offer 3D apps in the > embedded space so might be more attractive to outside funding. Ports to > consolses are also an area where perhaps funding might be possible in which > the general refactor work can fall out of it. > > Without external funding we'll have to chip away at the task bit by bit. Currently it is very hard to write OSG applications supporting fixed function and OpenGL 2.0 simultaneously, so most user stay with fixed function. Fixed function in OSG is a first class citizen. Lighting, texturing, fog states work out of the box. It is not the case for new versions of OpenGL. > > Robert. > > _______________________________________________ > osg-submissions mailing list > [email protected] > > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > Regards, Maciej
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
