Re: [osg-users] Pragmatic shader - a new #pragma directive proposition

[Robert Osfield]

On 14 January 2016 at 14:56, Robert Milharcic
 wrote:
> If I'm not mistaken, the #pragma directive is used by the C/C++ preprocessor
> for providing additional information, beyond what the language itself can
> offer. I thought this was the main inspiration for #pragma(tic) shader
> composition. Anyway, based on feedback I'm now convinced that my proposition
> isn't that useful as I thought :)  and on that note, I rest my case.

#pragma is indeed the C/C++ mechanism for providing extra hints to
specific compilers.

In terms of coming up with #pragma(tic) shader composition I started
with the observation that C/C++ macro's and #define's that could do
much of the job of shader composition, but then I needed a mechanism
for the shader to specify which #define's it required as input to the
shaders. After a bit of head scratching it occurred to me that #pragma
was support by GLSL and since it's a language feature I could piggy
back the extra information specification into the shaders.  Once I
spotted this missing bit of jigsaw it was just too elegant not to
work, thankfully the implementation ended up being relatively tidy
too.

I'm still open to making the shader parsing extensible, it seems like
an interesting experimental tool.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Pragmatic shader - a new #pragma directive proposition

[Robert Milharcic]

Hi all,

With the pragmatic shader one could implement multiple lights and other 
repetitive constructs like this:

-- start of shader code --
#pragma import_defines ( LIGHTING, LIGHT0, LIGHT1 )

#ifdef LIGHTING
  #ifdef LIGHT0
uniform vec4 u_LightColor0;
  #endif
  #ifdef LIGHT1
uniform vec4 u_LightColor1;
  #endif

varying vec4 basecolor;

void light( in vec4 lightColor, inout vec4 color );
#endif

void main(void)
{
basecolor = gl_Color;

#ifdef LIGHTING
  #ifdef LIGHT0
light( u_LightColor0, basecolor);
  #endif
  #ifdef LIGHT1
light( u_LightColor1, basecolor);
  #endif
#endif

gl_Position   = gl_ModelViewProjectionMatrix * gl_Vertex;
}
-- end of shader code --

... and to enable both lights:

stateset->setDefine("LIGHTING");
stateset->setDefine("LIGHT0");
stateset->setDefine("LIGHT1");

The problem with this approach is that nobody really knows in advance how many 
more lights will be needed. Moreover, the shader can get heavily bloated when 
more and more lights are added. As a solution I would like to propose a new 
#pragma construct:

#pragma repeat_begin( DEFINE_IDENTIFIER${SubstitutionParameter} )
(shader code block)
#pragma repeat_end()

... and the shader code supporting arbitrary number of lights would then look 
like this:

-- start of shader code --
#pragma import_defines ( LIGHTING, LIGHT${Member} )

#ifdef LIGHTING
#pragma repeat_begin( LIGHT${Member} )
uniform vec4 u_LightColor${Member};
#pragma repeat_end()

varying vec4 basecolor;

void light( in vec4 lightColor, inout vec4 color );
#endif

void main(void)
{
basecolor = gl_Color;

#ifdef LIGHTING
#pragma repeat_begin( LIGHT${Member} )
light( u_LightColor${Member}, basecolor);
#pragma repeat_end()
#endif

gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
}
-- end of shader code --

... where ${Member} is a substitution parameter and LIGHT is define identifier. 
Then with:

stateset->setDefine("LIGHTING");
stateset->setDefine("LIGHT${0}");
stateset->setDefine("LIGHT${1}");
stateset->setDefine("LIGHT${5}");

... where ${0}, ${1}, ${5} are substitution values, osg would produce following 
shader code:

-- start of shader code --
#define LIGHTING
#define LIGHT0
#define LIGHT1
#define LIGHT5

#ifdef LIGHTING
uniform vec4 u_LightColor0;
uniform vec4 u_LightColor1;
uniform vec4 u_LightColor5;

varying vec4 basecolor;

void light( in vec4 lightColor, inout vec4 color );
#endif

void main(void)
{
basecolor = gl_Color;

#ifdef LIGHTING
light( u_LightColor0, basecolor);
light( u_LightColor1, basecolor);
light( u_LightColor5, basecolor);
#endif

gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
}
-- end of shader code --

Before I do any coding I'd like to know if proposed solution would be of any 
use to the osg community? Or maybe there is a better way? I'm currently solving 
these kinds of problems with uniform arrays, but unfortunately, the uniform 
array has its own max number of elements and the management code of such 
approach tend to be complicated...

Cheers,
Robert Milharcic

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Testing osgUI library

[Rocio Tortajada]

Hi,

I have already tried rotating the GUI, but it doesn't work. When you enter
the mouse over the 3D TabWidget, you can see the message "Widget::enter()"
on the console log. But, if you do the same with the TabWidget which is
inside the HUD camera, you can't see any message.
We think that the problem is in the method called
"computeExtentsPositionInLocalCoordinates" of the Widget class (Widget.cpp
file) on lines;

498matrix.postMult(camera->getViewMatrix());
499matrix.postMult(camera->getProjectionMatrix());

