Hey all,
(In case your all wondering why I spout off so many bug reports and issues, I've been working on PD for over 20hrs a week for the last three months.)
This one is REALLY strange, I've only seen it on OSX since I can't get ftgl to play on gem/linux. It compiles fine, the configure is happy but then when I create a text3d object with the gemwin open I get:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 4840)] 0x401181f9 in free () from /lib/i686/libc.so.6 (gdb) where #0 0x401181f9 in free () from /lib/i686/libc.so.6 #1 0x40b600c1 in operator delete(void*) () from /usr/lib/libstdc++.so.5 #2 0x40b6011d in operator delete[](void*) () from /usr/lib/libstdc++.so.5 #3 0x402abab9 in TextBase::~TextBase() () from /home/bbogart/gem/gemcvs/src/Gnu/Gem.pd_linux #4 0x403279d8 in text3d::~text3d() () from /home/bbogart/gem/gemcvs/src/Gnu/Gem.pd_linux #5 0x40327a38 in text3d::obj_freeCallback(void*) () from /home/bbogart/gem/gemcvs/src/Gnu/Gem.pd_linux #6 0x08094c8e in pd_free (x=0x81211c8) at m_pd.c:35 #7 0x08233068 in ?? () #8 0x0823306c in ?? () #9 0x081127e0 in ?? () #10 0x081211c8 in ?? ()
But this is beside the point. Attached is an example patch.
Go through 1st to fourth and everything is fine. After "fourth" create the window again, the text gets replaced with a copy of the model! Click on the font message again to recreate the text and the model turns into the first letter of the text!!! I hope someone else can see this and I'm not losing my mind.
Thanks all, Ben
#N canvas 531 324 570 347 10; #X obj 21 114 gemhead 1; #X obj 20 217 text3d hello; #X obj 19 77 gemwin; #X msg 19 17 create , 1; #X msg 37 47 0 , destroy; #X msg 59 192 font ../fonts/arial.ttf; #X obj 22 164 rotateXYZ; #X floatatom 70 140 5 0 0 0 - - -; #X obj 368 74 rotateXYZ; #X floatatom 416 50 5 0 0 0 - - -; #X obj 371 209 model; #X obj 441 160 openpanel; #X msg 440 139 bang; #X msg 441 186 open $1; #X obj 368 25 gemhead 3; #X obj 369 111 scaleXYZ; #X floatatom 438 87 5 0 0 0 - - -; #X text 98 18 First; #X text 233 193 Second; #X text 476 141 Third; #X text 118 47 Fourth; #X text 25 263 After "fourth" create the window again , the text gets replaced with a copy of the model! Click on the font message again to recreate the text and the model turns into the first letter of hello!!! ; #X connect 0 0 6 0; #X connect 3 0 2 0; #X connect 4 0 2 0; #X connect 5 0 1 0; #X connect 6 0 1 0; #X connect 7 0 6 3; #X connect 8 0 15 0; #X connect 9 0 8 3; #X connect 11 0 13 0; #X connect 12 0 11 0; #X connect 13 0 10 0; #X connect 14 0 8 0; #X connect 15 0 10 0; #X connect 16 0 15 3; #X connect 16 0 15 2; #X connect 16 0 15 1;
hey ben,
On Mar 22, 2004, at 12:45 PM, B. Bogart wrote:
(In case your all wondering why I spout off so many bug reports and issues, I've been working on PD for over 20hrs a week for the last three months.)
...keep 'em coming!
This one is REALLY strange, I've only seen it on OSX since I can't get ftgl to play on gem/linux. It compiles fine, the configure is happy but then when I create a text3d object with the gemwin open I get:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 4840)] 0x401181f9 in free () from /lib/i686/libc.so.6 (gdb) where #0 0x401181f9 in free () from /lib/i686/libc.so.6 #1 0x40b600c1 in operator delete(void*) () from /usr/lib/libstdc++.so.5 #2 0x40b6011d in operator delete[](void*) () from /usr/lib/libstdc++.so.5 #3 0x402abab9 in TextBase::~TextBase() () from /home/bbogart/gem/gemcvs/src/Gnu/Gem.pd_linux
...uh, I thought you said this was on OSX, but it looks like you're running linux on an i686?
l8r, jamie
B. Bogart wrote:
Hey all,
(In case your all wondering why I spout off so many bug reports and issues, I've been working on PD for over 20hrs a week for the last three months.)
But this is beside the point. Attached is an example patch.
Go through 1st to fourth and everything is fine. After "fourth" create the window again, the text gets replaced with a copy of the model! Click on the font message again to recreate the text and the model turns into the first letter of the text!!! I hope someone else can see this and I'm not losing my mind.
all right, happens with me too. seems to be a problem with display-lists.
mfg.asd.r IOhannes
IOhannes m zmoelnig wrote:
B. Bogart wrote:
all right, happens with me too. seems to be a problem with display-lists.
indeed it was some issue with display-lists (although i haven't really found out why this happened): the model and the 1st glyph (e.g: character) have been assigned the same display-list. it also happened with concurring [text3d]-objects, resulting in exchanged glyphs.
while debugging, i found it very annoying that i had to re-load the font everytime i switched off/on rendering, so i added an auto-loader on startRendering(). et voila, this seems to have fixed the display-list sharing too.
i have committed the changes to the cvs.
mfg.asd.r IOhannes
Great!
I was manually sending a signal from the gem-window creation to the text3d object so that it would be initialized after the window is created! I will be very happy to remove this.
Ben
IOhannes m zmoelnig wrote:
IOhannes m zmoelnig wrote:
B. Bogart wrote:
all right, happens with me too. seems to be a problem with display-lists.
indeed it was some issue with display-lists (although i haven't really found out why this happened): the model and the 1st glyph (e.g: character) have been assigned the same display-list. it also happened with concurring [text3d]-objects, resulting in exchanged glyphs.
while debugging, i found it very annoying that i had to re-load the font everytime i switched off/on rendering, so i added an auto-loader on startRendering(). et voila, this seems to have fixed the display-list sharing too.
i have committed the changes to the cvs.
mfg.asd.r IOhannes
On Mar 24, 2004, at 6:03 AM, IOhannes m zmoelnig wrote:
indeed it was some issue with display-lists (although i haven't really found out why this happened): the model and the 1st glyph (e.g: character) have been assigned the same display-list. it also happened with concurring [text3d]-objects, resulting in exchanged glyphs.
while debugging, i found it very annoying that i had to re-load the font everytime i switched off/on rendering, so i added an auto-loader on startRendering(). et voila, this seems to have fixed the display-list sharing too.
i have committed the changes to the cvs.
after a flurry of updates tonight, text seems to have stopped working altogether for me on OSX. can anyone else confirm this?
cgc
I was playing around with some of Cyrille's pmpd patches and noticed that he commented on several of them needing lots of CPU to run. I quickly figured out that it was the sphere object that ate most of the CPU, and I had already made a note to fix this after Johannes rewrote the object. The big problem is that sphere calculates each and every vertex each and every pass even though most of the time the geometry is static. The quick fix I just committed to CVS only calculates the geometry when a parameter changes (slices, drawing style, etc). The result is at least a 3X improvement in performance, and most of the pmpd stuff runs ok now on my Powerbook.
Now, this is all fine and well, but the object is still in immediate mode and thus quite inefficient. I thought about creating a display list inside the sphere object, but that has two drawbacks. FIrst, there is considerable overhead compiling a list and uploading it. Second, it would waste a lot of VRAM for something like Cyrille's patches. The idea I have is to try and move as much stuff out of immediate (or idiot) mode as possible and try and create a system that really scales well for GEM. I think we could have a type of client and server using display lists that would function like this:
[GemCreateList name geo arg1 arg2]
[GemCallList name]
The first object would create a display list with a given name, and build a list with the desired geo inside the list. The second object would issue a glCallList() with that given name wherever the user needs that geo. This should be very fast and extremely efficient for large scale patches. It might even help GEM gain a bit of dynamism that it currently lacks.
cgc
On Mar 29, 2004, at 1:42 AM, chris clepper wrote:
I was playing around with some of Cyrille's pmpd patches and noticed that he commented on several of them needing lots of CPU to run. I quickly figured out that it was the sphere object that ate most of the CPU, and I had already made a note to fix this after Johannes rewrote the object. The big problem is that sphere calculates each and every vertex each and every pass even though most of the time the geometry is static. The quick fix I just committed to CVS only calculates the geometry when a parameter changes (slices, drawing style, etc). The result is at least a 3X improvement in performance, and most of the pmpd stuff runs ok now on my Powerbook.
...good job chris! I was just playing with the pmpd examples and noticing the slowness, but I didn't look close...then I tried your fix, and it runs much better!
jamie