Forums > Jitter

another camera perspective question


ico
June 23, 2007 | 4:59 pm

According to one OpenGL paper I read the following is apparently possible in
OpenGL but am not sure whether jitter offers this kind of low-level access,
hence my question:

Is it possible to adjust camera angle in such a way that the actual z-plane
is skewed in respect to the camera origin, yet that it appears flat on the
view. The best way to visualize this is to look at the attached jpg
rendition.

Please note that I am aware that this could be compensated by doing some
runtime position/rotation adjustments to objects and/or by using an
appropriate lens shader. I am however wondering whether this is possible via
the aforesaid low-level OpenGL modification of camera.

Ivica Ico Bukvic, D.M.A.
Composition, Music Technology, CCTAD, CHCI
Virginia Tech
Dept. of Music – 0240
Blacksburg, VA 24061
(540) 231-1137
(540) 231-5034 (fax)
ico@vt.edu
http://www.music.vt.edu/people/faculty/bukvic/

http://ico.bukvic.net


June 24, 2007 | 8:44 pm

Hi ico,

Unfortunately in the forum your attachment is not visible. Could you repost the attachment via the forum?

Mattijs

Quote: ico wrote on Sat, 23 June 2007 18:59
—————————————————-
> According to one OpenGL paper I read the following is apparently possible in
> OpenGL but am not sure whether jitter offers this kind of low-level access,
> hence my question:
>
> Is it possible to adjust camera angle in such a way that the actual z-plane
> is skewed in respect to the camera origin, yet that it appears flat on the
> view. The best way to visualize this is to look at the attached jpg
> rendition.
>
> Please note that I am aware that this could be compensated by doing some
> runtime position/rotation adjustments to objects and/or by using an
> appropriate lens shader. I am however wondering whether this is possible via
> the aforesaid low-level OpenGL modification of camera.
>
> Ivica Ico Bukvic, D.M.A.
> Composition, Music Technology, CCTAD, CHCI
> Virginia Tech
> Dept. of Music – 0240
> Blacksburg, VA 24061
> (540) 231-1137
> (540) 231-5034 (fax)
> ico@vt.edu
> http://www.music.vt.edu/people/faculty/bukvic/
> http://ico.bukvic.net
>
>
>
>
>
—————————————————-


June 24, 2007 | 8:51 pm

You want an asymmetric frustum. This is possible through
jit.gl.sketch and calling glfrustum with appropriate parameters.

wes

On 6/24/07, Mattijs Kneppers wrote:
>
> Hi ico,
>
> Unfortunately in the forum your attachment is not visible. Could you repost the attachment via the forum?
>
> Mattijs
>
> Quote: ico wrote on Sat, 23 June 2007 18:59
> —————————————————-
> > According to one OpenGL paper I read the following is apparently possible in
> > OpenGL but am not sure whether jitter offers this kind of low-level access,
> > hence my question:
> >
> > Is it possible to adjust camera angle in such a way that the actual z-plane
> > is skewed in respect to the camera origin, yet that it appears flat on the
> > view. The best way to visualize this is to look at the attached jpg
> > rendition.
> >
> > Please note that I am aware that this could be compensated by doing some
> > runtime position/rotation adjustments to objects and/or by using an
> > appropriate lens shader. I am however wondering whether this is possible via
> > the aforesaid low-level OpenGL modification of camera.
> >
> > Ivica Ico Bukvic, D.M.A.
> > Composition, Music Technology, CCTAD, CHCI
> > Virginia Tech
> > Dept. of Music – 0240
> > Blacksburg, VA 24061
> > (540) 231-1137
> > (540) 231-5034 (fax)
> > ico@vt.edu
> > http://www.music.vt.edu/people/faculty/bukvic/
> > http://ico.bukvic.net
> >
> >
> >
> >
> >
> —————————————————-
>
>
> –
> SmadSteck – http://www.smadsteck.nl
> Hard- and software for interactive audiovisual sampling
>



ico
June 24, 2007 | 10:50 pm

> You want an asymmetric frustum. This is possible through
> jit.gl.sketch and calling glfrustum with appropriate parameters.

