jit.gl.mesh not responding to "transform_reset 2" at patch loading time

James Harkins

Hi --

I have a student who is trying to use a jit.gl.mesh. One of the attributes given in the object box is `@transform_reset 2`. This attribute is required for her patch to draw correctly.

If she opens the patch, `transform_reset 2` seems not to be taking effect -- nothing is drawn after clicking the toggles to start rendering.

She can edit the jit.gl.mesh object (e.g. delete 2, retype 2) to re-create it, and then it works.

We have also tried `loadmess transform_reset 2`, and `loadbang --> delay 500 --> "transform_reset 2"(msg)` (here, I was thinking maybe the mesh object needs more time to initialize? stab in the dark), but so far, the only way she can get the patch to render as desired is by re-creating the mesh object.

In this screenshot, @transform_reset has been removed (the attempt shown here did *not* resolve the problem).

What are we missing?

hjh

Rob Ramirez

difficult to say without seeing the patch

James Harkins

> difficult to say without seeing the patch

Thanks, I'll get it from her.

hjh

James Harkins

OK, here is the patch file.

I guess it must be something apart from the @transform_reset...?

Thanks,
hjh

mhmh.maxpat

text/plain 50.38 KB

Rob Ramirez

the patch has a jit.gl.videoplane and a jit.gl.mesh both drawing to the exact same depth, both with depth_enable 1, so draw order is indeterminate. likely they want to set @depth_enable 0 on the videoplane, and control draw order with the @layer attribute (e.g. set the videoplane to @layer -1 so that it draws prior to objects with default layer order of 0). that should be enough to guarantee the mesh draws on top of the videoplane.

James Harkins

> the patch has a jit.gl.videoplane and a jit.gl.mesh both drawing to the exact same depth, both with depth_enable 1, so draw order is indeterminate.

That makes perfect sense... and then, recreating the jit.gl.mesh probably changes the draw order.

Thanks! I've already relayed this to the student.

hjh