Christopher Overstreet

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?

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?

videoplane-or-other-plane-questions

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?

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.

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?


You need to handle your own depth ordering by making your own display 

lists to fix the 'closest to the camera' issue.

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?

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

>
> 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?

> You need to handle your own depth ordering by making your own display 

> lists to fix the 'closest to the camera' issue.

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.

> 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.


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.

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 

here is a PD patch with GEM and the 'same' patch in Jitter. they 

exhibit the same behavior. hope this helps:

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.

> 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 

> 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.

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 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:

>
>
>> 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.

Use jit.gl.texture in conjunction with jit.gl.gridshape @shape plane

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

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?

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.

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
>


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

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

Suffice to say, this isn't possible in jitter just yet although depth

> 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.

> 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

> #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 newex 144 279 196 196617 jit.gl.handle target @inherit_transform 1;

> #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

> #P newex 49 188 96 196617 jit.gl.render target;

> #P newex 66 330 161 196617 jit.window target @depthbuffer 1;

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:

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

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 //
>
> 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.
>
>
>
>


videoplane or other plane questions