@capture mesh distance clipping


    Jun 28 2006 | 12:50 pm
    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

    • Jun 28 2006 | 1:07 pm
      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*
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • Jun 28 2006 | 1:09 pm
      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
      ;
      jitter glreadback fbo
      ;
      jitter glreadback rtt
      ;
      jitter glreadback ctt
      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.
      wes
      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
      >
    • Jun 28 2006 | 1:11 pm
      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*
      >
      This sounds like a good guess to me...that the videoplane is clipping the mesh.
      wes
    • Jun 28 2006 | 3:39 pm
      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.
      -Charlie
      -----BEGIN PATCH----
      max v2;
    • Jun 28 2006 | 4:02 pm
      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.
      Cheers,
      Andrew B.
    • Jun 28 2006 | 4:05 pm
      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..
      v a d e //
      www.vade.info
      abstrakt.vade.info
      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
      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.
      -Charlie
    • Jul 04 2006 | 9:06 am
      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.
      -Charlie
      max v2;