i've just committed an updated version of [text3d] that has a kind of anti-aliasing built-in.
it uses textures internally. the size of the texture (and thus the bluriness) can be controlled via the (revived) [precision( message.
the drawback is, that since the glyphs are textures, you cannot apply a texture on the text anymore (e.g. using [pix_texture]). since in older versions of Gem the texture was applied on each character rather than on the entire text, i think the usefulness of this feature was debatable.
in any case, you can get back to the original behaviour (with the ugly rendering) by sending an [alias 0( message (or actually an [antialias 0( message, which is the same).
let me know, whether this change breaks any patches.
fmdasr IOhannes
PS: due to a bug in FTGL, the new object will eventually crash pd/Gem if you chose a very high fontsize or precision (actually, fontsize*precision is the value that matters) and your openGL implementation has a limited texture size. i've submitted a bugreport to the debian package of FTGL that fixes the problem.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Le 14/04/2014 15:40, IOhannes m zmölnig a écrit :
i've just committed an updated version of [text3d] that has a kind of anti-aliasing built-in.
it uses textures internally. the size of the texture (and thus the bluriness) can be controlled via the (revived) [precision( message.
The precision message depends on the gemwin dimen ? If precision=1 then the texture size is the size of gemwin ? If precision=2 then the texture size is the double size of gemwin ? etc. ?
the drawback is, that since the glyphs are textures, you cannot apply a texture on the text anymore (e.g. using [pix_texture]). since in older versions of Gem the texture was applied on each character rather than on the entire text, i think the usefulness of this feature was debatable.
in any case, you can get back to the original behaviour (with the ugly rendering) by sending an [alias 0( message (or actually an [antialias 0( message, which is the same).
let me know, whether this change breaks any patches.
Why, the default is [antialias 1( ? Should be [antialias 0(, no ? Because it will break patches...
fmdasr IOhannes
PS: due to a bug in FTGL, the new object will eventually crash pd/Gem if you chose a very high fontsize or precision (actually, fontsize*precision is the value that matters) and your openGL implementation has a limited texture size. i've submitted a bugreport to the debian package of FTGL that fixes the problem.
Yep, crash here with [antialias 93(. On Ubuntu 13.10, Pd 0.45.0test 2, Gem ver: 0.93.git c68159c ++
Jack
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-04-15 20:42, Jack wrote:
Le 14/04/2014 15:40, IOhannes m zmölnig a écrit :
i've just committed an updated version of [text3d] that has a kind of anti-aliasing built-in.
it uses textures internally. the size of the texture (and thus the bluriness) can be controlled via the (revived) [precision( message.
The precision message depends on the gemwin dimen ? If precision=1 then the texture size is the size of gemwin ? If precision=2 then the texture size is the double size of gemwin ? etc. ?
if so, then i guess it's a bug.
let me know, whether this change breaks any patches.
Why, the default is [antialias 1( ? Should be [antialias 0(, no ? Because it will break patches...
this depends on what *you all* say. if it will break indeed "a lot" of patches (whatever a lot means), i will revert the default to antialias=0.
but i would prefer if we could use the antialiased version as the default (as i expect it to be more useful in general).
mfgasdr IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Le 16/04/2014 10:45, IOhannes m zmoelnig a écrit :
On 2014-04-15 20:42, Jack wrote:
Le 14/04/2014 15:40, IOhannes m zmölnig a écrit :
i've just committed an updated version of [text3d] that has a kind of anti-aliasing built-in.
it uses textures internally. the size of the texture (and thus the bluriness) can be controlled via the (revived) [precision( message.
The precision message depends on the gemwin dimen ? If precision=1 then the texture size is the size of gemwin ? If precision=2 then the texture size is the double size of gemwin ? etc. ?
if so, then i guess it's a bug.
I don't know, it was just a guess. What is the behavior of precision on antialiasing then ?
let me know, whether this change breaks any patches.
Why, the default is [antialias 1( ? Should be [antialias 0(, no ? Because it will break patches...
this depends on what *you all* say. if it will break indeed "a lot" of patches (whatever a lot means), i will revert the default to antialias=0.
but i would prefer if we could use the antialiased version as the default (as i expect it to be more useful in general).
Hmm, people who used to use FSAA message to manage antialiasing for their fonts, will have something different in the 3D scene. And people who applied texture on their fonts, won't be able to apply them. So for me it is important to have [antialias 0( as default. ++
Jack
mfgasdr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Le 16/04/2014 11:49, Jack a écrit :
but i would prefer if we could use the antialiased version as the default (as i expect it to be more useful in general).
Hmm, people who used to use FSAA message to manage antialiasing for their fonts, will have something different in the 3D scene. And people who applied texture on their fonts, won't be able to apply them. So for me it is important to have [antialias 0( as default.
I think text3d was so ugly without anti-aliasing that it was almost not usable. and i dont mind breaking few patch for the better.
but if it cause to much trouble, maybe text3d can be renamed in 3dtext (or somthing else), and a text3d abstraction can be made for compatibility with old patch.
cheers c
On 04/16/2014 11:49 AM, Jack wrote:
if so, then i guess it's a bug.
I don't know, it was just a guess. What is the behavior of precision on antialiasing then ?
it's not a real "anti-alias". it's rendering the font onto a texture of a given size (evtl. rather small) and then scaling the texture to your needs. so the bluriness does not depend on the window size.
attached is a snapshot of two Gem windows displying text at "precision=0.1", the left one is 250x250, the right one 500x500. the text on the small screen is [scale 2]d to have the same size as on the big screen. as you can see, they look the same.
fgdsar IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
OK, thanx to share. ++
Jack
Le 16/04/2014 17:25, IOhannes m zmölnig a écrit :
On 04/16/2014 11:49 AM, Jack wrote:
if so, then i guess it's a bug.
I don't know, it was just a guess. What is the behavior of precision on antialiasing then ?
it's not a real "anti-alias". it's rendering the font onto a texture of a given size (evtl. rather small) and then scaling the texture to your needs. so the bluriness does not depend on the window size.
attached is a snapshot of two Gem windows displying text at "precision=0.1", the left one is 250x250, the right one 500x500. the text on the small screen is [scale 2]d to have the same size as on the big screen. as you can see, they look the same.
fgdsar IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On 04/16/2014 11:49 AM, Jack wrote:
Hmm, people who used to use FSAA message to manage antialiasing for their fonts, will have something different in the 3D scene.
yes they will, but the question is, whether this hurts. openGL never guarantees pixel-accurate rendering across implementations, so (in theory) your scene can look differently when you upgrade your drivers. and FSAA never consistently worked across all platforms.
And people who applied texture on their fonts, won't be able to apply them.
yes. that's probably more of a problem. one possibility would be to detect whether there is a texture in the gemlist, and if so, fall back to the old behaviour (at least in some default "autotexture" mode)
another would be to allow configuring the default [text3d] backend via gem.conf.
So for me it is important to have [antialias 0( as default.
how many of your patches would be broken?
gfmdars IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Le 16/04/2014 17:30, IOhannes m zmölnig a écrit :
On 04/16/2014 11:49 AM, Jack wrote:
Hmm, people who used to use FSAA message to manage antialiasing for their fonts, will have something different in the 3D scene.
yes they will, but the question is, whether this hurts. openGL never guarantees pixel-accurate rendering across implementations, so (in theory) your scene can look differently when you upgrade your drivers. and FSAA never consistently worked across all platforms.
Yep, that's true.
And people who applied texture on their fonts, won't be able to apply them.
yes. that's probably more of a problem. one possibility would be to detect whether there is a texture in the gemlist, and if so, fall back to the old behaviour (at least in some default "autotexture" mode)
another would be to allow configuring the default [text3d] backend via gem.conf.
Don't know. For me, if you can't antialiased all geos, why you particulary want to antialiased the text3d object (even if I know why). There is the same problem on curve, small square, small circle, etc. Then, you have several possibilties working on all geos (with different result) : - - FSAA - - shaders - - upsampling
So for me it is important to have [antialias 0( as default.
how many of your patches would be broken?
0 % :) ++
Jack
gfmdars IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
About FSAA, does it works with Intel HD 4000 on Ubuntu 12.04 for anyone. I have no luck sending FSAA 2,4,6,8. Interestingly is the fact that egregore (the patch from chdh) have antialiasing (with the same setup). I think they use an opengl call (gemvertexbuffer?).
i don't think linux intel driver do have FSAA. if so, then a feature request should be filed in order to have fsaa in gem with intel card.
about egregore, i tried lot's of thing in order to improve rendering whatever hardware used. finally, i choose not to use hardware FSAA. since only line are rendered using a framebuffer, the patch render 2 time the same set of data with different line size properties. since the datas already are in the gpu, rendering a 2nd time the same lines is very fast.
c
Le 17/04/2014 23:36, puredata@11h11.com a écrit :
About FSAA, does it works with Intel HD 4000 on Ubuntu 12.04 for anyone. I have no luck sending FSAA 2,4,6,8. Interestingly is the fact that egregore (the patch from chdh) have antialiasing (with the same setup). I think they use an opengl call (gemvertexbuffer?).
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
egregore looks good and perform very nicely on my HD 4000. well done!
searching for HD 4000 antialising I found this post: https://communities.intel.com/thread/31912 ... Intel graphics built into the last two generations support MSAA (2x,4x,8x). ...
I think Gem supports FSAA, but not MSAA? à+
i fill a feature request for MSAA suport! c
Le 18/04/2014 04:47, puredata@11h11.com a écrit :
egregore looks good and perform very nicely on my HD 4000. well done!
searching for HD 4000 antialising I found this post: https://communities.intel.com/thread/31912 ... Intel graphics built into the last two generations support MSAA (2x,4x,8x). ...
I think Gem supports FSAA, but not MSAA? à+
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-
Cyrille Henry -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Jack -
puredata＠11h11.com