charlie@flimshaw.net

I'm using the @capture command to render a gl.mesh object and a gl.sketch object to separate textures, which I'm then combining with a shader on a video slab. This works great, and gives me all the control I want, but it seems that when an object's position goes beyond -1 to 1 in the z-axis (perhaps all axes, i'm not sure) it disappears. Is there a way to define near_clip and far_clip when capturing straight to texture? Any other ideas about why this is happening?

If this has been answered before, forgive me. The only computer I have access to is a pretty hack old PC in a hotel lobby in serbia, so crawling through newsgroups is like watching dead grass not grow.

I'm using the @capture command to render a gl.mesh object and a gl.sketch object to separate textures, which I'm then combining with a shader on a video slab.  This works great, and gives me all the control I want, but it seems that when an object's position goes beyond -1 to 1 in the z-axis (perhaps all axes, i'm not sure) it disappears.  Is there a way to define near_clip and far_clip when capturing straight to texture?  Any other ideas about why this is happening?

If this has been answered before, forgive me.  The only computer I have access to is a pretty hack old PC in a hotel lobby in serbia, so crawling through newsgroups is like watching dead grass not grow.

capture-mesh-distance-clipping

I think this might be a depth_enable issue. make sure that you render 

with automatic 0 for strict and that the videoplane or geometry you 

are rendering to has depth_enable set to 0, otherwise the objects you 

render are 'infront' of the captured texture and might pull through 

I think this might be a depth_enable issue. make sure that you render  
with automatic 0 for strict and that the videoplane or geometry you  
are rendering to has depth_enable set to 0, otherwise the objects you  
render are 'infront' of the captured texture and might pull through  
and not show up properly?

I've never seen that problem before. I'm guessing that it's not going

to be easy for you to provide an example patch? The near_clip and

far_clip are taken from jit.gl.render's settings, so that shouldn't be

an issue. The idea of capture is that it renders to texture exactly

what you would get if you didn't capture. You might be able to try

using a different backend for capture. There are 3 choices

fbo works well in the new beta of jitter, but is a bit slower than

rtt. However rtt has some issues that will be addressed in a future

version. If you're on windows, I have no idea about these things

except that ctt is the current default. To use the above, send a

message to jitter via a message ";jitter glreadback fbo" etc. I was

unable to reproduce your problems on OSX with the latest beta release.

> I'm using the @capture command to render a gl.mesh object and a gl.sketch object to separate textures, which I'm then combining with a shader on a video slab. This works great, and gives me all the control I want, but it seems that when an object's position goes beyond -1 to 1 in the z-axis (perhaps all axes, i'm not sure) it disappears. Is there a way to define near_clip and far_clip when capturing straight to texture? Any other ideas about why this is happening?

> If this has been answered before, forgive me. The only computer I have access to is a pretty hack old PC in a hotel lobby in serbia, so crawling through newsgroups is like watching dead grass not grow.

I've never seen that problem before.  I'm guessing that it's not going
to be easy for you to provide an example patch?  The near_clip and
far_clip are taken from jit.gl.render's settings, so that shouldn't be
an issue.  The idea of capture is that it renders to texture exactly
what you would get if you didn't capture.  You might be able to try
using a different backend for capture.  There are 3 choices

fbo works well in the new beta of jitter, but is a bit slower than
rtt.  However rtt has some issues that will be addressed in a future
version.  If you're on windows, I have no idea about these things
except that ctt is the current default.  To use the above, send a
message to jitter via a message ";jitter glreadback fbo" etc.  I was
unable to reproduce your problems on OSX with the latest beta release.
 Hope this helps.

On 6/28/06, Charlie  wrote:
>
> Alright everybody:
>
> I'm using the @capture command to render a gl.mesh object and a gl.sketch object to separate textures, which I'm then combining with a shader on a video slab.  This works great, and gives me all the control I want, but it seems that when an object's position goes beyond -1 to 1 in the z-axis (perhaps all axes, i'm not sure) it disappears.  Is there a way to define near_clip and far_clip when capturing straight to texture?  Any other ideas about why this is happening?
>
> If this has been answered before, forgive me.  The only computer I have access to is a pretty hack old PC in a hotel lobby in serbia, so crawling through newsgroups is like watching dead grass not grow.
>
> Thanks much,
> Charlie
>


