Hi,
I've been playing around with GEM for the past couple of days and must say that I'm very impressed! Great work to all involved. System notes: windows 2000 SP2, PIII, DX 8.1, nVidia Geforce2Go.
I have, however, come across a couple of things that seem to be a little strange:
- Trying to use DV codec compressed AVIs causes PD to crash. Through the
wonders of open source, I've tracked this problem down to a NULL return from AVIStreamGetFrameOpen(m_streamVid,NULL) in pix_filmNT :: realOpen() from pix_filmNT.cpp
This suggests that the AVI/Video For Windows system can't find an appropriate decompressor on my system. However, the same clips play just fine with Media player or other apps on the system. I have no problems in GEM using cinepak or a couple of other codecs that I've tried.
Can anyone/everyone reproduce this behaviour, or is it specific to my system?
- I'm trying to do some algorithmic gem list generation.
I want to have smooth animation, so I need double buffering.
A simple example of the kind of algorithm that I'm using is the generation of an array of a particular object. This is easy and elegant to do algorithmically, but would require a rat's nest of patching to do statically.
However I've encountered a number of problems: a) can't turn off the automatic render cycle when double buffering is enabled
This I've worked around by setting the frame rate to 0.0001 and then banging the gemlist heads with a metro, and banging the gemwin to trigger the flip.
Unfortunately there are some other peculiarities: b) the view position moves from the default to 0 0 0 c) it is not possible to change the viewing position (As far as i can tell) using the view message to the gemwin at any stage of the render/flip cycle d) the pixel or texture format seems to get confused... i'm using pix_data to pull colours to give to my objects and i need to reverse the order of the triple in order to get the right colours to appear.
It seems that I'm not using GEM in the way it may have been intended, but I think it would be very useful (and I imagine not difficult) to have the system support this kind of thing. I suspect it's just a matter of rearranging the rendering code a little but I've not yet delved that far into the code.
Daniel
Ahah... I think I can answer my own question about the DV codec. It is a case of Type-1 versus Type-2 DV AVIs.
- Trying to use DV codec compressed AVIs causes PD to crash. Through the
wonders of open source, I've tracked this problem down to a NULL return from AVIStreamGetFrameOpen(m_streamVid,NULL) in pix_filmNT :: realOpen() from pix_filmNT.cpp
This suggests that the AVI/Video For Windows system can't find an appropriate decompressor on my system. However, the same clips play just fine with Media player or other apps on the system. I have no problems in GEM using cinepak or a couple of other codecs that I've tried.
Daniel Heckenberg wrote:
Hi,
I have, however, come across a couple of things that seem to be a little strange:
- Trying to use DV codec compressed AVIs causes PD to crash. Through the
wonders of open source, I've tracked this problem down to a NULL return from AVIStreamGetFrameOpen(m_streamVid,NULL) in pix_filmNT :: realOpen() from pix_filmNT.cpp
thanks for the bug-report, i will check and fix it. (btw: yes this is a very cute and rigth way to do it)
Unfortunately there are some other peculiarities: b) the view position moves from the default to 0 0 0
this i cannot reproduce, what does it mean ? when does it change ? from below i can see, that you are using the "view" message. the default viewing position is at "0 0 4" (or -4, i don't remember)
c) it is not possible to change the viewing position (As far as i can tell) using the view message to the gemwin at any stage of the render/flip cycle
i have looked at the code, and i see what you mean. i think, i will pull the behaviour of "bang" towards "render" rather than "swap-buffers". does this break anything ???
d) the pixel or texture format seems to get confused... i'm using pix_data to pull colours to give to my objects and i need to reverse the order of the triple in order to get the right colours to appear.
this might depend on your data. from your DV-bugs i guess, that you are working with movies. lot's of movies are stored in BGR-format. i decided to not change the format directly in the [pix_film]-objects because of performance issues. obviously the pix_data does not know about this and interpretes your images are RGB. you can either reverse the triples by hand (as you do it know) or use [pix_rgba] to convert it automatically. i guess you will need only few pixels of the image, so maybe the doing-by-hand is way faster (i do not know, whether your patch is consumptive or not)
It seems that I'm not using GEM in the way it may have been intended,
so who does ??
but I think it would be very useful (and I imagine not difficult) to have the system support this kind of thing. I suspect it's just a matter of rearranging the rendering code a little but I've not yet delved that far into the code.
sure. i will have a deep breath and think of it
do you need your changes very soon???
mfg.ads.dr IOhannes
Daniel
Thanks IOhannes,
On the question of "procedural" gem list generation in double buffer mode: I've recreated the patch using the [render_trigger] object to avoid the viewport movement and other problems, so there's no immediate time pressure from me. I think it would be nice for single buffer and double buffer modes to behave more consistently in the long term tho.
Unfortunately there are some other peculiarities: b) the view position moves from the default to 0 0 0
this i cannot reproduce, what does it mean ? when does it change ? from below i can see, that you are using the "view" message. the default viewing position is at "0 0 4" (or -4, i don't remember)
The viewport shifts when the (double buffered) viewport is banged... I've attached a sample patch to demonstrate.
c) it is not possible to change the viewing position (As far as
i can tell)
using the view message to the gemwin at any stage of the
render/flip cycle i have looked at the code, and i see what you mean. i think, i will pull the behaviour of "bang" towards "render" rather than "swap-buffers". does this break anything ???
hmm. not sure. i'll leave that one to you ;-)
d) the pixel or texture format seems to get confused... i'm
using pix_data
to pull colours to give to my objects and i need to reverse the
order of the
triple in order to get the right colours to appear.
this might depend on your data. from your DV-bugs i guess, that you are working with movies. lot's of movies are stored in BGR-format. i decided to not change the format directly in the [pix_film]-objects because of performance issues. obviously the pix_data does not know about this and interpretes your images are RGB. you can either reverse the triples by hand (as you do it know) or use [pix_rgba] to convert it automatically. i guess you will need only few pixels of the image, so maybe the doing-by-hand is way faster (i do not know, whether your patch is consumptive or not)
I did try to use a [pix_rgba] to convert the data before I used [pix_data] to sample the pixels and it seemed to make no difference. In fact, I've cooked up a little patch to demonstrate (either my lack of understanding, or some problem).
From what I can see, the [pix_rgba] doesn't have any effect on the pixel
values read by [pix_data]. The sample patch (which I'll send to IOhannes) has two [pix_data] objects: one before and one after the [pix_rgba]. They both return the triplet in the same order.
Thanks again, Daniel
-----> start patch "viewmove.pd" #N canvas 661 424 826 404 12; #X obj 29 190 gemwin 0.001; #X obj 261 93 gemhead; #X obj 203 180 gemhead; #X obj 197 222 translateXYZ 0 0 -4; #X msg 37 22 create; #X msg 48 54 destroy; #X obj 61 85 tgl 15 0 empty empty empty 20 8 0 8 -262144 -1 -1 0 1 ; #X msg 28 217 print; #X msg 138 15 frame 0.01; #X msg 96 158 frame 20; #X obj 186 62 t b b b; #X obj 267 125 sphere 1; #X obj 196 270 cube 1; #X text 231 14 click to "disable" auto refresh and start a manuual render.; #X connect 1 0 11 0; #X connect 2 0 3 0; #X connect 3 0 12 0; #X connect 4 0 0 0; #X connect 5 0 0 0; #X connect 6 0 0 0; #X connect 7 0 0 0; #X connect 8 0 0 0; #X connect 8 0 10 0; #X connect 9 0 0 0; #X connect 10 0 0 0; #X connect 10 1 2 0; #X connect 10 2 1 0;
Daniel Heckenberg wrote:
Thanks IOhannes,
Unfortunately there are some other peculiarities: b) the view position moves from the default to 0 0 0
this i cannot reproduce, what does it mean ? when does it change ?>
The viewport shifts when the (double buffered) viewport is banged... I've attached a sample patch to demonstrate.
uh sorry. my mail was misleading: i could reproduce the effect (obviously immediately after i wrote those lines)
i think, i will pull the behaviour of "bang" towards "render" rather than "swap-buffers".
this would be the solution to this problem: the call of the render-chain does all the viewpoint-transformations. since "bang" bypasses this call (in double buffered mode) the view-point is set to openGL's default (0,0,0) and ignores the settings in Gem.
does this break anything ???
hmm. not sure. i'll leave that one to you ;-)
well, this question was rather meant for all those people out there using Gem (esp. Mark)
d) the pixel or texture format seems to get confused... i'm
I did try to use a [pix_rgba] to convert the data before I used [pix_data] to sample the pixels and it seemed to make no difference. In fact, I've cooked up a little patch to demonstrate (either my lack of understanding, or some problem).
From what I can see, the [pix_rgba] doesn't have any effect on the pixel
values read by [pix_data]. The sample patch (which I'll send to IOhannes) has two [pix_data] objects: one before and one after the [pix_rgba]. They both return the triplet in the same order.
mine too, but in the right order. i am under linux right now and cannot boot into windows to check your problem. the provided AVI definitely is in BGR-mode, the linux-movies are colour-transformed automatically by the decoder into RGB.
mfg.dsa.dr IOhannes
Thanks again, Daniel
-
Daniel Heckenberg -
IOhannes zmoelnig