Hi Robert Osfield et. al.,
On 14.1.2016 16:34, Robert Osfield wrote:
I'm still open to making the shader parsing extensible, it seems like
an interesting experimental tool.
As Sebastian already pointed out, the actual parsing can be done outside osg,
perhaps before Shader::setShaderSource() c
> Frankly, I never thought about multi-light problem this way. I wonder if
such technique can be generalized enough, e.g. hidden behind the scenes, so
the user of the lighting framework doesn't have to deal with the texture
objects
That is what I though when designing OpenIG. Since I sounded like
Hi Sebastian,
Hi Robert,
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 inpu
Hi Nick,
On 14.1.2016 15:31, Trajce Nikolov NICK wrote:
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
tha
Hi Robert,
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
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 u
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. An
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
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, tha
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 th
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 becaus
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 th
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);
an
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
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[N
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 t
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)
{
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_L
18 matches
Mail list logo