> I think this might be a depth_enable issue. make sure that you render with

> automatic 0 for strict and that the videoplane or geometry you are rendering

> to has depth_enable set to 0, otherwise the objects you render are 'infront'

> of the captured texture and might pull through and not show up properly?

This sounds like a good guess to me...that the videoplane is clipping the mesh.

On 6/28/06, vade  wrote:
>
> I think this might be a depth_enable issue. make sure that you render with
> automatic 0 for strict and that the videoplane or geometry you are rendering
> to has depth_enable set to 0, otherwise the objects you render are 'infront'
> of the captured texture and might pull through and not show up properly?
>
> *shot in the dark*
>

Thanks for your quick replies, guys. I managed to hijack internet with my powerbook, so i can attach the example i was using. The behavior I'm seeing happens in the Scene Process example in Jitter Recipes Book 2, recipe 21. If you drop a [pak position 0. 0. 0.] onto the mesh, or just hold ALT down and use the jit.handle that's already on it, moving it along the z-axis makes it disappears pretty quick. I've tried the depth_enable things, but didn't have any luck. Also, I tried those different glreadback messages, but to no avail.

I'm going to download the beta now, but this is for a production that's happening in about a week and a half. How stable is the beta?

Thanks again, let me know if you come up with anything, or if the same problem happens for you in this patch. I confirmed it on a G5 desktop as well.

Thanks for your quick replies, guys.  I managed to hijack internet with my powerbook, so i can attach the example i was using.  The behavior I'm seeing happens in the Scene Process example in Jitter Recipes Book 2, recipe 21.  If you drop a [pak position 0. 0. 0.] onto the mesh, or just hold ALT down and use the jit.handle that's already on it, moving it along the z-axis makes it disappears pretty quick.  I've tried the depth_enable things, but didn't have any luck.  Also, I tried those different glreadback messages, but to no avail.

I'm going to download the beta now, but this is for a production that's happening in about a week and a half.  How stable is the beta?

Thanks again, let me know if you come up with anything, or if the same problem happens for you in this patch.  I confirmed it on a G5 desktop as well.

The mesh object is being clipped by the jit.gl.videoplane that is used 

to display the geometry. To prevent this, you will need to turn off 

@automatic on jit.gl.mesh and jit.gl.videoplane and impose a strict 

1. bang geometry matrix above jit.gl.mesh

FWIW, the beta does solve several issues with capturing to textures, and 

appears to be very stable. If you are serious about OpenGL stuff, I 

highly recommend checking out the jitter 1.6 public beta. It includes 

several very handy new features like @layer and @transform_reset. Also, 

the Max/jitter beta will install as a completely self-contained folder, 

so you can keep the older version around without trouble.

Hi Charlie,
The mesh object is being clipped by the jit.gl.videoplane that is used 
to display the geometry.  To prevent this, you will need to turn off 
@automatic on jit.gl.mesh and jit.gl.videoplane and impose a strict 
rendering order.

The order will be something like
1. bang geometry matrix above jit.gl.mesh
2. bang jit.gl.mesh
3. bang destination texture
4. bang jit.gl.videoplane

FWIW, the beta does solve several issues with capturing to textures, and 
appears to be very stable.  If you are serious about OpenGL stuff, I 
highly recommend checking out the jitter 1.6 public beta.  It includes 
several very handy new features like @layer and @transform_reset. Also, 
the Max/jitter beta will install as a completely self-contained folder, 
so you can keep the older version around without trouble.

the beta is actually remarkably stable, save for the jit.gl.imageunit 

external. Im using it, but just make sure to NOT resize your 

Im not seeing that behavior on the patch you posted BTW, moving the z 

axis for the mesh will render just fine regardless - Max OS X 10.4.6 

jitter 1.6. Maybe its a 1.6 fix? I didnt try with 4.5.7 and Jitter 

On Jun 28, 2006, at 11:39 AM, Charlie wrote:

Thanks for your quick replies, guys. I managed to hijack internet 