because it uses the matrices of the 'default' camera instead of the HUD
camera's matrices.
We've replaced the two lines before with the next line. In this way, it
detects the mouse over the TabWidget which is inside the HUD camera, but
when I click on the tabs it doesn't work. We could write this line because
we know the projection matrix of our HUD camera.
  matrix.postMult(osg::Matrix::ortho2D(0, 1400, 0, 760));

Thank you.

Rocío

2016-01-05 11:52 GMT+01:00 Robert Osfield :

> Hi Rocio,
>
> I haven't yet had a chance to test the example (it's holidays here :-)
> but in principle it should be possible to use osgUI within a HUD as
> well as in the 3D scene.  One of the motivations for developing osgUI
> was the need to have a GUI in a 3D scene with full stereo rendering
> (HMD's and powerwalls) so this is where I've done all the testing.
>
> My best guess for why it isn't working in the HUD case is a precision
> issue with the intersection routines. As a test try rotating the GUI
> very slightly so it has some depth rather being planner.  If this gets
> things working then we know that it's an issue with intersection tests
> and these need to be adapted to handle the planar HUD case.
>
> Robert.
>
> On 23 December 2015 at 12:12, Rocio Tortajada
>  wrote:
> > Hi!
> >
> > I've tried the osgUI library. I loaded the TabWidget.lua from the
> osg-data
> > into the scene and when I clicked on the tabs it worked as expected
> >
> > The problem arises when I added the TabWidget in the HUD camera, as far
> as
> > we tested the intersections to the widget seems not to be working. Is the
> > osgUI library supporting HUD cameras?  Are we missing something?
> >
> > Find attached an example with my test code, on the left of the scene
> there
> > is a 3D TabWidget and on the right there is a TabWidget inside the HUD
> > camera. The test is very simple, but  if you find it interesting it can
> be
> > added to the OSG examples.
> >
> > Thank you!
> >
> > Rocío
> >
> > ___
> > 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
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Pragmatic shader - a new #pragma directive proposition

[Sebastian Messerschmidt]

Hi Robert,

This seems more complicated than needed.
Why not pass the number of lights as a compile time constant

#pragma import_defines (NUM_LIGHTS)

shader_state->setDefine("NUM_LIGHTS",12);

and use uniform arrays:

uniform vec4 u_LightColor[NUM_LIGHTS];

for (int i = 0; i < NUM_LIGHTS;++i)
{
light+=calcLight(u_LightColor[i], ...):
}

I feel your approach will bloat the preprocessor code path and will 
complicate the use.





Hi all,

With the pragmatic shader one could implement multiple lights and 
other repetitive constructs like this:


-- start of shader code --
#pragma import_defines ( LIGHTING, LIGHT0, LIGHT1 )

#ifdef LIGHTING
  #ifdef LIGHT0
uniform vec4 u_LightColor0;
  #endif
  #ifdef LIGHT1
uniform vec4 u_LightColor1;
  #endif

varying vec4 basecolor;

void light( in vec4 lightColor, inout vec4 color );
#endif

void main(void)
{
basecolor = gl_Color;

#ifdef LIGHTING
  #ifdef LIGHT0
light( u_LightColor0, basecolor);
  #endif
  #ifdef LIGHT1
light( u_LightColor1, basecolor);
  #endif
#endif

gl_Position   = gl_ModelViewProjectionMatrix * gl_Vertex;
}
-- end of shader code --

... and to enable both lights:

stateset->setDefine("LIGHTING");
stateset->setDefine("LIGHT0");
stateset->setDefine("LIGHT1");

The problem with this approach is that nobody really knows in advance 
how many more lights will be needed. Moreover, the shader can get 
heavily bloated when more and more lights are added. As a solution I 
would like to propose a new #pragma construct:


#pragma repeat_begin( DEFINE_IDENTIFIER${SubstitutionParameter} )
(shader code block)
#pragma repeat_end()

... and the shader code supporting arbitrary number of lights would 
then look like this:


-- start of shader code --
#pragma import_defines ( LIGHTING, LIGHT${Member} )

#ifdef LIGHTING
#pragma repeat_begin( LIGHT${Member} )
uniform vec4 u_LightColor${Member};
#pragma repeat_end()

varying vec4 basecolor;

void light( in vec4 lightColor, inout vec4 color );
#endif

void main(void)
{
basecolor = gl_Color;

#ifdef LIGHTING
#pragma repeat_begin( LIGHT${Member} )
light( u_LightColor${Member}, basecolor);
#pragma repeat_end()
#endif

gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
}
-- end of shader code --

... where ${Member} is a substitution parameter and LIGHT is define 
identifier. Then with:


stateset->setDefine("LIGHTING");
stateset->setDefine("LIGHT${0}");
stateset->setDefine("LIGHT${1}");
stateset->setDefine("LIGHT${5}");

... where ${0}, ${1}, ${5} are substitution values, osg would produce 
following shader code:


-- start of shader code --
#define LIGHTING
#define LIGHT0
#define LIGHT1
#define LIGHT5

#ifdef LIGHTING
uniform vec4 u_LightColor0;
uniform vec4 u_LightColor1;
uniform vec4 u_LightColor5;

varying vec4 basecolor;

void light( in vec4 lightColor, inout vec4 color );
#endif

void main(void)
{
basecolor = gl_Color;

#ifdef LIGHTING
light( u_LightColor0, basecolor);
light( u_LightColor1, basecolor);
light( u_LightColor5, basecolor);
#endif

gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
}
-- end of shader code --

Before I do any coding I'd like to know if proposed solution would be 
of any use to the osg community? Or maybe there is a better way? I'm 
currently solving these kinds of problems with uniform arrays, but 
unfortunately, the uniform array has its own max number of elements 
and the management code of such approach tend to be complicated...


Cheers,
Robert Milharcic

___
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

Re: [osg-users] How to setup multi channel

[Dan Liu]

Hi, Robert:
   Thanks for your remind and support. Yes, one display card can support 
multiple monitors. 
   I want to split the master viewer screen which in the same plane into M rows 
and N columns equally. For example, M=5 and N=10. addSlave is the good way as 
you recommend. But I don't know how to setup the value of 
projectionOffsetMatrix. Is there a formula to calculate projectionOffsetMatrix 
for one sub-node(row=i, column=j)? 


With best regards
Daniel


-- Original --
From:  "Robert Osfield";;
Date:  Thu, Jan 14, 2016 03:43 AM
To:  "OpenSceneGraph Users"; 

Subject:  Re: [osg-users] How to setup multi channel



Hi Daniel,

These days most decent graphics cards can push multiple displays at a
solid 60Hz so rather than 20 computers for 5x4 display wall you could
have 5 computers pushing 4 displays each or a similar arrangement.
You could look to mix and matching osgcluster style approach with a
viewer with multiple slave Camera's to achieve this.

When using slave Camera's you provide a matrix to multiple the view
and projection matrices via the View::addSlave(camera,
projectionOffsetMatrix, viewOffsetMatrix), you'll find this defined in
include/osg/View.

Using addSlave when implementing a cluster rather than just setting
the master Camera is generally better as it means that the master can
dispatch the same updates to the master Camera to all slaves and the
individual slaves that apply this to their Viewer.getCamera() while
the individual Slave camera offsets at set up once at start up.

The settings to use with addSlave will depend on the master Camera's
projection matrix set up - is it set to have a field of view of a
single display or for the whole display region?  Also on whether the
display are all in the same plane or not - in the same plane you
simply need to modify the projection matrix offset, but if you have a
cylindrical display then you just modify the view matrix.

Robert.




On 13 January 2016 at 17:01, Dan Liu <139250...@qq.com> wrote:
>  Dear Robert:
> Thank you very much!
> I have studied osgwindow. If I have 20 computer, each computer has 1
> monitor. And my screen wall is 4 rows, 5 columns. Should I setup
> osg::GraphicsContext::Traits if I run viewer in full screen mode? For
> example, a screen's row_no=2 and column_no=2(index begin from 0), it should
> display x range from 50% to 75% and y range from 40% to 60%, and scale
> aspect ratio to 5/4=1.2.
> I don't know how to change matrix in below line:
> viewer.addSlave(camera.get(), osg::Matrixd::translate(1.0,0.0,0.0),
> osg::Matrixd());
>
> And scale function does not work:
> viewer.getCamera()->getProjectionMatrix() *= osg::Matrix::scale(1.2, 1.0,
> 1.0) has no effect, x scale is not changed. But
> viewer.getCamera()->getProjectionMatrix() *= osg::Matrix::scale(1.2, 1.2,
> 1.2) can works, the earth becomes bigger in both x, y, z dimension.
>
> With best regards
> Daniel
> -- Original --
> From:  "Robert Osfield";;
> Date:  Wed, Jan 13, 2016 05:29 PM
> To:  "OpenSceneGraph Users";
> Subject:  Re: [osg-users] How to setup multi channel
>
> Hi Daniel,
>
> The OSG is designed for handling multi-channel system and provides the
> support via the osgVIewer support for master + slave Camera.
>
> The osgwindow example is probably the most straight forward
> implementation to look at - this creates two windows and assign these
> to two slave osg::Camera, which are both assigned to a single
> osgViewer::Viewer (subclass from osgViewer::View which subclasses from
> osg::View) which provides the master Camera.
>
> The overall view is controlled by the master Camera attached to the
> View(er) which provides the main view and projection matrices.  The
> slave Camera's that are assigned to the View(er) have offset matrices
> that multiplied by the master's view and projection matrices to give
> the final view and projection matrices that the Slave camera will use.
>
> Other examples of the slave camera in action can be seen in the
> osgViewer::ViewConfig implementations found in the
> src/osgViewer/config directory.  The neatest way to implement what you
> need would be to implement your own custom osgViewer::ViewConfig that
> sets up the appropriate Slave Camera you need, then when you want to
> set up your viewer for this display system you simply pass in this
> ViewConfig and have it configure the View(er) as required.
>
> Robert.
>
>
>
> On 13 January 2016 at 03:50, Dan Liu <139250...@qq.com> wrote:
>> Dear all:
>> Hello! I'm using OSG to develop an application which run as screen
>> wall(M rows, N columns). I studied the osgcluster example. But still don't
>> know how to split master screen into MXN sub screens, and scale the screen
>> according to the screen wall's real resolution.
>>
>> With best regards
>> Daniel
>>
>> 

Re: [osg-users] Pragmatic shader - a new #pragma directive proposition

[Robert Osfield]

Hi Robert M, et. al,

I understand the motivation the proposal but it does look like it'll
complicate the parsing significantly so am inclined to suggest we look
at the problem at look for easier ways to implement it.

In terms of code bloat in shaders, the #pragma(tic) shader composition
ensures that the final code passed the OpenGL will have all the
unimplemented paths removed so performance won't be an issue.  For
developers code bloat in shaders is an potential issue, one thing you
do to help would be to wrap up all the lighting calls into a small set
of functions that are called from the main, these functions are
implemented in separate shaders that handle all the different code
paths so at least the complexity is kept in one place and can be
reused easily.

A second possibility would be to have developers auto generate shaders
so avoid creating bloated shaders directly.

A third approach might be to have the ability to provide a custom
parser to the OSG so that it can handle custom syntax that developers
feel suits their needs better than the default set of features
provided by the core #pragma(tic) shader composition.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Pragmatic shader - a new #pragma directive proposition

[Robert Milharcic]

On 14.1.2016 9:52, Sebastian Messerschmidt wrote:

Hi Robert,

This seems more complicated than needed.
Why not pass the number of lights as a compile time constant

#pragma import_defines (NUM_LIGHTS)

shader_state->setDefine("NUM_LIGHTS",12);

and use uniform arrays:

uniform vec4 u_LightColor[NUM_LIGHTS];

for (int i = 0; i < NUM_LIGHTS;++i)
{
light+=calcLight(u_LightColor[i], ...):
}

I feel your approach will bloat the preprocessor code path and will complicate the use. 


Hi Sebastian,

First, thank you for your input. Yes, that is more or less the same approach 
I'm currently using. The downside of this approach is that it requires 
additional nontrivial code logic for the uniform array management 
(u_LightColor) and that is why I started to look at the alternatives. There is 
also an upper limit for the size of the array that needs to be taken into 
account.  Also, the loop represents unnecessary overhead (though, this is not a 
problem on a never hardware). On the other hand, my suggestion fits well into 
existing pragmatic shader composition logic and probably has less downsides.

Cheers,
Robert Milharcic
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Pragmatic shader - a new #pragma directive proposition

[Robert Milharcic]

Hi Robert Osfield,

On 14.1.2016 10:10, Robert Osfield wrote:

Hi Robert M, et. al,

I understand the motivation the proposal but it does look like it'll
complicate the parsing significantly so am inclined to suggest we look
at the problem at look for easier ways to implement it.


Actually, while I was waiting for a feedback I made a proof of concept 
implementation which turns out to be relatively straightforward task. For the 
parser part I have to add only a few more lines (excluding sanity checks):

void Shader::_computeShaderDefines()
{
...

if (keyword == "import_defines") _parseShaderDefines(str, _shaderDefines);
else if (keyword == "requires") _parseShaderDefines(str, 
_shaderRequirements);
else if (keyword == "repeat_begin")
{
ShaderDefines shaderCodeBlockIdentifers;
_parseShaderDefines(str, shaderCodeBlockIdentifers);

ShaderCodeBlock shaderCodeBlock;

shaderCodeBlock._begin = eol;
shaderCodeBlock._end = std::string::npos;

shaderCodeBlock._identifier = *shaderCodeBlockIdentifers.begin();
_shaderCodeBlocks.push_back(shaderCodeBlock);
}
else if (keyword == "repeat_end")
{
ShaderCodeBlock& shaderCodeBlock = _shaderCodeBlocks.back();
shaderCodeBlock._end = _shaderSource.find_last_not_of(" \t", pos - 8);
}

...
}

In terms of code bloat in shaders, the #pragma(tic) shader composition
ensures that the final code passed the OpenGL will have all the
unimplemented paths removed so performance won't be an issue.  For
developers code bloat in shaders is an potential issue, one thing you
do to help would be to wrap up all the lighting calls into a small set
of functions that are called from the main, these functions are
implemented in separate shaders that handle all the different code
paths so at least the complexity is kept in one place and can be
reused easily.

Agreed.


A second possibility would be to have developers auto generate shaders
so avoid creating bloated shaders directly.

A third approach might be to have the ability to provide a custom
parser to the OSG so that it can handle custom syntax that developers
feel suits their needs better than the default set of features
provided by the core #pragma(tic) shader composition.


Third approach is the approach I like most. I wonder what others have to say 
about this, though...

Robert Milharcic
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Pragmatic shader - a new #pragma directive proposition

[Sebastian Messerschmidt]

Am 14.01.2016 um 11:56 schrieb Robert Milharcic:

On 14.1.2016 9:52, Sebastian Messerschmidt wrote:

Hi Robert,

This seems more complicated than needed.
Why not pass the number of lights as a compile time constant

#pragma import_defines (NUM_LIGHTS)

shader_state->setDefine("NUM_LIGHTS",12);

and use uniform arrays:

uniform vec4 u_LightColor[NUM_LIGHTS];

for (int i = 0; i < NUM_LIGHTS;++i)
{
light+=calcLight(u_LightColor[i], ...):
}

I feel your approach will bloat the preprocessor code path and will 
complicate the use. 


Hi Sebastian,

First, thank you for your input. Yes, that is more or less the same 
approach I'm currently using. The downside of this approach is that it 
requires additional nontrivial code logic for the uniform array 
management (u_LightColor) and that is why I started to look at the 
alternatives.
What could be more complicated there than to setup individual uniforms? 
Sorry this doesn't pass as a valid argument. If you have to hold the 
number of used lights somewhere you can hold a reference to the uniform 
as well.


There is also an upper limit for the size of the array that needs to 
be taken into account. 
At least 512. If this is not enough you can use Uniform buffer objects 
(UBO)[1] or Shader Storage Blocks[2] which support
If this is not enough for your light-count you will probably hit 
performance problems first.


Also, the loop represents unnecessary overhead (though, this is not a 
problem on a never hardware). 
That's an assumption of yours. Usually constant folded loops with single 
return and without break, continue-statements are unrolled by the compiler.

I'll accept performance comparisons however ;)

On the other hand, my suggestion fits well into existing pragmatic 
shader composition logic and probably has less downsides.


Downside is that you're trying to invent a meta-language here out of 
reasons that I commented on. The downside of your approach is a 
preprocessor language with no clear advantages over the tools already at 
your disposal.
So to say, the current language is already turing-complete and you're 
trying to put some syntactic sugar on top, which adds some high degree 
of complexity to the parser and to the shader-code.


An alternative for you is to manage this part yourself by simply 
overriding the parts managing the define-states. Maybe Robert O. can 
fill in on the details here.


Cheers
Sebastian


[1]https://www.opengl.org/wiki/Interface_Block_%28GLSL%29#Uniform_blocks
[2]https://www.opengl.org/wiki/Interface_Block_%28GLSL%29#Shader_storage_blocks



Cheers,
Robert Milharcic
___
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

Re: [osg-users] Pragmatic shader - a new #pragma directive proposition

[Robert Milharcic]

Hi Sebastian,

First of all, the lightning shader only illustrates one of the cases where 
(optionally) repeating a code block containing substitution parameter can be 
useful. I used the multi-light lightning as an illustration only.


First, thank you for your input. Yes, that is more or less the same approach 
I'm currently using. The downside of this approach is that it requires 
additional nontrivial code logic for the uniform array management 
(u_LightColor) and that is why I started to look at the alternatives.

What could be more complicated there than to setup individual uniforms? Sorry 
this doesn't pass as a valid argument. If you have to hold the number of used 
lights somewhere you can hold a reference to the uniform as well.



Sorry, but that is not what I had in mind.  The problem here is the management of the array 
uniform's content and not the reference to it or the light count etc. Let say I only want to 
disable one of the lights, say LIGHT0 eg. stateset->setDefines("LIGHT0", 
osg::StateAttribute::OFF). What will you do?

There is also an upper limit for the size of the array that needs to be taken into account. 

At least 512. If this is not enough you can use Uniform buffer objects (UBO)[1] 
or Shader Storage Blocks[2] which support
If this is not enough for your light-count you will probably hit performance 
problems first.



Yes, that is true. The upper limit is not a problem for this specific 
multi-light problem.

Also, the loop represents unnecessary overhead (though, this is not a problem on a never hardware). 

That's an assumption of yours. Usually constant folded loops with single return 
and without break, continue-statements are unrolled by the compiler.
I'll accept performance comparisons however ;)



Yes, you are right about that. The constant loop will most probably be unrolled 
by the compiler. Of courses, that is another assumption on top of the previous 
assumption :)


