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?

hello,

the hap-codec (https://github.com/Vidvox/hap) uses the graphic card instead of the CPU for decoding, which would make it much faster at higher resoluions. appearently it's "a thing" in the world of vj-software.

a quick check on my system (ubuntu 16.04) reveals: - mplayer doesn't know what it is - ffmpeg, encodes and plays it (DEVIL), but doesn't know when to stop (keeps on playing the last frame) - pix_film claims it's just 1 frame at -1 fps

i followed the dependency chain and i think (not 100% sure) pix_film uses libquicktime, which in turn uses ffmpeg to play it.

i was wondering, how difficult it would be to add stable support for the hap-codec in Gem. maybe even bypassing libquicktime/ffmpeg alltogether?

has anyone looked into it yet?

many thanks for any input, ub

The other day i tried [pix_movie] with a HAP file and it worked (on Mac OS), although with non-satisfying performance, compared to Max/Jitter. I guess this is because it uses quicktime and the respective HAP quicktime component. My question is why the performance (frame rate) is far worse than in Max (or quicktime player). Is there any additional video texture transfer from/to GPU memory involved? thanks, Thomas

-- Thomas Grill http://grrrr.org

Am 21.09.2016 um 09:00 schrieb IOhannes m zmölnig zmoelnig@iem.at:

On 09/20/2016 09:26 PM, ub wrote:

...

i followed the dependency chain and i think (not 100% sure) pix_film uses libquicktime, which in turn uses ffmpeg to play it.

no. Gem can use a variety of backends to decode a video, using it's own plugin system. libquicktime is among them. libgmerlin is among them. others are as well...

...

i was wondering, how difficult it would be to add stable support for the hap-codec in Gem. maybe even bypassing libquicktime/ffmpeg alltogether?

just write a filmHAP plugin :-) the main problem is see is that the output of [pix_film] is a *pix*, that is a decoded image in main memory. i *guess* that HAP would benefit from leaving the image on the GPU memory and just making it available as a texture. unfortunately the "film" plugin architecture doesn't allow this.

there has been a proposal for a "texture source" plugin, but it hasn't got much attention from my side.

...

has anyone looked into it yet?

no.

fgmas IOhannes

---

GEM-dev mailing list GEM-dev@lists.iem.at https://lists.puredata.info/listinfo/gem-dev

On 21.09.2016 09:00, IOhannes m zmölnig wrote:

On 09/20/2016 09:26 PM, ub wrote:

...

i followed the dependency chain and i think (not 100% sure) pix_film uses libquicktime, which in turn uses ffmpeg to play it.

no. Gem can use a variety of backends to decode a video, using it's own plugin system. libquicktime is among them. libgmerlin is among them. others are as well...

thanks for the clarification. anything to do with codecs is by default a labyrinth, but i see a bit more clearly now.

i don't know, but i am suspecting libquicktime uses fmpeg codecs as fallbacks, as a) they don't list hap on their native codec list and b) ffmpeg seems the only library on my system supporting it. and i know libquicktime is handling movs as gmerlin is not enabled.

just to be sure, i tried and it can't play hap, and even crashes pd when trying.

...

i was wondering, how difficult it would be to add stable support for the hap-codec in Gem. maybe even bypassing libquicktime/ffmpeg alltogether?

just write a filmHAP plugin :-)

getting there. ;)

the reason i was looking at hap in the first place is that with two players at 1280x720 in one patch, the framerate drops to unacceptable <15fps that's because all procesing in the patch inlcuding the decoding is done one one cpu-core. i can gain a lot by running two players in separate pd instances. i can feed then pixes back to the main patch via shared memory.

the main problem is see is that the output of [pix_film] is a *pix*, that is a decoded image in main memory. i *guess* that HAP would benefit from leaving the image on the GPU memory and just making it available as a texture.

that's my guess too. and there's more optimizations possible down the line, with porting pixes to shaders.

so it's either to have one threaded, preloading, "superplayer" independent of pd or make the whole decoding and image processing much more lightweight.

unfortunately the "film" plugin architecture doesn't allow this.

but pix_movie could do that, yeah?

cheers, ub