[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