Well, here are my latest findings. I just spent 2 days trying to hack the dvgrab app (available from Kino, talks to devices via userland) and somehow merge it with Gem. I am pleased to report that the hackathon was successful but the results were surprisingly the same as before (talk about the DOH! moment). However, I did discover that actually both before and now the video feed *was* working. It is however as if the entire texture in Gem is covering either really small area (i.e. one pixel) or had some kind of mangled data that remained for the most part black. How do I know this? When I flickered with my hand in front of the camera and/or made drastic changes in lighting/exposure, there was slight change in color of the overall texture.
So what gives? It obviously is not the way Gem tries to open devices as this other userland model had no effect on the final results, but there is simply something that prevents the texture to be projected properly. Granted, I reused as much of the old code as possible but the core of the engine was going through dvgrab which in and of itself works flawlessly.
So, given that Dapper/Edgy/FC6 all suffer from this (all of whom are new distros), is it:
1) udev (unlikely since devices open ok) 2) updated fw driver which somehow messes something up (unlikely since Kino works) 3) way how Gem talks to fw devices (unlikely since it apparently works) 4) something with imageStruct or some other GL-texture related thing (unlikely since 0.90 release behaves the same) 5) something else but what?
The only obvious commonality is that all distros are new. Other than that, I have no clue whatsoever...
At this point I am also wondering if Linux Gem and more specifically dv part of it is actively maintained and if so by whom? Furthermore, I would love to hear from others who are using Gem/DV in their work in order to figure out whether this affects any other recent distro/setup.
If anyone is interested in testing this other hacked version I'll gladly post it but please note that it is built with scotch tape and chewing gum.
Naturally, I am hoping for some help in this area since I am at a loss what may be wrong...
Best wishes,
Ico
send 'mode 0' to pix_texture?
On 12/30/06, Ivica Ico Bukvic ico.bukvic@gmail.com wrote:
Well, here are my latest findings. I just spent 2 days trying to hack the dvgrab app (available from Kino, talks to devices via userland) and somehow merge it with Gem. I am pleased to report that the hackathon was successful but the results were surprisingly the same as before (talk about the DOH! moment). However, I did discover that actually both before and now the video feed *was* working. It is however as if the entire texture in Gem is covering either really small area (i.e. one pixel) or had some kind of mangled data that remained for the most part black. How do I know this? When I flickered with my hand in front of the camera and/or made drastic changes in lighting/exposure, there was slight change in color of the overall texture.
One word: WOW!
This, against any common sense actually worked. On Ubuntu Hoary running on the 100% same hardware and the *same* pd software revision this was not needed. Now suddenly this is required, go figure. More so, given that e-mails on various lists asking about this go back to mid-2005, none of which were apparently solved...
So, in short for Studio and others to try out:
1) Start the examples/Gem/04.Video/00.SimpleVideo.pd 2) Change device message to "/dev/dv1394/0" or if you have dv1394-0 device, then to "/dev/dv1394-0" 3) Change "driver 0" to "driver 1" 4) add a message to pix_texture "mode 0" 5) depending upon your type of camera you may also need to use "mode NTSC"
Click on mode (if needed), then driver, then device, then on the newly added mode, and then finally create gemwin and turn on rendering. You should now have a working dv feed!
Kudos to Chris for solving the riddle! I am still a bit confused why this is necessary (mode deals with "rectangle texturing" but since I was using the same version of pd/gem before and it worked without it, this is still IMHO very curious).
Best wishes,
Ico
On 12/31/06, chris clepper cgclepper@gmail.com wrote:
send 'mode 0' to pix_texture?
On 12/30/06, Ivica Ico Bukvic ico.bukvic@gmail.com wrote:
Well, here are my latest findings. I just spent 2 days trying to hack the dvgrab app (available from Kino, talks to devices via userland) and somehow merge it with Gem. I am pleased to report that the hackathon was successful but the results were surprisingly the same as before (talk about the DOH! moment). However, I did discover that actually both before and now the video feed *was* working. It is however as if the entire texture in Gem is covering either really small area (i.e. one pixel) or had some kind of mangled data that remained for the most part black. How do I know this? When I flickered with my hand in front of the camera and/or made drastic changes in lighting/exposure, there was slight change in color of the overall texture.
On 12/31/06, Ivica Ico Bukvic ico.bukvic@gmail.com wrote:
I am still a bit confused why this is necessary (mode deals with "rectangle texturing" but since I was using the same version of pd/gem before and it worked without it, this is still IMHO very curious).
Did any graphics drivers change? There seems to be a problem with some configurations where rectangle textures are listed as supported but the texture coordinates for them are not dealt with properly. Coordinates for rectangle textures are absolute pixel dimensions while 2D textures are normalized from 0..1, which is why the rectangle coordinates give the one big pixel effect.
On 12/31/06, chris clepper cgclepper@gmail.com wrote:
On 12/31/06, Ivica Ico Bukvic ico.bukvic@gmail.com wrote:
I am still a bit confused why this is necessary (mode deals with
"rectangle texturing" but since I was using the same version of pd/gem before and it worked without it, this is still IMHO very curious).
Did any graphics drivers change? There seems to be a problem with some configurations where rectangle textures are listed as supported but the texture coordinates for them are not dealt with properly. Coordinates for rectangle textures are absolute pixel dimensions while 2D textures are normalized from 0..1, which is why the rectangle coordinates give the one big pixel effect.
Well, in my case the distro was upgraded from 5.04 to 6.10 which is a pretty significant leap forward (kernel 2.6.5-ish to 2.6.18), so I am quite confident that drivers have been updated all across the board. Given that this is a dv issue, my guess would be the ieee1394 driver, especially since the project website reports a major overhaul of the driver for the 2.6.12 kernel series and up.
BTW, are there any sideffects of running pix_texture this way or is this pretty much a transparent fix for this setup?
Again, many thanks for your help in this matter!
P.S. Perhaps it would be nice to overhaul the documentation to reflect this important issue (it would've saved me 2 1/2 days of hacking :-) and if googling is any indicator of the current state I am sure others may benefit from it too. I'll gladly supply a new patch if someone could upload it to Gem CVS since I do not have dev access to it.
Best wishes,
Ico
On 12/31/06, Ivica Ico Bukvic ico.bukvic@gmail.com wrote:
BTW, are there any sideffects of running pix_texture this way or is this pretty much a transparent fix for this setup?
Rectangle textures improve performance quite a bit on the Mac, but don't seem to do much on Windows or Linux.
P.S. Perhaps it would be nice to overhaul the documentation to reflect
this important issue (it would've saved me 2 1/2 days of hacking :-) and if googling is any indicator of the current state I am sure others may benefit from it too. I'll gladly supply a new patch if someone could upload it to Gem CVS since I do not have dev access to it.
I'll have a look at the pix_texture code in the near future and see if we can improve the default settings for texturing on each platform.
I'll have a look at the pix_texture code in the near future and see if we can improve the default settings for texturing on each platform.
If "mode" thingy is going to go away by altering pix_texture then obviously changes in docs will not be necessary. Otherwise, I am quite convinced that updating documentation might be a good idea.
Once again, many thanks for your help and a Happy New Year to all!
Best wishes,
Ico
-
chris clepper -
Ivica Ico Bukvic