[GEM-dev] mipmapping and pix_snap2tex and GEMgl*
cyrille henry
ch at chnry.net
Sat Jul 30 11:15:31 CEST 2016
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?
>
More information about the GEM-dev
mailing list