Many thanks for the clarification. However, this should only affect drawing
associated with jit.gl.sketch, no? If so, how can one make this global so
that it affects all that is being captured by a particular GL camera?

The other question is what are default values in glfrustum inside jitter. I
messed with values but am getting rather bizarre results. An example would
be most appreciated, too.

Many thanks!

Best wishes,

Ico


June 24, 2007 | 10:57 pm

There are no defualt values for Jitter but there are values for
OpenGL. It’s a very very lowlevel call and you have to really
understand what you’re doing to get proper results. It’s not really
something you can just muck around with and expect interesting things
from. I’m not really sure what the best way to use it to control an
entire patch would be at this point.

wes

On 6/24/07, Ivica Ico Bukvic wrote:
> > You want an asymmetric frustum. This is possible through
> > jit.gl.sketch and calling glfrustum with appropriate parameters.
>
> Many thanks for the clarification. However, this should only affect drawing
> associated with jit.gl.sketch, no? If so, how can one make this global so
> that it affects all that is being captured by a particular GL camera?
>
> The other question is what are default values in glfrustum inside jitter. I
> messed with values but am getting rather bizarre results. An example would
> be most appreciated, too.
>
> Many thanks!
>
> Best wishes,
>
> Ico
>
>
>



ico
June 25, 2007 | 12:43 am

> There are no defualt values for Jitter but there are values for
> OpenGL. It’s a very very lowlevel call and you have to really
> understand what you’re doing to get proper results. It’s not really
> something you can just muck around with and expect interesting things
> from. I’m not really sure what the best way to use it to control an
> entire patch would be at this point.

I would be surprised to find out that jitter does not use default OpenGL
flustrum values, yet basic expected setting does not yield favorable results
(glfrustum -1.33 1.33 -1 1 0.1 100 for a camera at 0 0 2 with a 4:3 screen
and with z near/far adjusted to default setting inside jit.gl.sketch where
objects disappear at 1.9 and -98).

The other problem with glfrustum is that one has to click on a message twice
before it has a more-or-less expected effect. If jit.gl.sketch is reset and
then glfrustum is clicked on once, image is inverted and there is a bunch of
other problems. Yet, when it is clicked twice, results are closer to what is
expected, but still off. Clicking on the message three or more times makes
difficult if not impossible to locate object in the viewport.

To portray some of the oddities, for instance entering glfrustum -1 1 -1 1 3
10 gets you closest to the default frustum of a sphere 0.5 object in the
jit.gl.sketch help file but that is a far cry from what it ought to be. One
would expect 4:3 scene frustum to be -1.33 1.33 -1 1 but any off values
skews the object suggesting that frustum is object rather than
scene-specific.

So, based on a wasted afternoon my guess is the following:

1) glfrustum implementation may be buggy–namely, requires double entry of
data
2) glfrustum in its current form affects object but not the scene, which
would explain some of the oddities with obtained results as well as removal
of the object from its center (when you try to rotate object with
jit.gl.handle it appears outside the rotational center).

If these conjectures are true, then this type glfrustum is useless for this
particular purpose.

Best wishes,

Ico


June 25, 2007 | 1:31 am

Here’s a question for you that may be the root of your problems.
Notice in the glFrustum spec how it says a call to glFrustum generates
a matrix which is multiplied by the current projection matrix. If
you’re not doing the following:

glmatrixmode projection,
glpushmatrix,
glloadidentity,
glfurstum …,
glmatrixmode modelview,
draw stuff,
glmatrixmode projection,
glpopmatrix,
glmatrixmode modelview

then you might have problems.

wes