On the other hand, my suggestion fits well into existing pragmatic shader 
composition logic and probably has less downsides.


Downside is that you're trying to invent a meta-language here out of reasons 
that I commented on. The downside of your approach is a preprocessor language 
with no clear advantages over the tools already at your disposal.
So to say, the current language is already turing-complete and you're trying to 
put some syntactic sugar on top, which adds some high degree of complexity to 
the parser and to the shader-code.


Exactly, that was my intention, to add a higher degree of complexity and hopefully solve 
some problems that "turing-complete" language can't.


An alternative for you is to manage this part yourself by simply overriding the 
parts managing the define-states. Maybe Robert O. can fill in on the details 
here.

Cheers
Sebastian



Cheers,
Robert Milharcic
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Pragmatic shader - a new #pragma directive proposition

[Trajce Nikolov NICK]

Hi Robert M.

I went through this thread fast and I see you are trying (at least your
show case) is lighting and use of shader composition. The approach you are
taking is what I was using too, some years ago. But there are other methods
that does not require any mods and will work just fine with the existing
shader composition features. You can for example encode all the light
attributes into a texture buffer object (think of this as an image where
each float texel is one light attribute like color, etc).

Have a look at this, it is Forward+ implementation in opensource project
https://www.youtube.com/watch?v=beSkETJ_vgY

