<div dir="ltr">Hi Ralf,<br><div class="gmail_extra"><br><div class="gmail_quote">On 17 October 2017 at 13:58, Ralf Habacker <span dir="ltr"><<a href="mailto:ralf.habacker@freenet.de" target="_blank">ralf.habacker@freenet.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> The shader_pipeline branch already has the abilty to toggle features on/off this way.<br>
</span>that means for example switching light on and off will effect the<br>
related shaders immediatly or is a recompile required ?<br></blockquote><div><br></div><div>It has immediate effect, if the particular combination of modes/defines has never been compiled into a gl program before then a new one is compiled and linked, but this is all done automatically for you. Once all the required gl programs are created the toggle is little more than the OSG backend selecting the appropriate gl program to use.  This particular feature mimics what the fixed function pipeline does in the GL driver, internally it maps the modes you've selected to a gl program.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I will give it a try - is there any abstract available for this feature<br>
branch ?<span class=""><br></span></blockquote><div><br></div><div>The only docs are my discussions of the work here on the mailing list/forum, just search for shader_pipeline references.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> For the .obj plugin I think one would want to make sure loads the obj<br>
> data properly and makes it possible post processing to enable shader<br>
> functionality that maps what the data suggest is appropriate.<br>
</span>I assume you are refering to adding a node call back in the obj plugin,<br>
which does the real work after loading ? It needs to get the texture<br>
type to unit index mapping (either automatically assigned or by obj<br>
plugin options)<br></blockquote><div><br></div><div>Having a callback mechanism in a plugin is really awkward, it forces you to push the interface to the callback into osgDB, assign this to an osgDB::Options that you pass into the readNodeFile() call and then having the plugin check for this and call it.  Given the OSG has a large number of plugins if you start doing using this approach you open the door to an ever messy API and implementation.</div><div><br></div><div>The plugins are decoupled from the core OSG to keep things extensible.<br></div><div><br></div><div>The right way to handle things to load the data and post process if required.  If you want you don't want to explicitly invoke the post processing then you can use a osgDB::ReadFileCallback to catch all attempts to read files and then post process them as you wish.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> I don't think it would be appropriate to push shader functionality into the obj<br>
> plugin to handle this,<br>
</span>any hint where to add such stuff into the shader pipeline branch of the<br>
osg framework?<br>
<span class=""><br>
or for the ShaderGen itself to be worked on when<br>
> it's not far away from being replaced.<br>
</span>make sense<br>
<span class=""></span></blockquote><div><br></div><div>As a short term solution I would suggest just writing a shader yourself for these problem .obj files, this would be the quickest way to get things working at your end.  You could leverage #pragma(tic) shader composition to help toggle on/on off features, but you'll need an even handler that toggles the StateSet::setDefine()'s rather than leverage the StateSet::setMode(..) functionality.<br></div><div><br></div><div>With the shader_pipeline work one would need to have a top level shader that is able to handle the diffuse and specular texture maps in an appropriate way.  The current top level shader I've worked on so far is OpenSceneGraph-Data/shaders/shaderpipeline.vert and shaderpipeline.frag, this is just early days though, but might give you an idea where this functionality is going and how one might add support for different texturing and lighting approaches.<br></div><div><br></div><div>With ShaderGen it's there as stop gap to generate some shaders for a subset of the fixed function pipeline that is common in a subset of the OSG loaders. It is just a means of getting "something" on the screen on platforms like GL core profile and GLESL 2+, it's not an all purpose fully functioning solution.<br></div><div><br></div><div>Robert.<br></div><div> </div></div></div></div>