On 6/24/07, Ivica Ico Bukvic wrote:
> > There are no defualt values for Jitter but there are values for
> > OpenGL. It’s a very very lowlevel call and you have to really
> > understand what you’re doing to get proper results. It’s not really
> > something you can just muck around with and expect interesting things
> > from. I’m not really sure what the best way to use it to control an
> > entire patch would be at this point.
>
> I would be surprised to find out that jitter does not use default OpenGL
> flustrum values, yet basic expected setting does not yield favorable results
> (glfrustum -1.33 1.33 -1 1 0.1 100 for a camera at 0 0 2 with a 4:3 screen
> and with z near/far adjusted to default setting inside jit.gl.sketch where
> objects disappear at 1.9 and -98).
>
> The other problem with glfrustum is that one has to click on a message twice
> before it has a more-or-less expected effect. If jit.gl.sketch is reset and
> then glfrustum is clicked on once, image is inverted and there is a bunch of
> other problems. Yet, when it is clicked twice, results are closer to what is
> expected, but still off. Clicking on the message three or more times makes
> difficult if not impossible to locate object in the viewport.
>
> To portray some of the oddities, for instance entering glfrustum -1 1 -1 1 3
> 10 gets you closest to the default frustum of a sphere 0.5 object in the
> jit.gl.sketch help file but that is a far cry from what it ought to be. One
> would expect 4:3 scene frustum to be -1.33 1.33 -1 1 but any off values
> skews the object suggesting that frustum is object rather than
> scene-specific.
>
> So, based on a wasted afternoon my guess is the following:
>
> 1) glfrustum implementation may be buggy–namely, requires double entry of
> data
> 2) glfrustum in its current form affects object but not the scene, which
> would explain some of the oddities with obtained results as well as removal
> of the object from its center (when you try to rotate object with
> jit.gl.handle it appears outside the rotational center).
>
> If these conjectures are true, then this type glfrustum is useless for this
> particular purpose.
>
> Best wishes,
>
> Ico
>
>


June 25, 2007 | 3:34 pm

>1) glfrustum implementation may be buggy–namely, requires double entry of data
>2) glfrustum in its current form affects object but not the scene, which would explain some of the oddities with obtained results as well as removal of the object from its center (when you try to rotate object with jit.gl.handle it appears outside the rotational center).

1. I’d bet that the problems you’re having aren’t due to bugs, they’re because of some quirk of whatever method you’re using. But unless you post an example, no one can really give you an definitive answer.

2. The way you’re stating the question would suggest you’re a bit confused about how the whole jit.gl system works. glfrustum is only available through jit.gl.sketch, so you’ll want to use one instance of jit.gl.sketch to control your camera. If there are other jit.gl objects (including additional jit.gl.sketch’s) that you want to include in the scene, turn off their automatic attribute and use the first jit.gl.sketch’s drawobject method with them. Then they’ll all be viewed from the same frustum-enabled camera.

The frustum stuff isn’t actually all that complicated. Here’s a working example (patch & javascript)

max v2;
#N vpatcher 828 202 1473 512;
#P origin -23 0;
#P window setfont "Sans Serif" 9.;
#P flonum 491 167 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname flonum[11];
#P flonum 457 167 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname flonum[12];
#P flonum 423 167 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname flonum[13];
#P flonum 320 98 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname flonum[5];
#P flonum 286 98 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname flonum[6];
#P flonum 252 98 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname flonum[7];
#P flonum 218 98 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname flonum[8];
#P flonum 184 98 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname flonum[9];
#P flonum 150 98 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname flonum[10];
#P newex 116 119 216 196617 pak frustum -1.33 1.33 -1. 1. 5. 120.;
#P newex 150 76 183 196617 unpack -1.33 1.33 -1 1 1.5 120;
#P newex 51 45 45 196617 loadbang;
#P newex 219 143 287 196617 unpack 0 0 3 0 0 0 0 1 0;
#P flonum 389 167 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname flonum[18];
#P flonum 355 167 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname flonum[4];
#P flonum 321 167 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname flonum[3];
#P flonum 287 167 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname flonum[2];
#P flonum 253 167 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname flonum[1];
#P flonum 219 167 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname flonum;
#P newex 185 188 321 196617 pak lookat 0. 0. 3. 0. 0. 0. 0. 1. 0.;
#P toggle 44 128 26 0;
#P newex 44 161 57 196617 qmetro 20;
#P newex 116 245 70 196617 js frustum.js;
#P connect 2 0 1 0;
#P connect 3 0 0 0;
#P connect 1 0 0 0;
#P connect 13 0 0 0;
#P connect 11 0 12 0;
#P connect 12 0 14 0;
#P connect 14 0 13 1;
#P connect 12 1 15 0;
#P connect 15 0 13 2;
#P connect 12 2 16 0;
#P connect 16 0 13 3;
#P connect 11 0 10 0;
#P connect 10 0 4 0;
#P connect 4 0 3 1;
#P connect 12 3 17 0;
#P connect 17 0 13 4;
#P connect 10 1 5 0;
#P connect 5 0 3 2;
#P connect 12 4 18 0;
#P connect 18 0 13 5;
#P connect 10 2 6 0;
#P connect 6 0 3 3;
#P connect 12 5 19 0;
#P connect 19 0 13 6;
#P connect 10 3 7 0;
#P connect 7 0 3 4;
#P connect 10 4 8 0;
#P connect 8 0 3 5;
#P connect 10 5 9 0;
#P connect 9 0 3 6;
#P connect 10 6 20 0;
#P connect 20 0 3 7;
#P connect 10 7 21 0;
#P connect 21 0 3 8;
#P connect 10 8 22 0;
#P connect 22 0 3 9;
#P pop;

