videoplane or other plane questions

Jul 15, 2006 at 7:06pm

videoplane or other plane questions

I’ve been using videoplanes as 3D objects in a first-person world and having a heck of a time with getting them to display correctly according to their depth order, even with the new layers attribute in the beta.

I just realized that if I replace them with jit.gl.plato all those problems took care of themselves. I guess this is because a jit.gl.videoplane isn’t truly a 3D object? Anyways, now what I am wondering, is that if I want to use video as a texture will things slow down this way? And what is the fastest way to do that. I do not yet have shader support. Should I just refernce a jit.gl.texture object that has live video going into it?

Thanks,
Christopher Overstreet

#26812
Jul 15, 2006 at 7:28pm

So I spoke to soon. I still can’t seem to get depth to work properly.

I have tried all combinations of layering and drawing with automatic off giving all of the transformations in the correct order. I can get things to look correct from one side but if I move the camera to the other side and everything is still drawn in the same order regardless of what is in front in the 3D space.

I have also tried many combinations of depth_enable 1/0, depthbuffer 1/0, on all objects and have tried doublebuffer 1/0 to jit.gl.render and jit.window and nothing seems to change.

Another short unrelated question. In a first person type jitter environment is it best to set the camera, and primarily use the position command to move around? Or maybe just use one or the other?

#80593
Jul 15, 2006 at 9:01pm

You need to handle your own depth ordering by making your own display
lists to fix the ‘closest to the camera’ issue.

v a d e //

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

On Jul 15, 2006, at 3:28 PM, Christopher Overstreet wrote:

>
> So I spoke to soon. I still can’t seem to get depth to work properly.
>
> I have tried all combinations of layering and drawing with
> automatic off giving all of the transformations in the correct
> order. I can get things to look correct from one side but if I
> move the camera to the other side and everything is still drawn in
> the same order regardless of what is in front in the 3D space.
>
> I have also tried many combinations of depth_enable 1/0,
> depthbuffer 1/0, on all objects and have tried doublebuffer 1/0 to
> jit.gl.render and jit.window and nothing seems to change.
>
> Another short unrelated question. In a first person type jitter
> environment is it best to set the camera, and primarily use the
> position command to move around? Or maybe just use one or the other?

#80594
Jul 16, 2006 at 4:12am

> You need to handle your own depth ordering by making your own display
> lists to fix the ‘closest to the camera’ issue.
>
>
> v a d e //
>

This seems quite complicated, especially with my forgotten math skills, but seems like it could solve some collision detection problems as well. So would the answer be something like…

For every 3D object I create it needs to store its position and scale into a matrix “objects position table”. Then each dimension of this matrix is compared to the camera’s position using something like the pythagorean theorem to find the distances. The objects are then each sent a draw command or bang in the order of furthest to closest?

BTW, when I played with GEM and PD the other day I noticed that this all seems to be handled by the system. Less flexible yes but…

I can’t wait until there is a physics object for Jitter with a counter-part to handle collision detection, depth ordering, etc.

#80595
Jul 16, 2006 at 7:37am

pmpd runs in max? (Physical modelling – ie springs, masses,
dampening. Hans Christoph Steiner [package manager for PD Extended)
showed it to me the other day. Calling it sexy is an understatement.

yes, ive been meaning to try it ;)

http://www.cnmat.berkeley.edu/%7Eali/share/max/pmpd/

it looks fantastic, if it runs anything like in PD.

yes and no about my prior comments. it depends on the complexity of
your scene. you can tell max to handle it for you for simple stuff.
make sure you give depth_enable 1 to your objects and depthbuffer 1
to your jit.window:

here is a PD patch with GEM and the ‘same’ patch in Jitter. they
exhibit the same behavior. hope this helps:

max-