We are releasing a new version with F+ lighting available these days, so
you might want to keep an eye on it.

Cheers,
Nick

On Thu, Jan 14, 2016 at 3:20 PM, Robert Osfield 
wrote:

> Hi Robert M. et. al.
>
> I don't have any answers/recommendations at this stage but one first
> reading the proposal has relative to traditional C/C++ features seems
> a bit out of place.
>
> #pragma(tic) shader composition currently have a very close mapping to
> C macro's, my hope has always been that because of this close mapping
> it'd be quick to pick up and use - this is one of the key reasons why
> I went for this approach to shader composition.
>
> This makes me wonder if C/C++ features itself might be able to inspire
> any proposed extensions to #pragma(tic) shader composition.
>
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
trajce nikolov nick
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Pragmatic shader - a new #pragma directive proposition

[Robert Osfield]

Hi Robert M. et. al.

I don't have any answers/recommendations at this stage but one first
reading the proposal has relative to traditional C/C++ features seems
a bit out of place.

#pragma(tic) shader composition currently have a very close mapping to
C macro's, my hope has always been that because of this close mapping
it'd be quick to pick up and use - this is one of the key reasons why
I went for this approach to shader composition.

This makes me wonder if C/C++ features itself might be able to inspire
any proposed extensions to #pragma(tic) shader composition.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Anyone Experimenting with OSVR