//begin frustum.js
var renderContext = "myContext"
var look = [0,0,3,0,0,0,0,1,0];
var frust = [-1.33,1.33,-1,1,1.5,120];

var mySketch = new JitterObject("jit.gl.sketch",renderContext); // CREATE JITTER OBJECTS
var myText = new JitterObject("jit.gl.text3d",renderContext);
var myHandle = new JitterObject("jit.gl.handle",renderContext);
var myRender = new JitterObject("jit.gl.render",renderContext);
var myWindow = new JitterObject("jit.window",renderContext);

mySketch.lighting_enable = 1;
mySketch.smooth_shading = 1;
myWindow.depthbuffer = 1;
myRender.erase_color = [0,0,0,1];

function bang() {

mySketch.reset();
mySketch.glclear();

mySketch.glmatrixmode("projection"); // PROJECTION MATRIX
mySketch.glloadidentity();
mySketch.glfrustum(frust);

mySketch.glmatrixmode("modelview"); // MODELVIEW MATRIX
mySketch.glloadidentity();
mySketch.glulookat(look);

mySketch.gltranslate(myHandle.position); // HANDLE
mySketch.glrotate(myHandle.rotate);

mySketch.glpushmatrix(); // GROUND PLANE
mySketch.gltranslate(0,-0.45,0);
mySketch.glrotate(90,0,0);
mySketch.glcolor(1,1,0,1);
mySketch.plane(2);
mySketch.glpopmatrix();

mySketch.glpushmatrix(); // CONE
mySketch.gltranslate(-1.125,0,0);
mySketch.glrotate(90,0,0);
mySketch.glcolor(1,0,0,1);
mySketch.cylinder(0.45,0,0.45);
mySketch.glpopmatrix();

mySketch.glpushmatrix(); // CUBE
mySketch.glcolor(0,0.25,1,1);
mySketch.cube(0.425);
mySketch.glpopmatrix();

mySketch.glpushmatrix(); // SPHERE
mySketch.gltranslate(1.125,0,0);
mySketch.glcolor(0,1,0,1);
mySketch.sphere(0.45);
mySketch.glpopmatrix();

myRender.erase();
myRender.drawswap();
}

function lookat(a,b,c,d,e,f) {
look = [a,b,c,d,e,f,0,1,0];
}

function frustum(a,b,c,d,e,f) {
frust = [a,b,c,d,e,f];
}
//end frustum.js



ico
June 25, 2007 | 9:07 pm

That’s it! Thank you very much for the clarification. My error was to assume
that glfrustum was simply an option passed to the jit.gl.sketch object (as
in message "glfrustum a b c d e f"), but what was missing in my case is all
the low-level code in between. Interesting thing was that it produced any
results whatsoever, some of which I must admit were quite interesting :-).

One more quick question. You mentioned to use @automatic 0 option on other
objects that need rendering. I am having hard time to project them into the
same space once automatic is disabled. Do you mind posting a simple example
on how to alter draw object method you mentioned?

