changing the jit.gl.render rotate origin
Hi there,
Sorry if this has been covered elsewhere - I searched through the archives for a few hours and couldn't find it.
I'm using max/msp 4.5.5 and Jitter 1.5 for windows
When I use rotatexyz (some values) on a jit.gl object (like gridshape), then the object rotates relative to its position. When I move the object, it rotates on the spot where I put it.
I like this.
When I do the same thing with jit.gl.render, I get a different behaviour. I can use position messages, and these seem to combine with rotate messages to change the direction of movement. However, the rotate or rotatexyz message seem to rotate around the original point.
I don't like this so much.
When you move the camera and lookat locations, you still get the same behaviour. I did the whole thing with poltocar, but it made my head bleed.
Can I change this so that rotate and rotatexyz will rotate around the origin set by the position message?
Hope this is possible somehow.
Love
Burt Lancaster.
P.S. please let me know if you need an example patch
On Jan 3, 2007, at 7:52 PM, burt lancaster wrote:
> When I do the same thing with jit.gl.render, I get a different
> behaviour. I can use position messages, and these seem to combine
> with rotate messages to change the direction of movement. However,
> the rotate or rotatexyz message seem to rotate around the original
> point.
>
> I don't like this so much.
As always, if you send a clear example patch with steps to reproduce
and desired behavior, etc. there's greater chance that people on the
list will investigate the report.
As for rotate vs rotatexyz, there's no difference in sequencing, so
it should present the same behavior. It sounds like you want to
change the default order of translation vs. rotation. For greater
flexibility, I would suggest you use jit.gl.sketch's drawobject
command, possibly in conjunction with the gltranslate and glrtotate
commands.
Search the archives for some examples like this one:
-Joshua
On this note, may I make a feature request, if possible -
I would love a separate jit.gl.translate and jit.gl.rotate objects,
similar to GEM for Pd's translate and rotate, than you can inline one
after the other and chain to objects gl objects the same way you link
to a jit.gl.handle, to create nice orbiting rotation matrices.
I know it is low on the list (plenty to do!!), but it would be a
lovely quality of life thing. Thanks for considering.
Im sure one can do this now - pelado introduced a nice set of patches
showing some of this, but externals with clean implementation would
be nice.
Hm, perhaps ill try to make a few abstractions that do this in the
mean time. Thanks anyway - sorry for thinking out loud.
On Jan 4, 2007, at 4:57 PM, Joshua Kit Clayton wrote:
>
> On Jan 3, 2007, at 7:52 PM, burt lancaster wrote:
>
>> When I do the same thing with jit.gl.render, I get a different
>> behaviour. I can use position messages, and these seem to combine
>> with rotate messages to change the direction of movement. However,
>> the rotate or rotatexyz message seem to rotate around the original
>> point.
>>
>> I don't like this so much.
>
> As always, if you send a clear example patch with steps to
> reproduce and desired behavior, etc. there's greater chance that
> people on the list will investigate the report.
>
> As for rotate vs rotatexyz, there's no difference in sequencing, so
> it should present the same behavior. It sounds like you want to
> change the default order of translation vs. rotation. For greater
> flexibility, I would suggest you use jit.gl.sketch's drawobject
> command, possibly in conjunction with the gltranslate and glrtotate
> commands.
>
> Search the archives for some examples like this one:
>
> https://cycling74.com/forums/index.php?t=msg&goto=61938#msg_61938
>
> -Joshua
>
>
v a d e //
www.vade.info
abstrakt.vade.info
On Jan 4, 2007, at 2:08 PM, vade wrote:
> On this note, may I make a feature request, if possible -
>
> I would love a separate jit.gl.translate and jit.gl.rotate objects,
> similar to GEM for Pd's translate and rotate, than you can inline
> one after the other and chain to objects gl objects the same way
> you link to a jit.gl.handle, to create nice orbiting rotation
> matrices.
>
> Hm, perhaps ill try to make a few abstractions that do this in the
> mean time. Thanks anyway - sorry for thinking out loud.
Ja, just have a global sketch object (optionally in immediate mode),
and send the message to the sketch object in a bang chain, and you
have the GEM model AFAICT.
What I would probably consider to this end for Jitter in the future
would be a little different--e.g. rather make it so you can just
connect objects to a "sub-context". Something like the following
patch which wouldn't work.
-Joshua
I don't want to start a long ass email war, but I want to note a few things:
1) the GEM and Jitter methods of wrapping the OpenGL API are *very* different
2) you can do it with sketch and potentially use JS to make your life
easier (which you probably already know, so yes this is probably the
last item on the list)
thanks for understanding,
wes
Joshua - that is exactly what I was thinking, or perhaps rather than
channel through a sketch object, you could specify the glscale/rotate/
translate matrix directly by sending in a 4x4 float32 matrix to a
jit.gl.whatever OB3D and having something like 'prepend glmatrix' or
somesuch. This way you could do matrix ops on the incoming glmatrices
in pure jitter land. Dont mean to be a backseat programmer, feel
free to tell me to stfu :)
Wesley - No worries, Im well aware that Jitter and Gem approach
things differently - there is a reason I use one and not the other. I
think it would be much easier and more max like to have objects,
rather than using a central sketch / js , but yes - I hear ya loud
and clear - its obviously doable now... as per pelados and other
examples - I had no intention of starting a flame war :P
Thanks.
On Jan 4, 2007, at 5:34 PM, Joshua Kit Clayton wrote:
>
> On Jan 4, 2007, at 2:08 PM, vade wrote:
>
>> On this note, may I make a feature request, if possible -
>>
>> I would love a separate jit.gl.translate and jit.gl.rotate
>> objects, similar to GEM for Pd's translate and rotate, than you
>> can inline one after the other and chain to objects gl objects the
>> same way you link to a jit.gl.handle, to create nice orbiting
>> rotation matrices.
>>
>> Hm, perhaps ill try to make a few abstractions that do this in the
>> mean time. Thanks anyway - sorry for thinking out loud.
>
> Ja, just have a global sketch object (optionally in immediate
> mode), and send the message to the sketch object in a bang chain,
> and you have the GEM model AFAICT.
>
> What I would probably consider to this end for Jitter in the future
> would be a little different--e.g. rather make it so you can just
> connect objects to a "sub-context". Something like the following
> patch which wouldn't work.
>
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P newex 359 163 139 196617 jit.gl.sketch @rotate 0. 2. 0.;
> #P newex 359 108 78 196617 jit.gl.gridshape;
> #P newex 88 108 78 196617 jit.gl.gridshape;
> #P newex 88 163 154 196617 jit.gl.sketch @rotate 90 1. 0. 0.;
> #P newex 186 236 152 196617 jit.gl.sketch @translate 1. 0. 0.;
> #P newex 186 287 65 196617 jit.gl.render;
> #P connect 2 0 1 0;
> #P connect 3 0 2 0;
> #P connect 4 0 5 0;
> #P connect 5 0 1 0;
> #P connect 1 0 0 0;
> #P window clipboard copycount 6;
>
>
> -Joshua
>
>
>
v a d e //
www.vade.info
abstrakt.vade.info
No problemo,
We've been talking about some new paradigms for max patches recently
that I don't always have in the foreground of my thoughts, one of
which as JKC mentioned is some kind of context-aware patchers and in
his example it would be an opengl context aware patcher. Anyways,
something to think about for the future for sure.
wes
Hey everyone,
Thanks for helping me out. I really appreciate it. I hadn't realised just how flexible jit.gl.sketch was :-)
..I guess I was hankering after the old PD/Gem days a little..
Happy New Year