Thanks for that. Yes, I use 'texture packs' all the time for simple
animations, or diverse billboards from one big array of vertices.
I have done that both in vertex and fragment shaders before with POT
and NPOT textures.

I have also played with procedurally changing the vec2 I provide to
texture2D.
That works very well also.

The crash I think is something to do with vec4s as it happens with
both the mix and multiply commands.

Thanks for the idea of using vectors. I had not thought of that.
Fingers crossed.

Unless someone else can see a stupid error in the few lines I provided
I am going to put this down to a hangover from the days when Point
Sprites were less stable.

Kind regards,
Stephen.

On Aug 15, 2008, at 8:51 PM, Ben Supnik wrote:

I can't comment on the bug, but processing the point sprite tex
coordinates in the fragment shader should be possible...we
implemented texture atlasing this way - that is, we select a sub-
section of the texture within the fragment shader; I didn't see any
problems with running standard matrix math. I didn't try to use a
matrix, but you could easily put the 2x2 2-d rotation matrix into
vectors and implement the rotation using dot products...

But there has been historically some weirdness with point sprites --
things like texture coordinates not being generated at all. :-( If
you have multiple machines you might want to try different graphics
cards to find a stable platform.

cheers
ben

Stephen Northcott wrote:

OK.. This is pretty crude, but it is a test case...
varying vec4 Color;
varying mat4 matrix;
uniform sampler2D tex;
void main (void)
{
vec4 rot = matrix * gl_TexCoord[0];
vec4 col = texture2D(tex, rot.st);
// vec4 col2 = mix(col,Color,0.5);
gl_FragColor = col;
}
I send 'matrix' from the vertex shader for now like this..
matrix = gl_TextureMatrix[0];
(The rest of the shader is pretty long so I have left it out)
Both shaders compile fine for my program and also in Apple's Shader
Builder.
However, if either the mix statement, or the matrix multiplication,
are in the fragment shader this will crash my GPU instantly.
The mix statement I am not so worried about, and can be easily
removed. I just set gl_FragColor to col instead of col2.
If I simply copy gl_TexCoord[0].st to a vec2 called 'rot' obviously
nothing happens in terms of rotation but the shader works as
expected and I get a textured Point Sprite, but without rotation.
Can anyone see what I am doing wrong?
Cheers,
Stephen.
On Aug 15, 2008, at 6:37 PM, Paul Sargent wrote:

On 15 Aug 2008, at 12:06, Stephen Northcott wrote:

It is possible to rotate the texture in a Point Sprite via a
shader, isn't it?
I had a theory I thought would work and it isn't.. as far as I
can tell.

If we generate the texcoord values by multiply the texture unit's
coordinates by the relevant texture matrix in the vertex shader,
will that carry through from the vertex shader to the fragment
shader correctly?

I think, and somebody correct me if I'm wrong, that the vertex
shader is before the point sprite quad is created in the pipeline.
This means that the vertex shader is only being called once per
point sprite (i.e. on the actual point)

Therefore I think you have to either do it in the fragment shader,
or geometry shader if you have one (which would actually be
generating the point sprite quad anyway)

------------------------------------------------------------------------
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Mac-opengl mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Mac-opengl mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden

Apple Footer

This site contains user submitted content, comments and opinions and is for informational purposes only. Apple may provide or recommend responses as a possible solution based on the information provided; every potential issue may involve several factors not detailed in the conversations captured in an electronic forum and Apple can therefore provide no guarantee as to the efficacy of any proposed solutions on the community forums. Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Apple Support Communities Terms of Use.
Apple