I thought of simply adding another "jit.gl.sketch myContext @automatic 0"
object and then instantiating stuff inside of it, but that did not work, nor
did adding a bang/erase into the object’s inlet.

Best wishes,

Ico

> —–Original Message—–
> From: jitter-bounces@cycling74.com [mailto:jitter-bounces@cycling74.com]
> On Behalf Of Perry Hoberman
> Sent: Monday, June 25, 2007 11:34 AM
> Subject: [jitter] Re: another camera perspective question
>
>
> >1) glfrustum implementation may be buggy–namely, requires double entry
> of data
> >2) glfrustum in its current form affects object but not the scene, which
> would explain some of the oddities with obtained results as well as
> removal of the object from its center (when you try to rotate object with
> jit.gl.handle it appears outside the rotational center).
>
> 1. I’d bet that the problems you’re having aren’t due to bugs, they’re
> because of some quirk of whatever method you’re using. But unless you post
> an example, no one can really give you an definitive answer.
>
> 2. The way you’re stating the question would suggest you’re a bit confused
> about how the whole jit.gl system works. glfrustum is only available
> through jit.gl.sketch, so you’ll want to use one instance of jit.gl.sketch
> to control your camera. If there are other jit.gl objects (including
> additional jit.gl.sketch’s) that you want to include in the scene, turn
> off their automatic attribute and use the first jit.gl.sketch’s drawobject
> method with them. Then they’ll all be viewed from the same frustum-enabled
> camera.



ico
June 25, 2007 | 9:31 pm

To clarify my problem here’s the example patch. Namely, the object now draws
inside the renderer but its position which is updated via Max has no effect
inside the scene with frustum:

#P button 97 340 15 0;
#P window setfont "Sans Serif" 10.;
#P window linecount 1;
#P newex 97 308 48 9109514 t b erase;
#P window setfont "Sans Serif" 9.;
#P message 206 325 39 9109513 cube 2;
#P message 258 295 34 9109513 reset;
#P flonum 409 294 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 370 294 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 331 294 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 303 320 99 9109513 pak position 0. 0. 0.;
#P newex 256 347 288 9109513 jit.gl.sketch myContext @automatic 0 @name boo
@position 1 0 0;
#P flonum 171 36 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 200 66 27 9109513 + 3.;
#P flonum 513 200 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname flonum[11];
#P flonum 479 200 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname flonum[12];
#P flonum 445 200 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname flonum[13];
#P flonum 342 131 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname flonum[5];
#P flonum 308 131 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname flonum[6];
#P flonum 274 131 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname flonum[7];
#P flonum 240 131 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname flonum[8];
#P flonum 206 131 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname flonum[9];
#P flonum 172 131 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname flonum[10];
#P newex 138 152 216 9109513 pak frustum -1.33 1.33 -1. 1. 5. 120.;
#P newex 172 109 183 9109513 unpack -1.33 1.33 -1 1 1.5 120;
#P newex 73 78 45 9109513 loadbang;
#P newex 241 176 287 9109513 unpack 0 0 3 0 0 0 0 1 0;
#P flonum 411 200 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname flonum[18];
#P flonum 377 200 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname flonum[4];
#P flonum 343 200 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname flonum[3];
#P flonum 309 200 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname flonum[2];
#P flonum 275 200 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname flonum[1];
#P flonum 241 200 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname flonum;
#P newex 207 221 321 9109513 pak lookat 0. 0. 3. 0. 0. 0. 0. 1. 0.;
#P toggle 66 161 26 0;
#P newex 66 194 57 9109513 qmetro 20;
#P newex 138 278 70 9109513 js frustum.js;
#P connect 22 0 3 9;
#P connect 10 8 22 0;
#P connect 21 0 3 8;
#P connect 10 7 21 0;
#P connect 20 0 3 7;
#P connect 10 6 20 0;
#P connect 9 0 3 6;
#P connect 10 5 9 0;
#P connect 29 0 26 3;
#P connect 8 0 3 5;
#P connect 10 4 8 0;
#P connect 28 0 26 2;
#P connect 7 0 3 4;
#P connect 10 3 7 0;
#P connect 19 0 13 6;
#P connect 12 5 19 0;
#P connect 27 0 26 1;
#P connect 6 0 3 3;
#P connect 10 2 6 0;
#P connect 18 0 13 5;
#P connect 12 4 18 0;
#P connect 5 0 3 2;
#P connect 10 1 5 0;
#P connect 17 0 13 4;
#P connect 12 3 17 0;
#P connect 31 0 25 0;
#P connect 30 0 25 0;
#P connect 26 0 25 0;
#P connect 32 1 25 0;
#P connect 32 0 33 0;
#P connect 32 0 25 0;
#P connect 4 0 3 1;
#P connect 10 0 4 0;
#P connect 11 0 12 0;
#P connect 11 0 10 0;
#P connect 16 0 13 3;
#P connect 12 2 16 0;
#P connect 15 0 13 2;
#P connect 12 1 15 0;
#P connect 23 0 15 0;
#P connect 24 0 14 0;
#P connect 24 0 23 0;
#P connect 14 0 13 1;
#P connect 12 0 14 0;
#P connect 13 0 0 0;
#P connect 3 0 0 0;
#P connect 1 0 32 0;
#P connect 1 0 0 0;
#P connect 2 0 1 0;
#P window clipboard copycount 34;

