aranm

are 3d textures supported? can i pass one to a shader as a sampler3D. im using some of the orange book examples, and want to get the cloud or fire shader going which uses a passed in 3d texture for use as a noise function.

glsl-shaders-and-sampler3d

heres some shader patches ive been working on. they are max 5 patches developed in windows (don't know if that makes a difference). if you have any hassles with them working give us a hoy.

there is a couple of patches from the orange book. the lattice shader and the mandelbrot or julia set (forgot which one)

there is a parameter builder for specifying shader parameters on the fly (so i dont have to make message boxes all the time and i can be a little more flexible) and a couple of objects that pack vectors to pass to the shaders.

i am trying to get the shader working called cloudAnim.jxs. it requires a 3dtexture to be passed to it, basically the output from a noise function to use as a repeatable random number generator. this texture is traversed using an offset value, and when it works gives the appearance of moving clouds (whispy ones not the big fluffy types). any help would be most appreciated.

p.s. these patches are early attempts, ive just started using max and im sure a lot of the code used here will be refined in upcoming iterations. all comments most welcome.

In your patch there are a couple of things that should be corrected:

you need to enable the depth buffer for the window (@depthbuffer 1).

in order to get a texture with your objects you can change two things;

first, give a texture unit a name using the @name [shademe] attribute, and

second pass the message "texture [shademe]" to the object you want to

utilise the texture, in your patch it would be jit.gl.model, or you can use

the cloudanim.jxs shader works except for one thing, the light position

doesn't respond to changing the parameters. if you change this line in the

you should be able to adjust the position.

I may be wrong here, (I haven't checked it) but I think if you want to use

the state variable you should put something like this in the shader code:

I couldn't get the inferno shader to work, it loads without any errors but

the screen just goes black. But, this doesn't mean that there's a problem

with the shader code, it more likely is the fact that my graphics card is a

Seeing your patch reminded me that I have an abstraction that gives you

access to editing shader parameters. I'll put it up on my website soon.

On Tue, Sep 2, 2008 at 2:43 PM, Aran wrote:

> heres some shader patches ive been working on. they are max 5 patches

> developed in windows (don't know if that makes a difference). if you have

> any hassles with them working give us a hoy.

> there is a couple of patches from the orange book. the lattice shader and

> the mandelbrot or julia set (forgot which one)

> there is a parameter builder for specifying shader parameters on the fly

> (so i dont have to make message boxes all the time and i can be a little

> more flexible) and a couple of objects that pack vectors to pass to the

> i am trying to get the shader working called cloudAnim.jxs. it requires a

> 3dtexture to be passed to it, basically the output from a noise function to

> use as a repeatable random number generator. this texture is traversed using

> an offset value, and when it works gives the appearance of moving clouds

> (whispy ones not the big fluffy types). any help would be most appreciated.

> p.s. these patches are early attempts, ive just started using max and im

> sure a lot of the code used here will be refined in upcoming iterations. all

first, give a texture unit a name using the @name [shademe] attribute, and
second pass the message "texture [shademe]" to the object you want to
utilise the texture, in your patch it would be jit.gl.model, or you can use
the @texture [shademe] attribute.

the cloudanim.jxs  shader works except for one thing, the light position
doesn't respond to changing the parameters.  if you change this line in the
jxs file:

I may be wrong here, (I haven't checked it) but I think if you want to use
the state variable you should put something like this in the shader code:

I couldn't get the inferno shader to work, it loads without any errors but
the screen just goes black.  But, this doesn't mean that there's a problem
with the shader code, it more likely is the fact that my graphics card is a
bit old.

Seeing your patch reminded me that I have an abstraction that gives you
access to editing shader parameters.  I'll put it up on my website soon.

On Tue, Sep 2, 2008 at 2:43 PM, Aran  wrote:

> heres some shader patches ive been working on. they are max 5 patches
> developed in windows (don't know if that makes a difference). if you have
> any hassles with them working give us a hoy.
>
> there is a couple of patches from the orange book. the lattice shader and
> the mandelbrot or julia set (forgot which one)
>
> there is a parameter builder for specifying shader parameters on the fly
> (so i dont have to make message boxes all the time and i can be a little
> more flexible) and a couple of objects that pack vectors to pass to the
> shaders.
>
> i am trying to get the shader working called cloudAnim.jxs. it requires a
> 3dtexture to be passed to it, basically the output from a noise function to
> use as a repeatable random number generator. this texture is traversed using
> an offset value, and when it works gives the appearance of moving clouds
> (whispy ones not the big fluffy types). any help would be most appreciated.
>
>
> p.s. these patches are early attempts, ive just started using max and im
> sure a lot of the code used here will be refined in upcoming iterations. all
> comments most welcome.
>
>
>

thanks for the help ill try this stuff tonight and post the working solution when its going. i'd like to get the complete orange book examples going.

"...doesn't respond to changing the parameters. if you change this line in the

you should be able to adjust the position."

what were the words in the middle? must be a copy paste error or something.

"...doesn't respond to changing the parameters. if you change this line in the
jxs file:

for these kind of forum anomalies, check the mail-list archive:

https://cycling74.com/pipermail/jitter/2008-September/016900.html

to retrieve the light position, as pelado suggested, use gl_LightSource[0].position. this way you can interact with it through the max gl.render interface. no need to make it a param/uniform.

3d textures should work as expected with jitter. i believe there's some examples of there use in the jitter-render examples folder.

for these kind of forum anomalies, check the mail-list archive:
https://cycling74.com/pipermail/jitter/2008-September/016900.html

to retrieve the light position, as pelado suggested, use gl_LightSource[0].position. this way you can interact with it through the max gl.render interface.  no need to make it a param/uniform.

> to retrieve the light position, as pelado suggested, use

> gl_LightSource[0].position. this way you can interact with it through the

> max gl.render interface. no need to make it a param/uniform.

> Actually, thinking about this, I think the method that Aran was using

should work to get the state variable light position passed to the shader.

(ie adding it to the paramater list in the jxs file). On trying it, the

shader is indeed aware of changes to the state lighting position but doesn't

update the pipeline unless something triggers it. When I change the param

lightposition in the shader the light position jumps to the state variable

Some of the shaders shipped with Jitter use Aran's approach, so I guess this

could be a bug, although there's no mention that I can find of using the

state variables inside shaders in the documentation.

> to retrieve the light position, as pelado suggested, use
> gl_LightSource[0].position. this way you can interact with it through the
> max gl.render interface.  no need to make it a param/uniform.
>
> Actually, thinking about this, I think the method that Aran was using
should work to get the state variable light position passed to the shader.
 (ie adding it to the paramater list in the jxs file).  On trying it, the
shader is indeed aware of changes to the state lighting position but doesn't
update the pipeline unless something triggers it.  When I change the param
lightposition in the shader the light position jumps to the state variable
position, if you follow me?
Some of the shaders shipped with Jitter use Aran's approach, so I guess this
could be a bug, although there's no mention that I can find of using the
state variables inside shaders in the documentation.

> Some of the shaders shipped with Jitter use Aran's approach, so I guess this

> could be a bug, although there's no mention that I can find of using the

> state variables inside shaders in the documentation.

If glEnable(GL_LIGHT0) and glLightf(GL_LIGHT0, GL_POSITION, ...) are

called, then this variable should be updated. It won't be in the

Jitter docs, but in the GLSL docs. I have noticed that if the

position isn't fully specified (i.e. all 4 position coordinates used)

that things might not work. In other words jit.gl.render

@light_position 1 1 1 0 or something similar. See:

http://www.opengl.org/sdk/docs/man/xhtml/glLight.xml

If you have a patch showing what's not working, I'll be happy to take a look.

> Some of the shaders shipped with Jitter use Aran's approach, so I guess this
> could be a bug, although there's no mention that I can find of using the
> state variables inside shaders in the documentation.

If glEnable(GL_LIGHT0) and glLightf(GL_LIGHT0, GL_POSITION, ...) are
called, then this variable should be updated.  It won't be in the
Jitter docs, but in the GLSL docs.  I have noticed that if the
position isn't fully specified (i.e. all 4 position coordinates used)
that things might not work.  In other words jit.gl.render
@light_position 1 1 1 0 or something similar.  See:
http://www.opengl.org/sdk/docs/man/xhtml/glLight.xml for more info on
the 4th coordinate.

> > Some of the shaders shipped with Jitter use Aran's approach, so I guess

> > could be a bug, although there's no mention that I can find of using the

> > state variables inside shaders in the documentation.

> If glEnable(GL_LIGHT0) and glLightf(GL_LIGHT0, GL_POSITION, ...) are

> called, then this variable should be updated. It won't be in the

> Jitter docs, but in the GLSL docs. I have noticed that if the

> position isn't fully specified (i.e. all 4 position coordinates used)

> that things might not work. In other words jit.gl.render

> @light_position 1 1 1 0 or something similar. See:

> If you have a patch showing what's not working, I'll be happy to take a

> Sorry, I should have a been a bit more explicit in what I was saying. This

was not a point about lighting as such, but about the method of calling

state variables within shaders in Jitter. What I meant was that I haven't

seen any documentation of how to call on state variables in the jitter JXS

wrapper. However, I have seen state variables being used as a uniform

variable in some of shaders included in the standard distribution of Jitter,

but these don't work. Or at least, not as I had expected.

For example, the mat.glass and mat.gooch JXS files call on the state

variables for lighting position and reveal the parameter to Jitter in the

same way as other uniform variables. I understand that these won't be

affected by passing the message 'param lightPos 1. 1. 1.' to the shader ,

but I did expect altering the lighting position via jit.gl.render would

update the shader's uniform variable. As I said in my message, the shader

doesn't reflect any change in the state light position unless it receives

some sort of trigger, such as trying to alter the parameter with a parameter

Your pointing out that all four light parameters may need to be included for

the light position variable would carry some logic. However, having just

tried it, the light position still doesn't seem to be updated.

Anyway, I've made up a patch that might help describe what is like a tongue

twister trying to explain in words. Its in the attached folder together

with my quick attempt at converting the JXS file to using a 4vec rather than

the 3vec included in the jitter gooch file.(maybe I did something wrong in

>
> > Some of the shaders shipped with Jitter use Aran's approach, so I guess
> this
> > could be a bug, although there's no mention that I can find of using the
> > state variables inside shaders in the documentation.
>
> If glEnable(GL_LIGHT0) and glLightf(GL_LIGHT0, GL_POSITION, ...) are
> called, then this variable should be updated.  It won't be in the
> Jitter docs, but in the GLSL docs.  I have noticed that if the
> position isn't fully specified (i.e. all 4 position coordinates used)
> that things might not work.  In other words jit.gl.render
> @light_position 1 1 1 0 or something similar.  See:
> http://www.opengl.org/sdk/docs/man/xhtml/glLight.xml for more info on
> the 4th coordinate.
>
> If you have a patch showing what's not working, I'll be happy to take a
> look.
>
> Sorry, I should have a been a bit more explicit in what I was saying.  This
was not a point about lighting as such, but about the method of calling
state variables within shaders in Jitter.  What I meant was that I haven't
seen any documentation of how to call on state variables in the jitter JXS
wrapper. However, I have seen state variables being used as a uniform
variable in some of shaders included in the standard distribution of Jitter,
but these don't work.  Or at least, not as I had expected.

For example, the mat.glass and mat.gooch JXS files call on the state
variables for lighting position and reveal the parameter to Jitter in the
same way as other uniform variables.  I understand that these won't be
affected by passing the message 'param lightPos 1. 1. 1.' to the shader ,
but I did expect altering the lighting position via jit.gl.render would
update the shader's uniform variable.  As I said in my message, the shader
doesn't reflect any change in the state light position unless it receives
some sort of trigger, such as trying to alter the parameter with a parameter
message.

Your pointing out that all four light parameters may need to be included for
the light position variable would carry some logic.  However, having just
tried it, the light position still doesn't seem to be updated.

Anyway, I've made up a patch that might help describe what is like a tongue
twister trying to explain in words.  Its in the attached folder together
with my quick attempt at converting the JXS file to using a 4vec rather than
the 3vec included in the jitter gooch file.(maybe I did something wrong in
altering the shader's code?)

The attachment didn't make through to the forum so here it is again

Thanks for the patch. I'll take a look and get back to you.

On Thu, Sep 4, 2008 at 4:51 PM, pelado wrote:

> The attachment didn't make through to the forum so here it is again

Thanks for the patch.  I'll take a look and get back to you.
wes

On Thu, Sep 4, 2008 at 4:51 PM, pelado  wrote:
> The attachment didn't make through to the forum so here it is again
>
> pelado
> --
> http://www.pelado.co.uk
>
>
>


Indeed there was a small logic bug that prevented state variables like

LIGHT0_POSITION from getting through after the first pass. This is

fixed and will be in the next incremental. In the meantime, you can

access OpenGL state like this directly form the OpenGL variables like

Hi Pelado,
Indeed there was a small logic bug that prevented state variables like
LIGHT0_POSITION from getting through after the first pass.  This is
fixed and will be in the next incremental.  In the meantime, you can
access OpenGL state like this directly form the OpenGL variables like
gl_LightSource[0].position.

glsl shaders and sampler3d