hello, when using a framebuffer in a patch, the perspective of the main windows is change to (-1, 1) in X and Y. So it's no more possible to use custom perspective (sending the perspec message to gemwin is useless). moreover, the perspective used lead to distorted images when the gemwin is not square.
fixing this is quite easy, but will break all patch using frambuffer with a not square gem windows. so, i'm wondering if i should commit the fix.
the fix is mainly to replace line 145 of gemframebuffer.cpp :
glFrustum(-1,1,-1,1,1,25);
with :
float xDivy = (float)GemMan::m_w / (float)GemMan::m_h;
glFrustum(GemMan::m_perspect[0] * xDivy, GemMan::m_perspect[1] * xDivy, // left, right GemMan::m_perspect[2], GemMan::m_perspect[3], // bottom, top GemMan::m_perspect[4], GemMan::m_perspect[5]); // front, back
but it need to add #include "Base/GemMan.h"
and to move static int m_w; static int m_h; from private to public in GemMan.h
should i commit this?
cyrille
here is a patch that explain this problem.
cyrille
cyrille henry a écrit :
hello, when using a framebuffer in a patch, the perspective of the main windows is change to (-1, 1) in X and Y. So it's no more possible to use custom perspective (sending the perspec message to gemwin is useless). moreover, the perspective used lead to distorted images when the gemwin is not square.
fixing this is quite easy, but will break all patch using frambuffer with a not square gem windows. so, i'm wondering if i should commit the fix.
the fix is mainly to replace line 145 of gemframebuffer.cpp :
glFrustum(-1,1,-1,1,1,25);
with :
float xDivy = (float)GemMan::m_w / (float)GemMan::m_h;
glFrustum(GemMan::m_perspect[0] * xDivy, GemMan::m_perspect[1] * xDivy, // left, right GemMan::m_perspect[2], GemMan::m_perspect[3], // bottom, top GemMan::m_perspect[4], GemMan::m_perspect[5]); // front, back
but it need to add #include "Base/GemMan.h"
and to move static int m_w; static int m_h; from private to public in GemMan.h
should i commit this?
cyrille
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
#N canvas 282 295 603 298 10; #X msg 28 38 0 , destroy; #X obj 18 119 gemhead; #X obj 18 148 square 1; #X msg 18 15 reset , dimen 600 100 , create , 1; #X obj 18 172 gemhead 1; #X obj 18 249 gemframebuffer; #X obj 18 94 gemwin; #X obj 18 227 spigot 0; #X obj 63 205 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X msg 60 67 perspec -1 10 -1 1 1 20; #X text 227 16 <- 1; #X text 86 205 <- 2 : using frambuffer does change persective; #X text 228 67 <- 3 : custom perspective are usless with a frambuffer ; #X connect 0 0 6 0; #X connect 1 0 2 0; #X connect 3 0 6 0; #X connect 4 0 7 0; #X connect 7 0 5 0; #X connect 8 0 7 1; #X connect 9 0 6 0;
cyrille henry wrote:
here is a patch that explain this problem.
hi cyrille,
I think you are right, gemframebuffer should not affect the main window. Not sure why nobody noticed that before... but besides from that, I am not sure, how gemframebuffer should behave, if it should adjust to the world perspec or not. since framebuffer is ignoring the view, maybe it should also ignore the perspec? (and accept individual frustum message instead, and individual view?).
I posted a question about ortho some days ago, and would like to know if this is related? (when using ortho in non square windows everything is distorted, too).
marius.
cyrille
cyrille henry a écrit :
hello, when using a framebuffer in a patch, the perspective of the main windows is change to (-1, 1) in X and Y. So it's no more possible to use custom perspective (sending the perspec message to gemwin is useless). moreover, the perspective used lead to distorted images when the gemwin is not square.
fixing this is quite easy, but will break all patch using frambuffer with a not square gem windows. so, i'm wondering if i should commit the fix.
the fix is mainly to replace line 145 of gemframebuffer.cpp : glFrustum(-1,1,-1,1,1,25);
with : float xDivy = (float)GemMan::m_w / (float)GemMan::m_h;
glFrustum(GemMan::m_perspect[0] * xDivy, GemMan::m_perspect[1] * xDivy, // left, right GemMan::m_perspect[2], GemMan::m_perspect[3], // bottom, top GemMan::m_perspect[4], GemMan::m_perspect[5]); // front, back
but it need to add #include "Base/GemMan.h"
and to move static int m_w; static int m_h; from private to public in GemMan.h
should i commit this?
cyrille
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Le 25 mai 08 à 15:30, marius schebella a écrit :
cyrille henry wrote:
here is a patch that explain this problem.
hi cyrille,
I think you are right, gemframebuffer should not affect the main window. Not sure why nobody noticed that before... but besides from that, I am not sure, how gemframebuffer should behave, if it should adjust to the world perspec or not. since framebuffer is ignoring the view, maybe it should also ignore the perspec? (and accept individual frustum message instead, and individual view?).
I posted a question about ortho some days ago, and would like to know if this is related? (when using ortho in non square windows everything is distorted, too).
Just send [compat 0( to [ortho] and all should be fine with a rectangle gemwin. ++
Jack .
marius.
cyrille
cyrille henry a écrit :
hello, when using a framebuffer in a patch, the perspective of the main windows is change to (-1, 1) in X and Y. So it's no more possible to use custom perspective (sending the perspec message to gemwin is useless). moreover, the perspective used lead to distorted images when the gemwin is not square.
fixing this is quite easy, but will break all patch using frambuffer with a not square gem windows. so, i'm wondering if i should commit the fix.
the fix is mainly to replace line 145 of gemframebuffer.cpp : glFrustum(-1,1,-1,1,1,25);
with : float xDivy = (float)GemMan::m_w / (float)GemMan::m_h;
glFrustum(GemMan::m_perspect[0] * xDivy, GemMan::m_perspect[1] * xDivy, // left, right GemMan::m_perspect[2], GemMan::m_perspect[3], // bottom, top GemMan::m_perspect[4], GemMan::m_perspect[5]); // front, back
but it need to add #include "Base/GemMan.h"
and to move static int m_w; static int m_h; from private to public in GemMan.h
should i commit this?
cyrille
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Jack wrote:
Le 25 mai 08 à 15:30, marius schebella a écrit :
I posted a question about ortho some days ago, and would like to know if this is related? (when using ortho in non square windows everything is distorted, too).
Just send [compat 0( to [ortho] and all should be fine with a rectangle gemwin. ++
Jack
wow jack, thanks!! I never found that feature, because in the help file it does not make a difference whether you click compat or not. took me 4 years to solve that problem, and it was always in front of my nose... marius.
marius schebella a écrit :
cyrille henry wrote:
here is a patch that explain this problem.
hi cyrille,
I think you are right, gemframebuffer should not affect the main window. Not sure why nobody noticed that before... but besides from that, I am not sure, how gemframebuffer should behave, if it should adjust to the world perspec or not. since framebuffer is ignoring the view, maybe it should also ignore the perspec? (and accept individual frustum message instead, and individual view?).
for now, gemframbuffer does ignore view, perspective,color etc of the gemwin. The fix i submit did not change that. it just restore the perspective to it's correct value after drawing in the FB. i think the gemframbuffer should be albe to accept a perspec and view message, just like gemwin does. but that's something else.
cyrille
I posted a question about ortho some days ago, and would like to know if this is related? (when using ortho in non square windows everything is distorted, too).
marius.
cyrille
cyrille henry a écrit :
hello, when using a framebuffer in a patch, the perspective of the main windows is change to (-1, 1) in X and Y. So it's no more possible to use custom perspective (sending the perspec message to gemwin is useless). moreover, the perspective used lead to distorted images when the gemwin is not square.
fixing this is quite easy, but will break all patch using frambuffer with a not square gem windows. so, i'm wondering if i should commit the fix.
the fix is mainly to replace line 145 of gemframebuffer.cpp : glFrustum(-1,1,-1,1,1,25);
with : float xDivy = (float)GemMan::m_w / (float)GemMan::m_h;
glFrustum(GemMan::m_perspect[0] * xDivy, GemMan::m_perspect[1] * xDivy, // left, right GemMan::m_perspect[2], GemMan::m_perspect[3], // bottom, top GemMan::m_perspect[4], GemMan::m_perspect[5]); // front, back
but it need to add #include "Base/GemMan.h"
and to move static int m_w; static int m_h; from private to public in GemMan.h
should i commit this?
cyrille
_______________________________________________GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Le 25 mai 08 à 14:23, cyrille henry a écrit :
hello, when using a framebuffer in a patch, the perspective of the main windows is change to (-1, 1) in X and Y. So it's no more possible to use custom perspective (sending the perspec message to gemwin is useless). moreover, the perspective used lead to distorted images when the gemwin is not square.
fixing this is quite easy, but will break all patch using frambuffer with a not square gem windows. so, i'm wondering if i should commit the fix.
I prefer when [gemframebuffer] doesn't distort the image when the gemwin is not a square. Maybe it is possible to use an option (by default 'distort 1') for old patches and turn to 'distort 0' to get a normal image (without distort when the gemwin is not a square). What do you think about this ? ++
Jack
the fix is mainly to replace line 145 of gemframebuffer.cpp :
glFrustum(-1,1,-1,1,1,25);
with :
float xDivy = (float)GemMan::m_w / (float)GemMan::m_h;
glFrustum(GemMan::m_perspect[0] * xDivy, GemMan::m_perspect[1] * xDivy, // left, right GemMan::m_perspect[2], GemMan::m_perspect[3], // bottom, top GemMan::m_perspect[4], GemMan::m_perspect[5]); // front, back
but it need to add #include "Base/GemMan.h"
and to move static int m_w; static int m_h; from private to public in GemMan.h
should i commit this?
cyrille
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Jack a écrit :
Le 25 mai 08 à 14:23, cyrille henry a écrit :
hello, when using a framebuffer in a patch, the perspective of the main windows is change to (-1, 1) in X and Y. So it's no more possible to use custom perspective (sending the perspec message to gemwin is useless). moreover, the perspective used lead to distorted images when the gemwin is not square.
fixing this is quite easy, but will break all patch using frambuffer with a not square gem windows. so, i'm wondering if i should commit the fix.
I prefer when [gemframebuffer] doesn't distort the image when the gemwin is not a square. Maybe it is possible to use an option (by default 'distort 1') for old patches and turn to 'distort 0' to get a normal image (without distort when the gemwin is not a square). What do you think about this ?
yes, fixing this bug + adding a message to get compatibility with old patch is certainly a good solution. what do developers think?
cyrille
++
Jack
the fix is mainly to replace line 145 of gemframebuffer.cpp :
glFrustum(-1,1,-1,1,1,25);
with :
float xDivy = (float)GemMan::m_w / (float)GemMan::m_h;
glFrustum(GemMan::m_perspect[0] * xDivy, GemMan::m_perspect[1] * xDivy, // left, right GemMan::m_perspect[2], GemMan::m_perspect[3], // bottom, top GemMan::m_perspect[4], GemMan::m_perspect[5]); // front, back
but it need to add #include "Base/GemMan.h"
and to move static int m_w; static int m_h; from private to public in GemMan.h
should i commit this?
cyrille
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
That proposal makes sense to me!
The way it is now is certainly not expected behaviour.
.b.
cyrille henry wrote:
Jack a écrit :
Le 25 mai 08 à 14:23, cyrille henry a écrit :
hello, when using a framebuffer in a patch, the perspective of the main windows is change to (-1, 1) in X and Y. So it's no more possible to use custom perspective (sending the perspec message to gemwin is useless). moreover, the perspective used lead to distorted images when the gemwin is not square.
fixing this is quite easy, but will break all patch using frambuffer with a not square gem windows. so, i'm wondering if i should commit the fix.
I prefer when [gemframebuffer] doesn't distort the image when the gemwin is not a square. Maybe it is possible to use an option (by default 'distort 1') for old patches and turn to 'distort 0' to get a normal image (without distort when the gemwin is not a square). What do you think about this ?
yes, fixing this bug + adding a message to get compatibility with old patch is certainly a good solution. what do developers think?
cyrille
++
Jack
the fix is mainly to replace line 145 of gemframebuffer.cpp :
glFrustum(-1,1,-1,1,1,25);
with :
float xDivy = (float)GemMan::m_w / (float)GemMan::m_h;
glFrustum(GemMan::m_perspect[0] * xDivy, GemMan::m_perspect[1] * xDivy, // left, right GemMan::m_perspect[2], GemMan::m_perspect[3], // bottom, top GemMan::m_perspect[4], GemMan::m_perspect[5]); // front, back
but it need to add #include "Base/GemMan.h"
and to move static int m_w; static int m_h; from private to public in GemMan.h
should i commit this?
cyrille
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
hello, i realise that my code is not doing what i wanted.
currently, the perspective is set in the gemwin, and it is reset in the gemframebuffer. the code i put in my original mail reset the framebuffer perspective to be the same as the rendering windows. what we need is to have 2 different perspective : 1 for the gemwindow, and 1 for the framebuffer. the latter sould also be optionally changed by the user.
i must say that i can't find how do this. i tried to change GemMan.cpp, but did not find where does the pb comes from. any help is welcome.
cyrille
cyrille henry a écrit :
hello, when using a framebuffer in a patch, the perspective of the main windows is change to (-1, 1) in X and Y. So it's no more possible to use custom perspective (sending the perspec message to gemwin is useless). moreover, the perspective used lead to distorted images when the gemwin is not square.
fixing this is quite easy, but will break all patch using frambuffer with a not square gem windows. so, i'm wondering if i should commit the fix.
the fix is mainly to replace line 145 of gemframebuffer.cpp :
glFrustum(-1,1,-1,1,1,25);
with :
float xDivy = (float)GemMan::m_w / (float)GemMan::m_h;
glFrustum(GemMan::m_perspect[0] * xDivy, GemMan::m_perspect[1] * xDivy, // left, right GemMan::m_perspect[2], GemMan::m_perspect[3], // bottom, top GemMan::m_perspect[4], GemMan::m_perspect[5]); // front, back
but it need to add #include "Base/GemMan.h"
and to move static int m_w; static int m_h; from private to public in GemMan.h
should i commit this?
cyrille
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
hello,
i fink i find a good / simple way to solve the problem. with just a pushmatrix (for the perspective matrix and not the projection matrix) in the framebuffer::render, and a popmatrix in the post render.
i'll test this here, and if nothing bad happend, i'll commit it.
thanks cyrille
IOhannes m zmoelnig a écrit :
cyrille henry wrote:
and to move static int m_w; static int m_h; from private to public in GemMan.h
at least these should be accessed with GemMan::getRealDimen(&x,&y);
mfgas.dr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
ok. i commit a fix to this bug. there is no compatibility option for old patch, but i hope no one would need it. changes are minor : all Gem example patch works.
tell me if it's a problem.
cyrille
cyrille henry a écrit :
hello,
i fink i find a good / simple way to solve the problem. with just a pushmatrix (for the perspective matrix and not the projection matrix) in the framebuffer::render, and a popmatrix in the post render.
i'll test this here, and if nothing bad happend, i'll commit it.
thanks cyrille
IOhannes m zmoelnig a écrit :
cyrille henry wrote:
and to move static int m_w; static int m_h; from private to public in GemMan.h
at least these should be accessed with GemMan::getRealDimen(&x,&y);
mfgas.dr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-
B. Bogart -
cyrille henry -
IOhannes m zmoelnig -
Jack -
marius schebella