[osg-users] obj plugin does not support diffuse and specular texture maps

[Robert Osfield]

Hi Ralf,

On 17 October 2017 at 13:58, Ralf Habacker <ralf.habacker at freenet.de> wrote:

> > The shader_pipeline branch already has the abilty to toggle features
> on/off this way.
> that means for example switching light on and off will effect the
> related shaders immediatly or is a recompile required ?
>

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.



> I will give it a try - is there any abstract available for this feature
> branch ?
>

The only docs are my discussions of the work here on the mailing
list/forum, just search for shader_pipeline references.


> > For the .obj plugin I think one would want to make sure loads the obj
> > data properly and makes it possible post processing to enable shader
> > functionality that maps what the data suggest is appropriate.
> I assume you are refering to adding a node call back in the obj plugin,
> which does the real work after loading ? It needs to get the texture
> type to unit index mapping (either automatically assigned or by obj
> plugin options)
>

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.

The plugins are decoupled from the core OSG to keep things extensible.

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.



>
> > I don't think it would be appropriate to push shader functionality into
> the obj
> > plugin to handle this,
> any hint where to add such stuff into the shader pipeline branch of the
> osg framework?
>
> or for the ShaderGen itself to be worked on when
> > it's not far away from being replaced.
> make sense
>

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.

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.

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.

Robert.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20171017/0bf396d0/attachment.html>