hello
there is 2 way to do multi-texture : they are both documented in exemple/10.glsl/05_multitexture* I think you are right : not having a 2nd inlet texture should be ok.
May i suggest this interface, (a toggle better than a bang) :
[pix_snap2tex] | / [pix_texture] <-- handles binding/unbinding texture | | Toggle <-- automatic mipmaps generation when not available (1) / pass-through (0) | / [GEMglGenerateMipmap]
But on a 2nd thought, since pix_texture already generate the Mipmap when used in mode 2, I would expect them to be automatically generated in this case :
[pix_snap2tex] | / [pix_texture] <-- texture mode 2
can't pix_texture notice that mipmaps are not present and generate them? sorry for being naive : I haven't look at Gem code for a long time.
cheers c
Le 30/07/2016 à 04:10, Claude Heiland-Allen a écrit :
Hi,
On 29/07/16 20:49, cyrille henry wrote:
hello,
i'm not familiar with mipmaps,
They're pretty essential for texturing without ugly aliasing.
but i've got the impression that you have the solution : a new object GEMglGenerateMipmap,
Yes - I could try to write it (though I am busy with other things for a week or two).
with a 2nd inlet for the texture
Good point - I didn't think about that, was assuming manipulating the GL state machine, which would need a GEMglBindTexture - I guess Gem is a slightly higher level of abstraction? Or could it work to do something like this?
: [pix_snap2tex] | / [pix_texture] <-- handles binding/unbinding texture | [t a b] <-- or a more specific message than bang | / [GEMglGenerateMipmap] :
where a bang tells it to generate the mipmap on the next gemlist only, otherwise it acts as a simple pass-through. How does Gem handle multiple texture units? I guess it'd need a message to set that too.
Note that glGenerateMipmap is from OpenGL 3.0 according to docs.gl [1], though extensions enable it for earlier versions (it works fine on my Raspberry Pi which reports OpenGL 2.1 [2]).
And it only works for some texture types (notably, not rectangle textures), so it should check and emit an error if a wrong texture is passed.
[1] http://docs.gl/gl4/glGenerateMipmap [2] https://mathr.co.uk/blog/2016-07-30_puzzle_on_raspberry_pi.html
Thanks,
Claude
look a good solution for me.
cheers c
Le 29/07/2016 à 20:18, Claude Heiland-Allen a écrit :
Hi!
I've got a little patch that generates a fractal using texture feedback. It looks really bad if I don't enable mipmapping (texture quality 2), but pix_snap2tex doesn't regenerate the mipmaps. I hacked my local Gem to glGenerateMipmap(GL_TEXTURE_2D) after snapping, but this has some issues:
- maintaining local patches across several machines is annoy
- glGenerateMipmap is wasteful if mipmaps are not being used
The second issue makes me think the simplest solution would be a new object, perhaps GEMglGenerateMipmap, that I could put directly after pix_snap2tex to make it work. This would defer the problem to the patch level, an automagic system to track when mipmaps need to be regenerated would be a lot more work and probably break some bizarro use cases where mipmaps shouldn't be regenerated.
Thoughts?