//frustum.js
var renderContext = "myContext"
var look = [0,0,3,0,0,0,0,1,0];
var frust = [-1.33,1.33,-1,1,1.5,120];

var mySketch = new JitterObject("jit.gl.sketch",renderContext); // CREATE
JITTER OBJECTS
var myText = new JitterObject("jit.gl.text3d",renderContext);
var myHandle = new JitterObject("jit.gl.handle",renderContext);
var myRender = new JitterObject("jit.gl.render",renderContext);
var myWindow = new JitterObject("jit.window",renderContext);

mySketch.lighting_enable = 1;
mySketch.smooth_shading = 1;
myWindow.depthbuffer = 1;
myRender.erase_color = [0,0,0,1];

function bang() {

myRender.erase();

mySketch.reset();
mySketch.glclear();

mySketch.glmatrixmode("projection"); // PROJECTION MATRIX
mySketch.glloadidentity();
mySketch.glfrustum(frust);

mySketch.glmatrixmode("modelview"); // MODELVIEW MATRIX
mySketch.glloadidentity();
mySketch.glulookat(look);

mySketch.gltranslate(myHandle.position); // HANDLE
mySketch.glrotate(myHandle.rotate);

mySketch.glpushmatrix(); // GROUND PLANE
mySketch.gltranslate(0,-0.45,0);
mySketch.glrotate(90,0,0);
mySketch.glcolor(1,1,0,1);
mySketch.plane(2);
mySketch.glpopmatrix();

mySketch.glpushmatrix(); // CONE
mySketch.gltranslate(-1.125,0,0);
mySketch.glrotate(90,0,0);
mySketch.glcolor(1,0,0,1);
mySketch.cylinder(0.45,0,0.45);
mySketch.glpopmatrix();

mySketch.glpushmatrix(); // CUBE
mySketch.glcolor(0,0.25,1,1);
mySketch.cube(0.425);
mySketch.glpopmatrix();

mySketch.glpushmatrix(); // SPHERE
mySketch.gltranslate(1.125,0,0);
mySketch.glcolor(0,1,0,1);
mySketch.sphere(0.45);
mySketch.glpopmatrix();

mySketch.drawobject("boo",1);

myRender.updateclients();
myRender.drawswap();
}

function lookat(a,b,c,d,e,f) {
look = [a,b,c,d,e,f,0,1,0];
}

function frustum(a,b,c,d,e,f) {
frust = [a,b,c,d,e,f];
}
//end frustum.js

What am I missing?

Ico


June 25, 2007 | 10:57 pm

I don’t really know what that sketch in the patch is supposed to be
doing, especially with the [t b erase] hooked into it. It’s not
going to be afected by any frustum calls because that all gets negated
by the draw method of jit.gl.sketch. Did you ever see the
public_ob3d.c file? It might be enlightening. The ob3d_draw_begin and
ob3d_draw_preamble get called _every_ time a jit.gl object draws in
the normal fashion.

