thanks for getting back to me!
Good point. I’ve changed the code as you suggest, but oddly it still doesn’t work (although now in a slightly different way).
You should be able to check this by setting the scale to 1 allowing just one grid to be seen. There should then be one star visible with the shape being cut off at the edges.
Annoyingly it doesn’t mention this till half way down the page at the “20.2 Technical Considerations” section:
The wrap mode for the texture image should be set to CLAMP. Otherwise, we’ll see ghost samples where we shouldn’t. Alternatively, we can clamp the coordinates to the range [0…1]. Most GPUs have hardware to do this at no cost.
ah… I missed that bit! I can’t actually change the texture mode in the app I’m using, but I can clamp the sample position to the 0>1 range and see if that sorts things out.
I may just give up on this implementation, and try adapting the Orange Book texture bomb shader. I’m really interesting in the Voronoi implementation mentioned later on on the page, which I guess could be tweaked to fit in with the Orange Book method.
Yeah, that method gets rid off the texture lookup and applies a procedural texture instead. This is fine if primitive shapes is all that your want.
In the Book “Texturing and Modeling - A Procedural Approach” it manages to use a procedural texture of a star, but creating anything with a more complex design and your better off using a texture. So before you go I thought I might share with you my implementation that prevents the texture from displaying the repeating artefacts despite having GL_TEXTURE_WRAP set to GL_REPEAT.
Here is what you might expect to see with nothing stopping the texture from wrapping:
Then with the added checks it looks like this:
All it does is tell the shader to ignore placing the colour once its in the area outside the texture being placed. By doing these checks it also reduces the number of texture calls for each cell:
The only thing you need to watch out for is that you have to have the same texture cordinate system as me. This is my current set up:
Top Left = (0,1) | Top Right = (1,1)
Bottom Left = (0,0) | Bottom Right = (1,0)
If you have a different set up and cant change it on the OpenGL side then you will have to change some of the code on the fragment shader to account for the different coordinate system.
Anyway I hope this is as much use as it was for me.
I should have mentioned that I’d replaced the texture lookup with a procedural circle in my code above. I did this mainly because I was working through the GPU Gems page primarily because I wanted to implement the Voronoi method mentioned later on. I did actually get somewhere near 20-10a, but it’s still a bit ‘glitchy’ in places.
I’d like to get to 20-10b, but I’m not to sure how to increase the number of samples per cell. In fact, this itself is only a stepping-stone to what I’m really after, which is some kind of realtime voronoi approximation based in live camera input rather than a random texture. I think the code will need quite a lot of tweaking to get to that though. I’ll need much larger variation in the sizes of the regions, which I guess means a smaller cell size, but more samples per cell. Lots of intriguing possibilities…