-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hey all,
I'm trying to compile the vertex branch on OSX. I've simply added the src/vertex files to the project and compile when without errors. Upon loading Gem I get the following unresolved symbols:
__ZN9GemVertex11setModifiedEv __ZN9GemVertexC2Ev __ZN9GemVertexD2Ev _glBindBufferARB _glBufferDataARB _glDeleteBuffersARB _glGenBuffersARB
I'm using OSX on 10.3.2 (Because I tried getting Gem to work on a french 1GHz powerbook and I could not get pix_video to work, only sending a green texture. It works fine in other applications though.
Also I can't get pix_film to load a animation compressed QT. It just send a green texture. QT opens it fine directly. These last two issues are based on the gem binary on taproot.dyndns.org/~cgc
Thanks all
Ben
On Oct 14, 2004, at 1:10 PM, B. Bogart wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hey all,
I'm trying to compile the vertex branch on OSX. I've simply added the src/vertex files to the project and compile when without errors. Upon loading Gem I get the following unresolved symbols:
__ZN9GemVertex11setModifiedEv __ZN9GemVertexC2Ev __ZN9GemVertexD2Ev _glBindBufferARB _glBufferDataARB _glDeleteBuffersARB _glGenBuffersARB
I'm using OSX on 10.3.2 (Because I tried getting Gem to work on a french 1GHz powerbook and I could not get pix_video to work, only sending a green texture. It works fine in other applications though.
ok, originally the vertex_array stuff was written with VAO in mind: that is slow, so at the moment the vertex array stuff is hacked to use VBO's (way faster), which aren't officially in OpenGL.framework (someone screwed up at Apple)...however, there is a glVBOext.h that I think is in cvs that provides the necessary defines to get the VBO stuff working...
...unfortunately, I forget what the minimum OSX is that exposed the VBO stuff in the driver: aha, quick review of my mail says 10.3.4+...so I highly suggest an update! I'm currently using 10.3.5 with no problem, but really am looking forward to 10.3.6 because it may solve some nagging OpenGL problems...
...lastly, there is a Base/GemVertex.cpp that you also need...better to just recheck out the cvs with the vertex_array tag...
Also I can't get pix_film to load a animation compressed QT. It just send a green texture. QT opens it fine directly. These last two issues are based on the gem binary on taproot.dyndns.org/~cgc
...don't know what's going on here...? Personally haven't tried any animation compression in 10 years :-) However it is quicktime supported, so shouldn't be a big deal, unless it's just a huge data rate...another thing to consider is whether or not the hardware supports yuv texturing, and that the movie is opened in YUV mode...
l8r, jamie
On Oct 14, 2004, at 12:10 PM, B. Bogart wrote:
I'm using OSX on 10.3.2 (Because I tried getting Gem to work on a french 1GHz powerbook and I could not get pix_video to work, only sending a green texture. It works fine in other applications though.
Also I can't get pix_film to load a animation compressed QT. It just send a green texture. QT opens it fine directly. These last two issues are based on the gem binary on taproot.dyndns.org/~cgc
YUV is the default for the OSX version of GEM due to it being absurdly faster than RGB for the same sources.
Send a 'colorspace rgb' message to both objects and reset the video using 'reset' and reload the video. RGB is the colorspace of Animation and None QT codecs and are definitely in the minority compared to the rest of the available codecs. Your video capture source must have been a webcam which are about the only RGB devices I've come across.
cgc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ok this makes much sense.
Prehaps the pix_film object could print out a message when trying to load a rgb codec in yuv space? Any plans for automatic colourspace switching?
Thanks for the info. B.
chris clepper wrote: | On Oct 14, 2004, at 12:10 PM, B. Bogart wrote: | |> |> I'm using OSX on 10.3.2 (Because I tried getting Gem to work on a |> french 1GHz |> powerbook and I could not get pix_video to work, only sending a green |> texture. |> It works fine in other applications though. |> |> Also I can't get pix_film to load a animation compressed QT. It just |> send a |> green texture. QT opens it fine directly. These last two issues are |> based on the |> gem binary on taproot.dyndns.org/~cgc | | | YUV is the default for the OSX version of GEM due to it being absurdly | faster than RGB for the same sources. | | Send a 'colorspace rgb' message to both objects and reset the video | using 'reset' and reload the video. RGB is the colorspace of Animation | and None QT codecs and are definitely in the minority compared to the | rest of the available codecs. Your video capture source must have been | a webcam which are about the only RGB devices I've come across. | | cgc | | | _______________________________________________ | GEM-dev mailing list | GEM-dev@iem.at | http://iem.at/cgi-bin/mailman/listinfo/gem-dev |
B. Bogart wrote:
Prehaps the pix_film object could print out a message when trying to load a rgb codec in yuv space?
well, this is a bit complicated. there is no such thing as a "yuv space" into which an "rgb"-object (e.g. movie) is loaded.
the idea is that a pix-source supplies the image in a "native" way. you should be able to override this "native" way with a "colourspace" (or "colorspace" if you prefer...) message.
all modifying objects should have methods for all colorspaces (if this is possible); if such the needed method has not been implemented (yet), an error-message is sent to the console.
Any plans for automatic colourspace switching?
this has been discussed once; chris has argumented (and by now i agree) that automatic switching would be a sincere performance penalty: the problem is, that the system will choose to convert for you and you will not know why it get's sooo slow; if you have to do the conversion "manually" then you might optimize it easier
(but we could do automatic conversion + output to the console that conversion is done! this would tell the user what is going on (so slow) and it still would work)
pix-sinks (like [pix_texture]) should handle all colour-spaces. since windos and linux don't know yuv-textures (at least i wasn't able to convince them to display correctly) they are automatically converted on these platforms. on OSX, yuv-textures should theoretically be possible, however there are bugs in (older releases of) the drivers (for nvidia). i don't know any failsave method to detect such bugs (except for looking at the green image, of course) and solve them on the application side (btw, i don't think that solving driver's bugs is a task for an application)
mfg.as.dr IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ok, I'm convinced too.
I was asked to make a list of "supported" codecs in Gem for OSX and I'll think I'll just consider RGB codecs and not-suggested.
The reason behind outputting the colourspace would have been so that a patch could read YUV or RGB images and the patch could worry about switching to RGB mode when needed. Performance is important so I'll more or less forget about RGB for general purposes!
Back to debugging popup...
Ben
IOhannes m zmoelnig wrote: | B. Bogart wrote: | |> Prehaps the pix_film object could print out a message when trying to |> load a rgb codec in yuv space? | | well, this is a bit complicated. | there is no such thing as a "yuv space" into which an "rgb"-object (e.g. | movie) is loaded. | | the idea is that a pix-source supplies the image in a "native" way. | you should be able to override this "native" way with a "colourspace" | (or "colorspace" if you prefer...) message. | | all modifying objects should have methods for all colorspaces (if this | is possible); if such the needed method has not been implemented (yet), | an error-message is sent to the console. | |> Any plans for automatic colourspace switching? | | this has been discussed once; chris has argumented (and by now i agree) | that automatic switching would be a sincere performance penalty: the | problem is, that the system will choose to convert for you and you will | not know why it get's sooo slow; if you have to do the conversion | "manually" then you might optimize it easier | | (but we could do automatic conversion + output to the console that | conversion is done! this would tell the user what is going on (so slow) | and it still would work) | | pix-sinks (like [pix_texture]) should handle all colour-spaces. | since windos and linux don't know yuv-textures (at least i wasn't able | to convince them to display correctly) they are automatically converted | on these platforms. | on OSX, yuv-textures should theoretically be possible, however there are | bugs in (older releases of) the drivers (for nvidia). | i don't know any failsave method to detect such bugs (except for looking | at the green image, of course) and solve them on the application side | (btw, i don't think that solving driver's bugs is a task for an | application) | | mfg.as.dr | IOhannes |
B. Bogart wrote:
The reason behind outputting the colourspace would have been so that a patch could read YUV or RGB images and the patch could worry about switching
well, this would work anyhow: [pix_info] should give you information about the colourspace of the image and you could do something according to it.
mfg.as.dr IOhannes
-
B. Bogart -
chris clepper -
IOhannes m zmoelnig -
James Tittle II