#P window setfont “Sans Serif” 9.;
#P window linecount 2;
#P newex 191 97 263 196617 jit.gl.plato target @shape cube @scale 0.5
0.5 0.5 @depth_enable 1 @lighting_enable 1 @smooth_shading 1;
#P window linecount 1;
#P newex 144 279 196 196617 jit.gl.handle target @inherit_transform 1;
#P window linecount 2;
#P newex 214 160 338 196617 jit.gl.plato target @shape cube @scale
0.5 0.5 0.5 @position 0.5 0.5 0.5 @color 0 255 0 @depth_enable 1
@lighting_enable 1 @smooth_shading 1;
#P toggle 46 45 15 0;
#P window linecount 1;
#P newex 49 65 51 196617 qmetro 2;
#P newex 46 98 61 196617 t b b erase;
#P newex 49 188 96 196617 jit.gl.render target;
#P newex 66 330 161 196617 jit.window target @depthbuffer 1;
#P connect 6 0 1 0;
#P connect 4 0 3 0;
#P connect 3 0 2 0;
#P connect 2 0 1 0;
#P connect 2 2 1 0;
#P window clipboard copycount 8;

pd-

#N canvas 256 159 764 493 10;
#X msg 59 20 create , 1;
#X msg 128 19 0 , destroy;
#X obj 68 44 gemwin;
#X obj 183 74 gemhead;
#X obj 282 76 gemhead;
#X obj 180 230 cube 0.5;
#X obj 280 232 cube 0.5;
#X obj 138 125 color 0 1 0;
#X obj 461 353 camera;
#X obj 461 241 gemhead;
#X obj 444 278 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0
1;
#X obj 467 259 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0
1;
#X obj 516 304 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0
1;
#X obj 542 282 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 1
1;
#X msg 516 320 left $1;
#X msg 542 298 right $1;
#X obj 357 316 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0
1;
#X obj 383 294 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 1
1;
#X msg 383 310 up $1;
#X msg 357 332 down $1;
#X msg 549 254 reset;
#X msg 467 276 forward $1;
#X msg 444 294 reverse $1;
#X msg 348 448 speed $1;
#X floatatom 348 430 5 0 0 0 – - -;
#X floatatom 349 391 5 0 0 0 – - -;
#X msg 661 346 lookX $1;
#X msg 661 383 lookY $1;
#X msg 661 419 lookZ $1;
#X floatatom 661 330 5 0 0 0 – - -;
#X floatatom 661 403 5 0 0 0 – - -;
#X floatatom 661 366 5 0 0 0 – - -;
#X msg 349 409 distance $1;
#X obj 261 161 translateXYZ 0.5 0.5 0.5;
#X connect 0 0 2 0;
#X connect 1 0 2 0;
#X connect 3 0 7 0;
#X connect 4 0 33 0;
#X connect 7 0 5 0;
#X connect 9 0 8 0;
#X connect 10 0 22 0;
#X connect 11 0 21 0;
#X connect 12 0 14 0;
#X connect 13 0 15 0;
#X connect 14 0 8 0;
#X connect 15 0 8 0;
#X connect 16 0 19 0;
#X connect 17 0 18 0;
#X connect 18 0 8 0;
#X connect 19 0 8 0;
#X connect 20 0 8 0;
#X connect 21 0 8 0;
#X connect 22 0 8 0;
#X connect 23 0 8 0;
#X connect 24 0 23 0;
#X connect 25 0 32 0;
#X connect 26 0 8 0;
#X connect 27 0 8 0;
#X connect 28 0 8 0;
#X connect 29 0 26 0;
#X connect 30 0 28 0;
#X connect 31 0 27 0;
#X connect 32 0 8 0;
#X connect 33 0 6 0;

v a d e //

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

On Jul 16, 2006, at 12:12 AM, Christopher Overstreet wrote:

>
>
>> You need to handle your own depth ordering by making your own display
>> lists to fix the ‘closest to the camera’ issue.
>>
>>
>> v a d e //
>>
>
> This seems quite complicated, especially with my forgotten math
> skills, but seems like it could solve some collision detection
> problems as well. So would the answer be something like…
>
> For every 3D object I create it needs to store its position and
> scale into a matrix “objects position table”. Then each dimension
> of this matrix is compared to the camera’s position using
> something like the pythagorean theorem to find the distances. The
> objects are then each sent a draw command or bang in the order of
> furthest to closest?
>
> BTW, when I played with GEM and PD the other day I noticed that
> this all seems to be handled by the system. Less flexible yes but…
>
> I can’t wait until there is a physics object for Jitter with a
> counter-part to handle collision detection, depth ordering, etc.

#80596
Jul 16, 2006 at 2:24pm

You can do one of several things:

Use jit.gl.texture in conjunction with jit.gl.gridshape @shape plane
with a low dim count.
Use jit.gl.texture in conjunction with jit.gl.mesh and send it a
4-point quad with corresponding tex coords.

Basically anyway you can texture 4 vertices can get you can do what
jit.gl.videoplane does. BTW, jit.gl.videoplane should work properly.
Perhaps you can post a patch as there are any number of things that
could be going awry.

best,
wes

On 7/15/06, Christopher Overstreet wrote:
>
> I’ve been using videoplanes as 3D objects in a first-person world and having a heck of a time with getting them to display correctly according to their depth order, even with the new layers attribute in the beta.
>
> I just realized that if I replace them with jit.gl.plato all those problems took care of themselves. I guess this is because a jit.gl.videoplane isn’t truly a 3D object? Anyways, now what I am wondering, is that if I want to use video as a texture will things slow down this way? And what is the fastest way to do that. I do not yet have shader support. Should I just refernce a jit.gl.texture object that has live video going into it?
>
> Thanks,
> Christopher Overstreet
>

#80597
Jul 16, 2006 at 2:31pm

Are you setting jit.window mywindow @depthbuffer 1? If you din;t give
jit.window a depthbuffer, you won’t have depth testing and this won’t
have object ordering based on z-value. That said, this doesn’t apply
to transparent objects and in this case, you have to do Z-ordering
yourself which is really a pain. There are some techniques for
getting around this using shaders and depth textures. The technique
is generally called depth peeling:

http://developer.nvidia.com/object/Interactive_Order_Transparency.html

Suffice to say, this isn’t possible in jitter just yet although depth
textures is on the horizon.

best,
wes

