glsl shaders and sampler3d
simple first question.
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.
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.
Hi Aran
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 @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:
to read this:
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:
vec3(gl_LightSource[0].position);
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.
pelado
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.
in your post you said
"...doesn't respond to changing the parameters. if you change this line in the
jxs file:
to read this:
you should be able to adjust the position."
what were the words in the middle? must be a copy paste error or something.
thanks
aran
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.
> 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.
pelado
> 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.
wes
>
> > 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?)
pelado
The attachment didn't make through to the forum so here it is again
pelado
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
>
>
>
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.
wes