wes



ico
June 26, 2007 | 12:25 am

The other sketch was supposed to have its object instantiated manually (I
believe in that version was a cube 2) and rendered it via other
jit.gl.sketch in order to be affected by the same custom frustum. The [t b
erase] was a pointless experiment at me trying to understand the concept.

FWIW, I finally figured out the problem. Changing drawobject call

mySketch.drawobject("boo",1);

to

mySketch.drawobject("boo",0);

inside the js file did the trick. The source of this problem was in part
because I copied drawobject(name, 1); call from another patch that was
posted on the list a while ago and which worked (although did not require
objects to move) and hence my assumption that it should’ve just worked and
thus the ensuing problem…

I was also unable to locate more info on drawobject in any of the jitter
documentation which would point out my error with 0 vs 1, so I finally dug
into the OpenGL API to learn more about it. Yet, there it simply talks about
the priority of rendering which is making me confused again…

Finally, for those who actually might find this useful, the default camera
frustum appears to be:

-0.0551 0.0551 -0.041429 0.041429 0.1 100

Many thanks to all for your help in this matter!

Best wishes,

Ico

> —–Original Message—–
> From: jitter-bounces@cycling74.com [mailto:jitter-bounces@cycling74.com]
> On Behalf Of Wesley Smith
> Sent: Monday, June 25, 2007 6:58 PM
> Subject: Re: [jitter] Re: another camera perspective question
>
> I don’t really know what that sketch in the patch is supposed to be
> doing, especially with the [t b erase] hooked into it. It’s not
> going to be afected by any frustum calls because that all gets negated
> by the draw method of jit.gl.sketch. Did you ever see the
> public_ob3d.c file? It might be enlightening. The ob3d_draw_begin and
> ob3d_draw_preamble get called _every_ time a jit.gl object draws in
> the normal fashion.
>
> wes


June 26, 2007 | 12:52 am

Look in the jit.gl.sketch help file in the object commands sub patch
for info on drawobject. This is a Jitter method, not an OpenGL one so
you won’t find it in the spec.

wes

On 6/25/07, Ivica Ico Bukvic wrote:
> The other sketch was supposed to have its object instantiated manually (I
> believe in that version was a cube 2) and rendered it via other
> jit.gl.sketch in order to be affected by the same custom frustum. The [t b
> erase] was a pointless experiment at me trying to understand the concept.
>
> FWIW, I finally figured out the problem. Changing drawobject call
>
> mySketch.drawobject("boo",1);
>
> to
>
> mySketch.drawobject("boo",0);
>
> inside the js file did the trick. The source of this problem was in part
> because I copied drawobject(name, 1); call from another patch that was
> posted on the list a while ago and which worked (although did not require
> objects to move) and hence my assumption that it should’ve just worked and
> thus the ensuing problem…
>
> I was also unable to locate more info on drawobject in any of the jitter
> documentation which would point out my error with 0 vs 1, so I finally dug
> into the OpenGL API to learn more about it. Yet, there it simply talks about
> the priority of rendering which is making me confused again…
>
> Finally, for those who actually might find this useful, the default camera
> frustum appears to be:
>
> -0.0551 0.0551 -0.041429 0.041429 0.1 100
>
> Many thanks to all for your help in this matter!
>
> Best wishes,
>
> Ico
>
>
> > —–Original Message—–
> > From: jitter-bounces@cycling74.com [mailto:jitter-bounces@cycling74.com]
> > On Behalf Of Wesley Smith
> > Sent: Monday, June 25, 2007 6:58 PM
> > Subject: Re: [jitter] Re: another camera perspective question
> >
> > I don’t really know what that sketch in the patch is supposed to be
> > doing, especially with the [t b erase] hooked into it. It’s not
> > going to be afected by any frustum calls because that all gets negated
> > by the draw method of jit.gl.sketch. Did you ever see the
> > public_ob3d.c file? It might be enlightening. The ob3d_draw_begin and
> > ob3d_draw_preamble get called _every_ time a jit.gl object draws in
> > the normal fashion.
> >
> > wes
>
>


Viewing 13 posts - 1 through 13 (of 13 total)