cablecharlz

right now in a jit.window i have rendered a sphere with a texture which rotates at the top of the screen.

what i want to do is combine this window with a jit.qt.movie through jit.op so that my sphere would overlay my background which would be a movie.

the thing i cannot figure out right now is how to convert my jit.gl.render into a movie because right now i can only play it in the window....nowhere else.

i looked through the help file and tried to name a jit.pwindow and then pass a drawto message to the jit.gl.render, but for some reason my 3d scene does not render in the jit.pwindow and only in the jit.window.

i suspect that if i can convert the jit.gl.render scene into jit.pwindow i can then pass that into jit.op along with my background.

making-jit-gl-render-a-movie-so-i-can-combine-it-with-a-background

I didn't check out your patch but I had the exact same question/problem myself. It turns out that there is a patch located in examples/jitter-examples/render (in the max application folder) that is called jit.gl.render over movie. There patch does the trick but I am just now tearing it apart to figure out why it works. On first glance it seems to go the other way around that we were thinking about, ie. using a draw_pixels command to place the video onto the render instead of converting the render to video or attempting to composite it into a new matrix. I have to leave for a movie premier I am doing in Prenzlauer Berg, Berlin, but when I return this evening I will post any new findings I have to help you out as well. Take care and I hope this leads you in the right direction as it did me.

ps. I have yet to test the functionality of this patch with a jit.gl.model object, but my fingers are crossed that it will work the same. As of now, the patch is using a jit.gl.gridshape object but I can't see this making a difference, as both still use the jit.gl.handle and jit.gl.render objects.

Here's what I would do for a start. If you want to combine 3D with

graphics, stay in OpenGL. You can canpture stuff to a texture and

slab it together in any way you wish. See archives for how to do this

kind of stuff there are alot of fairly length threads on this issue.

Here's what I would do for a start.  If you want to combine 3D with
graphics, stay in OpenGL.  You can canpture stuff to a texture and
slab it together in any way you wish.  See archives for how to do this
kind of stuff there are alot of fairly length threads on this issue.

This is a good idea, but if I am not mistaken Cablecharlz wants to do what I want, which is not allowed with textures. For example, if the 'background' video isn't in openGL itself then it won't move, so you are free to reposition the camera and 3d object(s)/model(s) without changing the video position. The draw_pixels method is actually seeming to work well for me but I will post my final results when I plug in a jit.gl.model object to the whole thing.

Oh, and because it might help, how do you turn a patch into text like you are doing? As well, how do you turn this back into a patch? Thanks...

Also, forgot to mention that adding a texture object is going to take up more ram (which is important to me because I am building patches for live performance and running on low ram gear). As well, a jit.gl.videoplane (or other similar solution) still requires a jit.qt.movie object anyway, so this draw_pixels method eliminates the need for a secondary object, ie. all you need is the qt.movie object and then a message that routes the matrix, prepends draw_pixels, and sends this directly to the render. Pretty sneaky if you ask me... but definitely let me know if you think there is a reason why this isn't less ram heavy, I am very interested in every angle involved. Thanks again...

Yes but with textures you get all kinds of features like interpolation

and compression which wil save you _VRAM_ (not RAM). Did you try

moving the camera around? That's basically what the handle was doing.

The background image doesn't actually move because I was using

@transform_reset 2. What GPU (and how much VRAM) do you have?

For making patches from this stuff, use your normal copy and paste

> Also, forgot to mention that adding a texture object is going to take up more ram (which is important to me because I am building patches for live performance and running on low ram gear). As well, a jit.gl.videoplane (or other similar solution) still requires a jit.qt.movie object anyway, so this draw_pixels method eliminates the need for a secondary object, ie. all you need is the qt.movie object and then a message that routes the matrix, prepends draw_pixels, and sends this directly to the render. Pretty sneaky if you ask me... but definitely let me know if you think there is a reason why this isn't less ram heavy, I am very interested in every angle involved. Thanks again...

Yes but with textures you get all kinds of features like interpolation
and compression which wil save you _VRAM_ (not RAM).  Did you try
moving the camera around?  That's basically what the handle was doing.
 The background image doesn't actually move because I was using
@transform_reset 2.  What GPU (and how much VRAM) do you have?

For making patches from this stuff, use your normal copy and paste
routines.  Max will handle the rest.

On 7/25/07, dilkROM  wrote:
>
> Also, forgot to mention that adding a texture object is going to take up more ram (which is important to me because I am building patches for live performance and running on low ram gear). As well, a jit.gl.videoplane (or other similar solution) still requires a jit.qt.movie object anyway, so this draw_pixels method eliminates the need for a secondary object, ie. all you need is the qt.movie object and then a message that routes the matrix, prepends draw_pixels, and sends this directly to the render. Pretty sneaky if you ask me... but definitely let me know if you think there is a reason why this isn't less ram heavy, I am very interested in every angle involved. Thanks again...
>
> -dilkROM
>