[David Glenn]

dimi christop wrote:
> I also just got my Unit.
> The say that the HDK 1.3 hav superior lenses compared to the DK2.
> OSG support should be possible taking the osvrtrackviewer code as a starting 
> point . They use side-side split screen stereo.
> 
> 
> Dimi
> 
> 
> 
> 
> 
> 
> 
> On Tuesday, December 8, 2015 8:50 PM, David Glenn <> wrote:
> 
> 
> 
> Greetings All!
> 
> Got my OSVR HDKv1.3 last week! I had to wait till the weekend to really try 
> it out and there are still parts of it that I have not tried out yet (like 
> the IR camera). So far most of the effort has been testing what works and 
> what is a work in progress. One thing that I noticed off the bat is that the 
> screen is only at an HD level. 
> 
> Also, I'm evaluating it using game development software. So I'm going off the 
> deep end right out of the box. I feel comfortable doing this given that I 
> have already been dabbling in Oculus Rift from the start, so I can compare 
> and contrast. So far, I have dealt with Dev Kit 1 and have dabbled with DK2 
> and other demos and this is just another notch in the belt for me, but most 
> of this has been done using Unity because it more geared to what my handlers 
> expect me to develop to theses days. 
> 
> However, I am always looking at subjects that I can learn and give talks 
> about and I'm getting a little sick of talking terrain. VR has a little more 
> meat on bones and it would be nice to get something working in VR for the 
> next SIGGRAPH BOF. 
> 
> Oh, and it looking at it, there seems to be at least one OSVR test app that 
> uses OSG, but it's not a VR Demo as it is just a way to test head tracking 
> movement. 
> 
> ... 
> 
> Thank you!
> 
> Cheers,
> David
> 
> 
> David Glenn
> ---
> D Glenn 3D Computer Graphics Entertainment.
> www.dglenn.com
> 
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=65828#65828 
> (http://forum.openscenegraph.org/viewtopic.php?p=65828#65828)
> 
> 
> 
> 
> 
> ___
> osg-users mailing list
>  ()
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org 
> (http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org)
> 
>  --
> Post generated by Mail2Forum


So far I have only tried the IR camera once with limited success! The internal 
accelerometer seems to work well enough for me so I've just been using that 
alone for now. They have a Unity plug-in and it has it's own version of the 
server that I've been using. I have made some Unity test Demos using that and 
it has been working well. 

I'm going to whip up some simulation demo and attach OSVR (and later Oculus 
Rift) to it. Maybe John will let me demo it at one of his BOF's at Siggraph 
this year. I may give a pretention at one of the fan cons - like at Dragon Con. 
 

