Hi Robert, I am very looking forward for the shader composition. I understand that you are busy with clients work and this delays new features that you may introduce to OSG. I started to think if there would be any way to help OSG growing because you are the main person for introducing core features and essentially, there were no big features introduced for past two years. Surely, I am not complaining, just thinking about it, as it affected me much in past few weeks.
The company I am working for sometimes considers which rendering backend to use. Many products went for Hoops3D (commercial sw), and I succeeded to make one product going for OSG last month. Unfortunately, the main weakness was considered probably this "no new features", at least not such features that could silence these arguments. Surely, I am not complaining, just want to look whether there would be any way to silence these arguments. Here is what came to my mind. I am not sure what can or can not be done. It is just dumping of my head: - Work for clients is important, but maybe, you can have a programmer that you would closely supervise, thus, he would deliver a good project to your client, while alleviating youself, at least partially, for OSG development. - Maybe, few companies around OSG could fund you (if we find them) to make yourself available, at least part-time, for OSG. Still a note to the first point: If it is a difficult to find a good programmers or a good programmer is too expensive in UK, I have few good here. I am using even students to do an interesting work (http://merlin.fit.vutbr.cz/wiki/index.php/Graphics_Projects_2012) while some are looking for a job in computer graphics after the studies. Skype communication is what we use to connect internationally located company members. - Maybe, a kind of professional support mechanism could be developed. Now thinking, how to apply this model in OSG context. Our company was paying for few professional support licenses for Coin (Open Inventor clone). Even Qt used this model. It was about 2000€/year/person and they provided excellent support (answers to questions in few minutes, bugfixes in an hour, etc.) Just putting ideas on the table, because Coin died and the main reason was that its developers started to participate on other project that probably earned more money. First, there were no features, then no patches, and after three years, the community around Coin disappeared. I do not believe this will happen to OSG and my wish is very opposite - that OSG grows continually and more and more people use it. If there is a way I can help, I would like to try... Sorry for offtopic and please, do not take this email in a bad way - Maybe, there is no way, then this email changes nothing. If there are some, we could reflect on that. Cheers, John On Thursday 07 of February 2013 17:22:27 Robert Osfield wrote: > HI Aurelien, > > I have just done a code review and am going to reject the code as is. > I feel the approach won't scale well as one is hardwiring support for > osg::Material into RenderLeaf and State, and if we take this approach > when the times comes to support all the rest of the fixed function > pipeline we'll end up with huge mess of code to maintain and the > performance overhead with all the checks would also be detrimental. > While the approach you have taken does follow what I did for the > modelview and projection matrices these are special cases and require > very specific type of handling which differs from normal OpenGL state > attributes that are handled by osg::StateAttribute. > > This issue you are trying to solve is one I've been aware of for a > couple of years, I have also done some of the legwork in creating an > infrastructure in the OSG to support mapping of fixed function > pipeline to shaders in the form of shader composition. The two halves > of shader composition is the management of the shaders themselves > which is equvilant to the glEnable/glDisable functionality in the > fixed function pipeline, and the uniform management that is equivalent > to mapping osg::Material to osg_Material as you have done. Before I > could complete the work on shader composition I got swamped by other > more pressing client and community work and alas haven't had the time > to get back and complete this work. Shader composition is bleeding > dev work with no good prior art to learn and be inspired by so it's > not something that is easy to drop in and out of from time to time - I > need to focus just on this topic for a couple of weeks to get my head > around all the issues and potential solutions. > > For a bit of idea of where I was going have a look at the > osgshadercomposition example and the various supporting classes. > > In my work I hadn't solved the issue of automatic mapping of old fixed > function state like osg::Material, but had a plan of have > osg::StateAttribute subclasses like osg::Material provide their own > osg::ShaderComponent which in turn provide the shaders, and then the > uniforms that will be required by these shaders. I'm afraid the > provision of the shaders is the bit I hadn't nailed down yet, but had > a vague idea that the state attributes would maintain their own > osg::Uniform and apply these from within their apply() method, or have > these queried by osg::State. I must admit I didn't spend time > thinking about your usage model - provide your own shaders but want > the uniforms, but this case should just require the disabling of the > shader composition but enabling of the uniform application. > > One of the guiding principles of the approach I was going for was that > the implementation of the various osg::StateAttribute (such as > osg::Material, osg::Light etc.) is that they would all provide their > own local uniform and shader implementations, their wouldn't be any > global approach to implementing the individual functionality - as I > mentioned in my first paragraph I don't like this approach as it'll > lead to lots of functionality being hardwired into classes like > osg::State to the extent that it'll kill performance and > maintainability. > > As I haven' solved all the problems of shader composition yet perhaps > others can reflect on the issue and how we might implement the > automatic uniform provision be state attributes in a way that solves > the specific problem that you have now and leads naturally on to full > blown shader composition. > > Cheers, > Robert. > > Robert. > > On 7 February 2013 11:42, Aurelien Albert <[email protected]> wrote: > > Hi, > > > > In "advanced" OpenGL (glsl > 320 I think) gl_material is deprecated. > > > > This is really annoying if you want to render "normal" files such as > > 3ds/ive/osgb... which contains osg::Material. > > > > This submission works like the "setUseModelViewAndProjectionUniforms" > > method on osg::State, by introducing the "setUseGLMaterialUniforms" > > method : > > > > This method add some uniforms, synced with the current osg::Material : > > > > osg_FrontMaterial.ambient > > osg_FrontMaterial.diffuse > > osg_FrontMaterial.specular > > osg_FrontMaterial.emission > > osg_FrontMaterial.shininess > > > > and > > > > osg_BackMaterial.ambient > > osg_BackMaterial.diffuse > > osg_BackMaterial.specular > > osg_BackMaterial.emission > > osg_BackMaterial.shininess > > > > > > To use it in a shader, you can : > > > > 1/ Declare only uniforms you want to use : > > > > > > Code: > > uniform vec4 osg_FrontMaterial.ambient; > > uniform vec4 osg_FrontMaterial.diffuse; > > > > > > > > If you use only these two values > > > > 2/ Declare complete structure : > > > > > > Code: > > // Define the structure > > struct osg_Material > > { > > > > vec4 ambient; > > vec4 diffuse; > > vec4 specular; > > vec4 emission; > > float shininess; > > > > }; > > > > // Declare the unfiroms : > > uniform osg_Material osg_FrontMaterial; > > uniform osg_Material osg_BackMaterial; > > > > > > > > > > and then use osg_FrontMaterial.ambient, osg_FrontMaterial.diffuse, etc... > > in your shader code. > > > > > > > > Thank you! > > > > Cheers, > > Aurelien > > > > ------------------ > > Read this topic online here: > > http://forum.openscenegraph.org/viewtopic.php?p=52462#52462 > > > > > > > > > > _______________________________________________ > > osg-submissions mailing list > > [email protected] > > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegrap > > h.org > _______________________________________________ > osg-submissions mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph. > org _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
