Am 07.11.2013 14:04, schrieb michael kapelko:
I was thinking of creating some sort of material.xml and assign it to
each object (or a group of objects).
You could totally do this. So material.xml could contain the defines.
As far as I understand, the define approach creates one shader per
object eventually. And that turns out to be faster than one shader per
pipeline with different StateSets and uniforms per object.
Am I correct?
Partially. It eventually creates one shader program per node. There
might be different statesets after all. As the shader-program is part of
the StateSet.
The thing saved here are the uniforms (in my case there where around 50
non-material/camera related uniforms just for controlling which
rendering-paths are taken)
Thanks.
2013/11/7 Sebastian Messerschmidt <sebastian.messerschm...@gmx.de
<mailto:sebastian.messerschm...@gmx.de>>
As this is company code and part of a bigger framework I can only
give you some hints.
I have a custom shader loader which parses the shader source in
order to later add the defines and creates a osg::Program derived
class
e.g. CustomProgram.
In GLSL you can use preprocessor macros like in C.
So you can say:
#define PATH_1
and later
vec4 color = vec4();
#ifdef PATH_1
color = vec4(1,0,0,0);
#else
color = vec4(0,0,1,0);
#endif
So the shader loader will create the CustomProgram which holds a
list of defines which should be applied later.
The CustomProgram itself will do this in the ::apply function, by
injecting the #define %DEFINE_NAME% in to the shadersource before
compiling it.
For setting the defines at the statesets you want, you can simply
check the stateset for a program-attribute, cast it to
CustomShader and add a define.
You will have to do some management inside the CustomProgram to
make it aware of changed define-sets etc. But it the end you are
simply adding some custom attributes to control the compiled
shader program at the state set, instead of setting uniforms directly.
While this seems complicated it allows for two things:
1. Fast less-branching shader code
2. Different sets of shaders realizing rendering based upon
defines. In my case I can do deferred and forward shading with the
same framework without having to know which one is running under
the hood, when assigning materials/material effects.
cheers
Sebastian
Can you please provide an example of how an object manages its
define-set?
In my case, I simply get the object's StateSet and setup
uniforms. But I don't get how to setup defines.
Thanks.
2013/11/7 Sebastian Messerschmidt <sebastian.messerschm...@gmx.de
<mailto:sebastian.messerschm...@gmx.de>>
Am 07.11.2013 12:55, schrieb michael kapelko:
Hi, Sebastian.
So you compose one shader per object?
No, one program per define-set (e.g. #define
NORMAL_MAPPING,#define PARALLAX_MAPPING, ...)
The idea is not to compose the shader from functional blocks,
but to write one shader containing all paths which are
activated based upon the defines.
It is still complicated to get all the paths correctly in the
ubershader, but i found it a good transition from uniform
based de/activation.
So you will end up with N different programs with N being the
number of define-combinations used.
Thanks.
2013/11/7 Sebastian Messerschmidt
<sebastian.messerschm...@gmx.de
<mailto:sebastian.messerschm...@gmx.de>>
Hi Michael,
I solved a similar problem by overriding osg::Program
which composes a shader from an Ubershader. This is not
done via uniforms but defines.
It seems to work somehow and improved the performance
over branching based on uniforms.
Hi.
I decided to go with single pipeline that provides big
shaders and objects using own uniforms and textures to
change the pipeline behaviour.
I started to design a simple material format so that it
resembles the one of EffectCompositor.
Thanks.
2013/10/31 michael kapelko <korn...@gmail.com
<mailto:korn...@gmail.com>>
Hi, Wang.
I've just checked if I can use some uber shader and
control its behaviour per object by setting the
object's uniforms. And it works.
I wonder if that's ok to do that to make different
objects rendered differently in the same scene.
Thanks.
2013/10/31 Wang Rui <wangra...@gmail.com
<mailto:wangra...@gmail.com>>
Hi Michael,
Effect compositor in fact adds the child scene
graph to a camera binding to a FBO, and then
uses RTT cameras to perform the post processing
work. The last step is always to show the final
image on an HUD quad so all other scene nodes
will be occluded. The only way to make the
effect compositor work with other fixed
pipeline nodes is to write to the depth values
in the shader code of the last step, which
cannot be automated.
The dof.xml does such work so you may try
./osgeffectcompositor --normal-scene cessna.osg
--effect dof.xml to see how normal and deferred
shaded objects are merged. At present I haven't
had a better idea about this problem. :-)
Wang Rui
2013/10/30 michael kapelko <korn...@gmail.com
<mailto:korn...@gmail.com>>
Hi.
I've recently implemented deferred shading
with normal mapping and shadow mapping
using EffectCompositor, but it has effect
on the whole scene, not a single object.
Is it possible to use EffectCompositor to
apply effects per object?
Thanks.
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
<mailto:osg-users@lists.openscenegraph.org>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
<mailto:osg-users@lists.openscenegraph.org>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
<mailto:osg-users@lists.openscenegraph.org>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
<mailto:osg-users@lists.openscenegraph.org>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
<mailto:osg-users@lists.openscenegraph.org>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
<mailto:osg-users@lists.openscenegraph.org>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
<mailto:osg-users@lists.openscenegraph.org>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
<mailto:osg-users@lists.openscenegraph.org>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