On 7/16/06, vade wrote:
>
> pmpd runs in max? (Physical modelling – ie springs, masses, dampening. Hans
> Christoph Steiner [package manager for PD Extended) showed it to me the
> other day. Calling it sexy is an understatement.
>
> yes, ive been meaning to try it ;)
>
>
>
> http://www.cnmat.berkeley.edu/%7Eali/share/max/pmpd/
>
> it looks fantastic, if it runs anything like in PD.
>
> yes and no about my prior comments. it depends on the complexity of your
> scene. you can tell max to handle it for you for simple stuff. make sure you
> give depth_enable 1 to your objects and depthbuffer 1 to your jit.window:
>
> here is a PD patch with GEM and the ‘same’ patch in Jitter. they exhibit the
> same behavior. hope this helps:
>
> max-
>
>
> #P window setfont “Sans Serif” 9.;
> #P window linecount 2;
> #P newex 191 97 263 196617 jit.gl.plato target @shape cube @scale 0.5 0.5
> 0.5 @depth_enable 1 @lighting_enable 1 @smooth_shading 1;
> #P window linecount 1;
> #P newex 144 279 196 196617 jit.gl.handle target @inherit_transform 1;
> #P window linecount 2;
> #P newex 214 160 338 196617 jit.gl.plato target @shape cube @scale 0.5 0.5
> 0.5 @position 0.5 0.5 0.5 @color 0 255 0 @depth_enable 1 @lighting_enable 1
> @smooth_shading 1;
> #P toggle 46 45 15 0;
> #P window linecount 1;
> #P newex 49 65 51 196617 qmetro 2;
> #P newex 46 98 61 196617 t b b erase;
> #P newex 49 188 96 196617 jit.gl.render target;
> #P newex 66 330 161 196617 jit.window target @depthbuffer 1;
> #P connect 6 0 1 0;
> #P connect 4 0 3 0;
> #P connect 3 0 2 0;
> #P connect 2 0 1 0;
> #P connect 2 2 1 0;
> #P window clipboard copycount 8;
>
>
> pd-
>
> #N canvas 256 159 764 493 10;
> #X msg 59 20 create , 1;
> #X msg 128 19 0 , destroy;
> #X obj 68 44 gemwin;
> #X obj 183 74 gemhead;
> #X obj 282 76 gemhead;
> #X obj 180 230 cube 0.5;
> #X obj 280 232 cube 0.5;
> #X obj 138 125 color 0 1 0;
> #X obj 461 353 camera;
> #X obj 461 241 gemhead;
> #X obj 444 278 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0
> 1;
> #X obj 467 259 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0
> 1;
> #X obj 516 304 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0
> 1;
> #X obj 542 282 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 1
> 1;
> #X msg 516 320 left $1;
> #X msg 542 298 right $1;
> #X obj 357 316 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0
> 1;
> #X obj 383 294 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 1
> 1;
> #X msg 383 310 up $1;
> #X msg 357 332 down $1;
> #X msg 549 254 reset;
> #X msg 467 276 forward $1;
> #X msg 444 294 reverse $1;
> #X msg 348 448 speed $1;
> #X floatatom 348 430 5 0 0 0 – - -;
> #X floatatom 349 391 5 0 0 0 – - -;
> #X msg 661 346 lookX $1;
> #X msg 661 383 lookY $1;
> #X msg 661 419 lookZ $1;
> #X floatatom 661 330 5 0 0 0 – - -;
> #X floatatom 661 403 5 0 0 0 – - -;
> #X floatatom 661 366 5 0 0 0 – - -;
> #X msg 349 409 distance $1;
> #X obj 261 161 translateXYZ 0.5 0.5 0.5;
> #X connect 0 0 2 0;
> #X connect 1 0 2 0;
> #X connect 3 0 7 0;
> #X connect 4 0 33 0;
> #X connect 7 0 5 0;
> #X connect 9 0 8 0;
> #X connect 10 0 22 0;
> #X connect 11 0 21 0;
> #X connect 12 0 14 0;
> #X connect 13 0 15 0;
> #X connect 14 0 8 0;
> #X connect 15 0 8 0;
> #X connect 16 0 19 0;
> #X connect 17 0 18 0;
> #X connect 18 0 8 0;
> #X connect 19 0 8 0;
> #X connect 20 0 8 0;
> #X connect 21 0 8 0;
> #X connect 22 0 8 0;
> #X connect 23 0 8 0;
> #X connect 24 0 23 0;
> #X connect 25 0 32 0;
> #X connect 26 0 8 0;
> #X connect 27 0 8 0;
> #X connect 28 0 8 0;
> #X connect 29 0 26 0;
> #X connect 30 0 28 0;
> #X connect 31 0 27 0;
> #X connect 32 0 8 0;
> #X connect 33 0 6 0;
>
>
> v a d e //
>
> http://www.vade.info
> abstrakt.vade.info
>
>
>
>
>
> On Jul 16, 2006, at 12:12 AM, Christopher Overstreet wrote:
>
>
>
>
> You need to handle your own depth ordering by making your own display
> lists to fix the ‘closest to the camera’ issue.
>
>
> v a d e //
>
>
>
> This seems quite complicated, especially with my forgotten math skills, but
> seems like it could solve some collision detection problems as well. So
> would the answer be something like…
>
> For every 3D object I create it needs to store its position and scale into a
> matrix “objects position table”. Then each dimension of this matrix is
> compared to the camera’s position using something like the pythagorean
> theorem to find the distances. The objects are then each sent a draw
> command or bang in the order of furthest to closest?
>
> BTW, when I played with GEM and PD the other day I noticed that this all
> seems to be handled by the system. Less flexible yes but…
>
> I can’t wait until there is a physics object for Jitter with a counter-part
> to handle collision detection, depth ordering, etc.
>
>
>
>