I'm almost putting the PowerPoint presentation together as I speak.

Using this stuff, I'm reminded of the tracking stuff that I used to do when was 
working in immersive simulation. Especially the tracking! I used to use that 
tracking hardware that InterSense made long ago! I know that it's exactly like 
the good old days, but it surprisingly close - even better in some ways! :)


David Glenn
---
D Glenn 3D Computer Graphics Entertainment.
www.dglenn.com

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=66020#66020





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Pragmatic shader - a new #pragma directive proposition

[Robert Milharcic]

Hi Sebastian ,

On 14.1.2016 15:47, Sebastian Messerschmidt wrote:

Am 14.01.2016 um 15:01 schrieb Robert Milharcic:

Hi Sebastian,

First of all, the lightning shader only illustrates one of the cases where 
(optionally) repeating a code block containing substitution parameter can be 
useful. I used the multi-light lightning as an illustration only.


First, thank you for your input. Yes, that is more or less the same approach 
I'm currently using. The downside of this approach is that it requires 
additional nontrivial code logic for the uniform array management 
(u_LightColor) and that is why I started to look at the alternatives.

What could be more complicated there than to setup individual uniforms? Sorry 
this doesn't pass as a valid argument. If you have to hold the number of used 
lights somewhere you can hold a reference to the uniform as well.



Sorry, but that is not what I had in mind.  The problem here is the management of the array 
uniform's content and not the reference to it or the light count etc. Let say I only want to 
disable one of the lights, say LIGHT0 eg. stateset->setDefines("LIGHT0", 
osg::StateAttribute::OFF). What will you do?