Actually I didn't look at the patch yet but that stuff is good to know. Excuse my lack of knowledge here, but vram is virtual ram yes? And why is this important to save on over regular ram? As for my equipment, PowerBook G4 (slightly unreliable yet sturdy, as it was smashed by a guitar before being given to me, only part that is broken for sure is the disc drive, but sometimes I think it slows down do to the damage...) 1.5 ghz and 1.25 gb ram. How do I checck vram on my machine, do you know? Probably under the entire specs... About the copy and pasting, this was what I thought, but that is cool it works so easy. To give you an idea of the patch I am building, it runs jitter video effects objects (nearly twenty of them) using xfade to combine up to 5 channels (but all coming from the same jit.qt.movie object just pushed through each effect separately before being mixed with xfade). As well I have much automation controls (counters and such) and am now including a few gl objects (gridshape, model, etc.). I know how handle works but never knew there was a setting that kept the background from changing position. This is helpful, but overall why would it be better to save the vram instead of the ram? Thanks for the helpful info, as soon as I have my patch up and running (next few hours most likely, unless I crash out and finish it tomorrow) I will post it here for you to check out.

Actually I didn't look at the patch yet but that stuff is good to know. Excuse my lack of knowledge here, but vram is virtual ram yes? And why is this important to save on over regular ram?  As for my equipment, PowerBook G4 (slightly unreliable yet sturdy, as it was smashed by a guitar before being given to me, only part that is broken for sure is the disc drive, but sometimes I think it slows down do to the damage...) 1.5 ghz and 1.25 gb ram. How do I checck vram on my machine, do you know? Probably under the entire specs... About the copy and pasting, this was what I thought, but that is cool it works so easy. To give you an idea of the patch I am building, it runs jitter video effects objects (nearly twenty of them) using xfade to combine up to 5 channels (but all coming from the same jit.qt.movie object just pushed through each effect separately before being mixed with xfade). As well I have much automation controls (counters and such) and am now including a few gl objects (gridshape, model, etc.). I know how handle works but never knew there was a setting that kept the background from changing position. This is helpful, but overall why would it be better to save the vram instead of the ram? Thanks for the helpful info, as soon as I have my patch up and running (next few hours most likely, unless I crash out and finish it tomorrow) I will post it here for you to check out.

By VRAM I was refering to Video RAM on your graphics card. If you're

doing alot of video effects and have a decent GPU like a Radeon 9700

or better, than you'll benefit quite a bit in terms of how many

effects you can run by using jit.gl.slab. And honestly I wouldn't

worry about VRAM unless you start building delay lines on the GPU,

Next time it might be wise to look at the patch before responding.

By VRAM I was refering to Video RAM on your graphics card.  If you're
doing alot of video effects and have a decent GPU like a Radeon 9700
or better, than you'll benefit quite a bit in terms of how many
effects you can run by using jit.gl.slab.  And honestly I wouldn't
worry about VRAM unless you start building delay lines on the GPU,
then it might become an issue.

Okay, thanks for the tip (about viewing the patch, I will do this from now on). Checked my system profiler, using a GeForce FX Go5200 with 64 mb vram. What are delay lines? I used an early version of this patch I am building before and had not too much slow down but was a victim of a crash near the end of the 'performance'. I believe this was due to my uneducated use of multiple metros and counters, which now I counteract by running most tasks from one qmetro and using Lnth to simulate (q)metros at different timings. Once I get a break in my work I will look at this patch you sent and see how it runs on my machine, sometimes I just get too caught up in the world of Max, I am sure you know how this can be. Thanks for the patience and guidance, I really appreciate it.

I have no real experience with the 5200. You should run some test on

it with slab processing to see how much it can handle.

> Okay, thanks for the tip (about viewing the patch, I will do this from now on). Checked my system profiler, using a GeForce FX Go5200 with 64 mb vram. What are delay lines? I used an early version of this patch I am building before and had not too much slow down but was a victim of a crash near the end of the 'performance'. I believe this was due to my uneducated use of multiple metros and counters, which now I counteract by running most tasks from one qmetro and using Lnth to simulate (q)metros at different timings. Once I get a break in my work I will look at this patch you sent and see how it runs on my machine, sometimes I just get too caught up in the world of Max, I am sure you know how this can be. Thanks for the patience and guidance, I really appreciate it.

I have no real experience with the 5200.   You should run some test on
it with slab processing to see how much it can handle.

On 7/25/07, dilkROM  wrote:
>
> Okay, thanks for the tip (about viewing the patch, I will do this from now on). Checked my system profiler, using a GeForce FX Go5200 with 64 mb vram. What are delay lines? I used an early version of this patch I am building before and had not too much slow down but was a victim of a crash near the end of the 'performance'. I believe this was due to my uneducated use of multiple metros and counters, which now I counteract by running most tasks from one qmetro and using Lnth to simulate (q)metros at different timings. Once I get a break in my work I will look at this patch you sent and see how it runs on my machine, sometimes I just get too caught up in the world of Max, I am sure you know how this can be. Thanks for the patience and guidance, I really appreciate it.
>
> -dilkROM
>


Also, read the Max and Jitter tutorials and the Fundamentals pdf. A 

lot of your questions and concerns are addressed therein. Armed with 

their knowledge you'll be able to make your patch much more efficient.

Also, read the Max and Jitter tutorials and the Fundamentals pdf.  A  
lot of your questions and concerns are addressed therein.  Armed with  
their knowledge you'll be able to make your patch much more efficient.


making jit.gl.render a movie so i can combine it with a background?