#80598
Jul 16, 2006 at 2:56pm

Try this patch out.

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P message 199 394 83 196617 read dishes.mov;
#P flonum 492 373 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 492 394 42 196617 rate $1;
#P message 356 394 28 196617 read;
#P message 426 394 27 196617 stop;
#P message 392 394 31 196617 start;
#P flonum 335 373 35 9 0.5 0 1 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P toggle 293 373 15 0;
#P newex 293 393 52 196617 metro 30;
#P message 456 394 31 196617 clear;
#P newex 293 420 103 196617 jit.qt.movie 320 240;
#P newex 293 443 259 196617 jit.gl.videoplane dp @depth_enable 1
@rotate -45 0 1 0;
#P message 269 276 80 196617 read dozer.mov;
#P flonum 562 255 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 562 276 42 196617 rate $1;
#P message 426 276 28 196617 read;
#P message 496 276 27 196617 stop;
#P message 462 276 31 196617 start;
#P flonum 405 255 35 9 0.5 0 1 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P toggle 363 255 15 0;
#P newex 363 275 52 196617 metro 30;
#P message 526 276 31 196617 clear;
#P newex 363 302 103 196617 jit.qt.movie 320 240;
#P newex 363 325 254 196617 jit.gl.videoplane dp @depth_enable 1
@rotate 45 0 1 0;
#P toggle 190 131 15 0;
#P message 190 151 68 196617 fullscreen $1;
#N vpatcher 30 89 166 253;
#P window setfont “Sans Serif” 9.;
#P newex 50 71 35 196617 sel 27;
#P newex 50 50 40 196617 key;
#P outlet 50 93 15 0;
#P connect 1 0 2 0;
#P connect 2 0 0 0;
#P pop;
#P newobj 190 111 33 196617 p Esc;
#P newex 88 129 48 196617 loadbang;
#P newex 190 169 143 196617 jit.window dp @depthbuffer 1;
#P message 151 169 34 196617 reset;
#P newex 151 190 178 196617 jit.gl.handle dp @inherit_transform 1;
#P toggle 88 150 15 0;
#P newex 88 169 57 196617 qmetro 60;
#P newex 88 190 50 196617 t b erase;
#P newex 88 215 240 196617 jit.gl.render dp @rotate -45 1 0 0 @camera 0 0 -3;
#P fasten 1 0 0 0 93 211 93 211;
#P fasten 1 1 0 0 133 211 93 211;
#P fasten 4 0 0 0 156 211 93 211;
#P connect 24 0 23 0;
#P connect 12 0 11 0;
#P connect 27 0 26 0;
#P fasten 32 0 24 0 497 415 298 415;
#P fasten 31 0 24 0 361 415 298 415;
#P fasten 30 0 24 0 431 415 298 415;
#P fasten 29 0 24 0 397 415 298 415;
#P fasten 25 0 24 0 461 415 298 415;
#P fasten 26 0 24 0 298 418 298 418;
#P connect 28 0 26 1;
#P connect 33 0 32 0;
#P connect 34 0 24 0;
#P connect 22 0 12 0;
#P connect 21 0 20 0;
#P connect 16 0 14 1;
#P fasten 14 0 12 0 368 300 368 300;
#P fasten 13 0 12 0 531 297 368 297;
#P fasten 17 0 12 0 467 297 368 297;
#P fasten 18 0 12 0 501 297 368 297;
#P fasten 19 0 12 0 431 297 368 297;
#P fasten 20 0 12 0 567 297 368 297;
#P connect 15 0 14 0;
#P connect 9 0 6 0;
#P connect 5 0 4 0;
#P connect 10 0 9 0;
#P connect 8 0 10 0;
#P connect 2 0 1 0;
#P connect 3 0 2 0;
#P connect 7 0 3 0;
#P window clipboard copycount 35;

#80599

You must be logged in to reply to this topic.