Let's say you have a fixed maximum on N, than you create a UBO/Array of this 
size and provide a count-uniform for the maximum valid entries.
If a light gets disabled, you simply remove it, copy it to the back and set 
your count to N-1.
In the shader you simply loop from 0 to count instead of N. That might break 
compiler optimization, but it won't hurt too much I guess.
When using the setDefine, OSG will have to issue a recompile of this new 
variant, which will degrade performance if all combinations are needed.

Assume 16 Lightsource, that will produce 65536 possible shader programs ... and 
that is only 16, not 500, or 1000 ...
Having 1024 individually switchable Lightsources would totally wreck your idea 
of having an alternative to my solution.
2^1024 might exceed the numbers of atoms in the known universe, so there is not 
a remote chance to solve this with shader combinations...



The question was purely rhetorical. I just wanted to prove my point regarding the 
uniform's content management vs already provided setDefines("LIGHT0", 
osg::StateAttribute::OFF). I didn't expect all that. Sorry for the fuzz :)  BTW, I'm not 
planing to toggle all possible on/off combinations just to see all the permutations, the 
normal graph usage is what I'm after.



There is also an upper limit for the size of the array that needs to be taken into account. 

At least 512. If this is not enough you can use Uniform buffer objects (UBO)[1] 
or Shader Storage Blocks[2] which support
If this is not enough for your light-count you will probably hit performance 
problems first.



Yes, that is true. The upper limit is not a problem for this specific 
multi-light problem.

Even so, UBOs support in the order of ten-tousands. If this is still isn't 
enough, a texture will provide maximum space.
Might be your example, but the number of individual uniforms is less than that. 
And putting a heap of uniforms into the stateset will fasten the handbrake on 
the CPU side.


Also, the loop represents unnecessary overhead (though, this is not a problem on a never hardware). 

That's an assumption of yours. Usually constant folded loops with single return 
and without break, continue-statements are unrolled by the compiler.
I'll accept performance comparisons however ;)



Yes, you are right about that. The constant loop will most probably be unrolled 
by the compiler. Of courses, that is another assumption on top of the previous 
assumption :)


On the other hand, my suggestion fits well into existing pragmatic shader 
composition logic and probably has less downsides.


Downside is that you're trying to invent a meta-language here out of reasons 
that I commented on. The downside of your approach is a preprocessor language 
with no clear advantages over the tools already at your disposal.
So to say, the current language is already turing-complete and you're trying to 
put some syntactic sugar on top, which adds some high degree of complexity to 
the parser and to the shader-code.


Exactly, that was my intention, to add a higher degree of complexity and hopefully solve 
some problems that "turing-complete" language can't.

Turing complete solves all computable problems ;-)
I do understand your motivation, but I still don't see the gain really.
I've presented some alternative ways to solve your problem, as I came across 
some of those challenges too.
The idea Robert mentioned might be a good one, basically we could use some kind 
of callback to let the user-code preprocess the shader, wait actually we can 
already do this, when it is loaded via a LoadCallback :-)
Actually I'm preprocessing my shader code when it's loaded to perform "include" and 
automated shader-define setup, so this might work for your "loop" too.



That would defeat the purpose of the #pragma(tic) shader 

Re: [osg-users] Pragmatic shader - a new #pragma directive proposition

[Sebastian Messerschmidt]

Am 14.01.2016 um 15:01 schrieb Robert Milharcic:

Hi Sebastian,

First of all, the lightning shader only illustrates one of the cases 
where (optionally) repeating a code block containing substitution 
parameter can be useful. I used the multi-light lightning as an 
illustration only.


First, thank you for your input. Yes, that is more or less the same 
approach I'm currently using. The downside of this approach is that 
it requires additional nontrivial code logic for the uniform array 
management (u_LightColor) and that is why I started to look at the 
alternatives.
What could be more complicated there than to setup individual 
uniforms? Sorry this doesn't pass as a valid argument. If you have to 
hold the number of used lights somewhere you can hold a reference to 
the uniform as well.




Sorry, but that is not what I had in mind.  The problem here is the 
management of the array uniform's content and not the reference to it 
or the light count etc. Let say I only want to disable one of the 
lights, say LIGHT0 eg. stateset->setDefines("LIGHT0", 
osg::StateAttribute::OFF). What will you do?
Let's say you have a fixed maximum on N, than you create a UBO/Array of 
this size and provide a count-uniform for the maximum valid entries.
If a light gets disabled, you simply remove it, copy it to the back and 
set your count to N-1.
In the shader you simply loop from 0 to count instead of N. That might 
break compiler optimization, but it won't hurt too much I guess.
When using the setDefine, OSG will have to issue a recompile of this new 
variant, which will degrade performance if all combinations are needed.


Assume 16 Lightsource, that will produce 65536 possible shader programs 
... and that is only 16, not 500, or 1000 ...
Having 1024 individually switchable Lightsources would totally wreck 
your idea of having an alternative to my solution.
2^1024 might exceed the numbers of atoms in the known universe, so there 
is not a remote chance to solve this with shader combinations...





There is also an upper limit for the size of the array that needs to 
be taken into account. 
At least 512. If this is not enough you can use Uniform buffer 
objects (UBO)[1] or Shader Storage Blocks[2] which support
If this is not enough for your light-count you will probably hit 
performance problems first.