with my powerbook, so i can attach the example i was using. The 

behavior I'm seeing happens in the Scene Process example in Jitter 

Recipes Book 2, recipe 21. If you drop a [pak position 0. 0. 0.] 

onto the mesh, or just hold ALT down and use the jit.handle that's 

already on it, moving it along the z-axis makes it disappears pretty 

quick. I've tried the depth_enable things, but didn't have any 

luck. Also, I tried those different glreadback messages, but to no 

I'm going to download the beta now, but this is for a production 

that's happening in about a week and a half. How stable is the beta?

Thanks again, let me know if you come up with anything, or if the 

same problem happens for you in this patch. I confirmed it on a G5 

the beta is actually remarkably stable, save for the jit.gl.imageunit  
external. Im using it, but just make sure to NOT resize your  
destination window.

Im not seeing that behavior on the patch you posted BTW, moving the z  
axis for the mesh will render just fine regardless  - Max OS X 10.4.6  
jitter 1.6. Maybe its a 1.6 fix? I didnt try with 4.5.7 and Jitter  
1.5.3..

Thanks for your quick replies, guys.  I managed to hijack internet  
with my powerbook, so i can attach the example i was using.  The  
behavior I'm seeing happens in the Scene Process example in Jitter  
Recipes Book 2, recipe 21.  If you drop a [pak position 0. 0. 0.]  
onto the mesh, or just hold ALT down and use the jit.handle that's  
already on it, moving it along the z-axis makes it disappears pretty  
quick.  I've tried the depth_enable things, but didn't have any  
luck.  Also, I tried those different glreadback messages, but to no  
avail.

I'm going to download the beta now, but this is for a production  
that's happening in about a week and a half.  How stable is the beta?

Thanks again, let me know if you come up with anything, or if the  
same problem happens for you in this patch.  I confirmed it on a G5  
desktop as well.

Sorry for vanishing for a bit, but I tried your suggestions and I'm still having the same issue. I've attached a much simpler patch that illustrates my problem. It may be fixed in the upcoming version of Jitter, but I have to use SoftVNS and a couple other objects that have been giving me trouble in the beta version.

In this patch, move the sphere along the z-axis, and you'll see that it is only rendering objects that are between -1. and 1. Also, there doesn't appear to actually be any z-axis movement, it simply clips itself off. I'm almost sure that the rendering order is correct.

I know that this is probably a problem that's going to be (or already is) fixed in the coming release, but I'm sure that it's not working in the current stable version of max. Could you open this in the max 4.5.6 / jit 1.5 and confirm this behavior (i've tried it on a couple machines). Any ideas?

Also vade: I experienced the same behavior in the patch you posted a couple days ago regarding capturing to texture. Add a [pak position] to the jit.gl.model and you can't move it along the z-axis it just remains stationary until it is clipped all together.

Thanks for your patience guys, but I'm positive this isn't working in jit 1.5, and I've had trouble with 1.6. If you get a chance, try the patch below.

Sorry for vanishing for a bit, but I tried your suggestions and I'm still having the same issue.  I've attached a much simpler patch that illustrates my problem.  It may be fixed in the upcoming version of Jitter, but I have to use SoftVNS and a couple other objects that have been giving me trouble in the beta version.

In this patch, move the sphere along the z-axis, and you'll see that it is only rendering objects that are between -1. and 1.  Also, there doesn't appear to actually be any z-axis movement, it simply clips itself off.  I'm almost sure that the rendering order is correct.

I know that this is probably a problem that's going to be (or already is) fixed in the coming release, but I'm sure that it's not working in the current stable version of max.  Could you open this in the max 4.5.6 / jit 1.5 and confirm this behavior (i've tried it on a couple machines).  Any ideas?

Also vade: I experienced the same behavior in the patch you posted a couple days ago regarding capturing to texture.  Add a [pak position] to the jit.gl.model and you can't move it along the z-axis it just remains stationary until it is clipped all together.

Thanks for your patience guys, but I'm positive this isn't working in jit 1.5, and I've had trouble with 1.6.  If you get a chance, try the patch below.

@capture mesh distance clipping