Bug report? User error? Cosmic joke?

Open jit.gl.videoplane. Load a movie. Toggle rendering. Mess with
tex_offset and tex_scale params. No visible change.

Am I missing something obvious?

Mac OS X 10.4.8, Max 4.6.2 Jitter 1.6.2

Is this a 1.6.3 ‘fix’ ?

Thanks.

v a d e //

http://www.vade.info
abstrakt.vade.info

On Dec 8, 2006, at 1:12 PM, vade wrote:

> Hello
>
> Bug report? User error? Cosmic joke?
>
> Open jit.gl.videoplane. Load a movie. Toggle rendering. Mess with
> tex_offset and tex_scale params. No visible change.
>
> Am I missing something obvious?
>
> Mac OS X 10.4.8, Max 4.6.2 Jitter 1.6.2
>
> Is this a 1.6.3 ‘fix’ ?
>
> Thanks.
>
> v a d e //
>
> http://www.vade.info
> abstrakt.vade.info
>
>
>

v a d e //

http://www.vade.info
abstrakt.vade.info

As a workaround, you can either send the dim message, or the
rebuild_geometry message to force a rebuild (which isn’t detected for
the texture offset cases). I think this is in the archives somewhere.
Sorry for the inconvenience.

-Joshua

I recall this in the archives, but I couldnt find it in the search
and could not remember the work around. Weak google-fu :)

If you could also refresh my memory = is jit.gl.videoplane
substantially faster than other OB3D for displaying video on a plane?
If I used sketch, or a nurbs with a low dim count, is there still a
performance differential?

Thanks. My memory says ‘yes, gl videoplane is optimized’, but Im
uncertain if anything has changed in 1.2.x -> 1.6.x with regard to this.

Thanks again

On Dec 8, 2006, at 3:27 PM, Joshua Kit Clayton wrote:

>
>
> Thanks. Known issue. I’ll try to sneak this in for the actual 1.6.3
> release (new beta coming later today or tomorrow with other recent
> fixes).
>
> As a workaround, you can either send the dim message, or the
> rebuild_geometry message to force a rebuild (which isn’t detected
> for the texture offset cases). I think this is in the archives
> somewhere. Sorry for the inconvenience.
>
> -Joshua

v a d e //

http://www.vade.info
abstrakt.vade.info

@expr snorm[0] snorm[1] “0.” norm[0] norm[1]

Cheers,
Andrew B.

Thanks again -

On Dec 8, 2006, at 4:41 PM, Andrew Benson wrote:

> You might get slightly better performance (with more setup) using
> jit.gl.mesh instead. A simple textured quad could be generated
> with the following jit.expr formula (5-plane matrix input):
>
> @expr snorm[0] snorm[1] “0.” norm[0] norm[1]
>
> Cheers,
> Andrew B.

v a d e //

http://www.vade.info
abstrakt.vade.info

> Hi Joshua. Thank you for the feedback. Is this an issue with only
> the jit.gl.videoplane, or with all OB3D geometry?

Most things will be fine, but if you encounter issues like this, you
can often send the rebuild_geometry message to several objects.

> If you could also refresh my memory = is jit.gl.videoplane
> substantially faster than other OB3D for displaying video on a
> plane? If I used sketch, or a nurbs with a low dim count, is there
> still a performance differential?

jit.gl.videoplane is just an instance of jit.gl.texture and some
geometry. There are w few utilities for texture coords, but
fundamentally there’s nothing special happening in that object vs.
using jit.gl.gridshape. You might want to decrease
jit.gl.videoplane’s dim size for better performance when drawing lots
of quads, and/or using @displaylist 1 for objects which support it
also improve performance when you don’t need to be dynamically
changing the geometry.

Just a note for jit.gl.mesh, like AB suggested, don’t send the
geometry more than it’s actually needed for optimum behavior–e.g.
just send once if static geometry.

-Joshua

jit.gl.videoplane still does nothing in response to the tex_scale and tex_offset messages, using 1.62b2. is it still on the to-do list?

j

> hi josh et al:
> jit.gl.videoplane still does nothing in response to the tex_scale
> and tex_offset messages, using 1.62b2. is it still on the to-do list?

Probably won’t make it in 1.6.3, as we’re focused on Max 5 dev tasks,
and only solving major bugs for 1.6.3. As mentioned previously on the
list, just send the rebuild_geometry or dim message to force
jit.gl.videoplane recalculate the gemoetry. No such a terrible
workaround in the meantime.

-Joshua