Yes, that is true. The upper limit is not a problem for this specific 
multi-light problem.
Even so, UBOs support in the order of ten-tousands. If this is still 
isn't enough, a texture will provide maximum space.
Might be your example, but the number of individual uniforms is less 
than that. And putting a heap of uniforms into the stateset will fasten 
the handbrake on the CPU side.


Also, the loop represents unnecessary overhead (though, this is not 
a problem on a never hardware). 
That's an assumption of yours. Usually constant folded loops with 
single return and without break, continue-statements are unrolled by 
the compiler.

I'll accept performance comparisons however ;)



Yes, you are right about that. The constant loop will most probably be 
unrolled by the compiler. Of courses, that is another assumption on 
top of the previous assumption :)


On the other hand, my suggestion fits well into existing pragmatic 
shader composition logic and probably has less downsides.


Downside is that you're trying to invent a meta-language here out of 
reasons that I commented on. The downside of your approach is a 
preprocessor language with no clear advantages over the tools already 
at your disposal.
So to say, the current language is already turing-complete and you're 
trying to put some syntactic sugar on top, which adds some high 
degree of complexity to the parser and to the shader-code.


Exactly, that was my intention, to add a higher degree of complexity 
and hopefully solve some problems that "turing-complete" language can't.

Turing complete solves all computable problems ;-)
I do understand your motivation, but I still don't see the gain really.
I've presented some alternative ways to solve your problem, as I came 
across some of those challenges too.
The idea Robert mentioned might be a good one, basically we could use 
some kind of callback to let the user-code preprocess the shader, wait 
actually we can already do this, when it is loaded via a LoadCallback :-)
Actually I'm preprocessing my shader code when it's loaded to perform 
"include" and automated shader-define setup, so this might work for your 
"loop" too.



Cheers
Sebastian


An alternative for you is to manage this part yourself by simply 
overriding the parts managing the define-states. Maybe Robert O. can 
fill in on the details here.


Cheers
Sebastian



Cheers,
Robert Milharcic
___
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] Color array always red

[Carlos Meira]

Hi,
Im trying create a simple white quad but it is always red. 
I took the example osgGeometry like this...

osg::Geode* geode = new osg::Geode();

// create Geometry object to store all the vertices and lines primitive.
osg::Geometry* polyGeom = new osg::Geometry();

osg::ref_ptr shared_colors = new osg::Vec4Array;
shared_colors->push_back(osg::Vec4(1.0f,1.0f,1.0f,1.0f));


osg::ref_ptr shared_normals = new osg::Vec3Array;
shared_normals->push_back(osg::Vec3(0.0f,-1.0f,0.0f));

float width = 1000.0f;
float height = 1000.0f;
// note, anticlockwise ordering.
osg::Vec3 myCoords[] =
{
osg::Vec3((width/2)*(-1),(height/2)*(-1),  0.0f),
osg::Vec3(width/2,(height/2)*(-1), 0.0f),
osg::Vec3(width/2,height/2 ,  0.0f),
osg::Vec3((width/2)*(-1),  height/2,  0.0f),


osg::Vec3(0.238942, 0.0f, -0.251302),
osg::Vec3(0.333696, 0.0f, 0.0329576),
osg::Vec3(0.164788, 0.0f, -0.0453167),
osg::Vec3(0.13595,  0.0f, -0.255421)
};

int numCoords = sizeof(myCoords)/sizeof(osg::Vec3);

osg::Vec3Array* vertices = new osg::Vec3Array(numCoords,myCoords);

// pass the created vertex array to the points geometry object.
polyGeom->setVertexArray(vertices);

// use the shared color array.
polyGeom->setColorArray(shared_colors.get(), osg::Array::BIND_OVERALL);


// use the shared normal array.
polyGeom->setNormalArray(shared_normals.get(), osg::Array::BIND_OFF);


// This time we simply use primitive, and hardwire the number of coords 
to use
// since we know up front,
polyGeom->addPrimitiveSet(new 
osg::DrawArrays(osg::PrimitiveSet::QUADS,0,numCoords));


  //  printTriangles("Quads",*polyGeom);

// add the points geometry to the geode.
geode->addDrawable(polyGeom);

  
What I m doing wrong ??
... 

Thank you!

Cheers,
Carlos

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=65985#65985





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Pragmatic shader - a new #pragma directive proposition

[Robert Milharcic]

On 14.1.2016 15:20, Robert Osfield wrote:

Hi Robert M. et. al.

I don't have any answers/recommendations at this stage but one first
reading the proposal has relative to traditional C/C++ features seems
a bit out of place.

#pragma(tic) shader composition currently have a very close mapping to
C macro's, my hope has always been that because of this close mapping
it'd be quick to pick up and use - this is one of the key reasons why
I went for this approach to shader composition.

This makes me wonder if C/C++ features itself might be able to inspire
any proposed extensions to #pragma(tic) shader composition.

Robert.

Hi Robert O.

If I'm not mistaken, the #pragmadirective is used by the C/C++ preprocessor for 
providing additional information, beyond what the language itself can offer. I 
thought this was the main inspiration for #pragma(tic) shader composition. 
Anyway, based on feedback I'm now convinced that my proposition isn't that 
useful as I thought :)  and on that note, I rest my case.

Cheers
Robert Milharcic
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org