Hi there:
I would like to draw the trail of a geo in motion, how can I do this? I am thinking of delay the gemlist to the specified amount but having no luck in doing so.
Any suggestions?
Cheers
CHUN
Hi there:
I would like to draw the trail of a geo in motion, how can I do this? I am thinking of delay the gemlist to the specified amount but having no luck in doing so.
I think that it is not as easy as one might hope (but I look foward to a discussion on the subject). What I can say, is that the 'gemlist' is a pointer to the data in the graphics hardware (I'm not clear of details here), rather than actually the data itself.
I wrote this off-list recently, perhaps it can help explain.
"I don't vouch for the total accuracy of all of this information, but I'm sure trying to explain will help me understand, too. I don't know what you know already, either, so I'll try to be quite comprehensive, but it should be relavent. All the geometric transformations and so on that one performs with OpenGL are carried out within the GPU. As such, the software maintains a pointer to the place in the graphics hardware where the geometry is being computed, rather than working directly with the actual 3d matrices. When you use a [gemhead], it initialises a pointer with the 'identity matrix' (the origin of the scene) and triggers a new set of computations every frame. When the gem message, containing the pointer to the relevant information in the graphics hardware, reaches a geo, that causes a new shape to be rendered in the appropriate place (and color, texture, scale, shininess...). When it reaches something such as a rotate or translate object, it causes that geometric transposition to be carried out on the data to which its pointer points."
So I think you can see the difficulty in delaying the gemlist...
As far as motion blur goes, I have implemented a crude implementation for the whole scene with [pix_snap2tex] feedback on a rectangle (alpha controls the strength of the effect). This is a bit fiddly, as it's sensitive to screen dimentions, for which there is no 'get' method or callback if the window size changes. Worse still, [perspec] messages really mess it up, but maybe [ortho] would sort that out. It can be a bit slow, too, and is generally far from perfect (but quite pretty, sometimes). I think an accumulation-buffer based effect sounds more to the point (for full scene motion blur), which I think can be done with GEMgl stuff, but it strikes me as very fiddly to code in pd (especially trying to relate online tutorials for c++ or whatever back), so I haven't done it.
I have wondered a bit about individual geos leaving trails, and delay line type things, but I haven't reached much conclussion (or done much experimentation). You could use a table to store the previous frames data, and have diminishing alpha for older elements, but again it would be far from perfect. Could be workable, though. I might see what I can hack together this afternoon, otherwise it won't be for a few days. As far as a generalised 'delay line' goes, I think this could turn out to be a good approach.
Cheers
CHUN
Cheers,
Peter
I would like to draw the trail of a geo in motion, how can I do this? I am thinking of delay the gemlist to the specified amount but having no luck in doing so.
I have wondered a bit about individual geos leaving trails, and delay line type things, but I haven't reached much conclussion (or done much experimentation). You could use a table to store the previous frames data, and have diminishing alpha for older elements, but again it would be far from perfect. Could be workable, though. I might see what I can hack together this afternoon, otherwise it won't be for a few days. As far as a generalised 'delay line' goes, I think this could turn out to be a good approach.
Here's a start.
Hi Peter:
Thanks for the explanation and example.
Ya, I have only start to understand the way Gem/OpenGL works in terms of gemlist and so on. I have also tried to draw trails or repeated motions with [any] but did not get anywhere with it. Your example will be a good starting point for me.
However, a Gem delay line object could be very interesting.
Thanks again
CHUN
On 8/12/04 4:36 pm, "Peter Todd" peter_todd82@yahoo.co.uk wrote:
I would like to draw the trail of a geo in motion, how can I do this? I am thinking of delay the gemlist to the specified amount but having no luck in doing so.
I have wondered a bit about individual geos leaving trails, and delay line type things, but I haven't reached much conclussion (or done much experimentation). You could use a table to store the previous frames data, and have diminishing alpha for older elements, but again it would be far from perfect. Could be workable, though. I might see what I can hack together this afternoon, otherwise it won't be for a few days. As far as a generalised 'delay line' goes, I think this could turn out to be a good approach.
Here's a start.
On Dec 8, 2004, at 11:14 AM, Peter Todd wrote:
Hi there:
I would like to draw the trail of a geo in motion, how can I do this? I am thinking of delay the gemlist to the specified amount but having no luck in doing so.
I think that it is not as easy as one might hope (but I look foward to a discussion on the subject).
hey ya'll,
...motion blurring is a very high priority for me atm :-)
Unfortunately, there isn't exactly an easy way :-\ The traditional way
is to cheat and use the accumulation buffer: ya render to this buffer
several frames with each slightly lighter, then pop out the
result...this doesn't give a directional blur, tho, and also it so
happens that OSX has a software implementation of this buffer, so it's
sloow...
...the better way is still in the future, and involves vertex &/or fragment programs along with pBuffers...there's plenty about this on the web, but it's just not do-able in GEM atm...soon, perhaps?
jamie
Hi James:
hey ya'll,
...motion blurring is a very high priority for me atm :-) Unfortunately, there isn't exactly an easy way :-\ The traditional way is to cheat and use the accumulation buffer: ya render to this buffer several frames with each slightly lighter, then pop out the result...this doesn't give a directional blur, tho, and also it so happens that OSX has a software implementation of this buffer, so it's sloow...
Ummm, sound a bit out of my depth;) but sufficient to say that its not easy...
...the better way is still in the future, and involves vertex &/or fragment programs along with pBuffers...there's plenty about this on the web, but it's just not do-able in GEM atm...soon, perhaps?
Not do-able in Gem at the moment? Is it because of the way Gem is written or OpenGL?
Cheers
CHUN
On Dec 8, 2004, at 10:14 AM, Peter Todd wrote:
What I can say, is that the 'gemlist' is a pointer to the data in the graphics hardware (I'm not clear of details here), rather than actually the data itself.
I don't know what you mean exactly by 'pointer to the data in the graphics hardware', but here's a simple little chain with some descriptions of what the objects do:
[gemhead] - resets the matrices using push/pop GL calls and zeros out some other data | | [rotate] - tells the GPU to rotate the entire current matrix using glRotate(). | | [color] - changes the draw color for every drawing command after it. | | [cube] - draws a cube using immediate mode calls. all drawing is done inside this object.
In this chain, GEM doesn't need to pass any data between objects as it
simply issues instructions to the GPU state machine, which are
processed in order. The [gemhead] resets the matrices to the origin
(0,0,0), and [rotate] will transform the entire matrix data around the
origin, so anything drawn in this chain will be transformed this way.
The [color] objects tells the GPU to draw every vertex from that point
on the same color until another glColor() command is sent. All of the
Geos do their drawing in a self-contained block of calls, which is
known as immediate mode ([model] is the exception in that it uses a
display list). Because the drawing is self-contained, there is no
vertex and color data passed between objects, which is why users can't
get to those individual values. in addition, immediate mode is the
slowest method of drawing in OpenGL and most applications that need
real-time performance have moved beyond it. The [polygon] object does
allow for the user to create a Geo by specifying each vertex, but the
drawing still happens in immediate mode.
Texture coordinates are the only thing that GEM sends down the chain, and the [pix_texture] object initializes the values based on the dimensions of the texture. []pix_coordinate] can change the texture coordinate data as it is represented by 4 x,y pairs. Geos will then internally map that texture data to each vertex, and again this data is not accessible to the user.
The GEM CVS does have a set of objects in the vertex_array branch that adds a new drawing model which allows for extensive user manipulations. These objects do pass vertex, normal, color and texture coordinate data around, and the user can manipulate them using a variety of objects much like the pix_ ones. This system does correspond more closely to the description of 'a pointer to the data in the graphics hardware' because the arrays get uploaded all at once, straight to the card through a simple set of calls, and the client side arrays do have a 1:1 correspondence to the data on the GPU. The vertex_array system still requires a great deal of work to make it all viable, and currently there is no planned date for final release.
cgc
On Dec 8, 2004, at 10:14 AM, Peter Todd wrote:
What I can say, is that the 'gemlist' is a pointer to the data in the graphics hardware (I'm not clear of details here), rather than actually the data itself.
I don't know what you mean exactly by 'pointer to the data in the graphics hardware',
Neither did I, really ;-). Thanks for the corrected explenation (now my erroneous one hopefully won't get the chance to mis-educate or otherwise confuse anyone).
but here's a simple little chain with some descriptions of what the objects do:
[gemhead] - resets the matrices using push/pop GL calls and zeros out some other data | | [rotate] - tells the GPU to rotate the entire current matrix using glRotate(). | | [color] - changes the draw color for every drawing command after it. | | [cube] - draws a cube using immediate mode calls. all drawing is done inside this object.
In this chain, GEM doesn't need to pass any data between objects as it simply issues instructions to the GPU state machine, which are processed in order.
Right, ok. I guess it's not so far from what I thought.
The [gemhead] resets the matrices to the origin (0,0,0), and [rotate] will transform the entire matrix data around the origin, so anything drawn in this chain will be transformed this way. The [color] objects tells the GPU to draw every vertex from that point on the same color until another glColor() command is sent. All of the Geos do their drawing in a self-contained block of calls, which is known as immediate mode ([model] is the exception in that it uses a display list). Because the drawing is self-contained, there is no vertex and color data passed between objects, which is why users can't get to those individual values. in addition, immediate mode is the slowest method of drawing in OpenGL and most applications that need real-time performance have moved beyond it. The [polygon] object does allow for the user to create a Geo by specifying each vertex, but the drawing still happens in immediate mode.
Texture coordinates are the only thing that GEM sends down the chain, and the [pix_texture] object initializes the values based on the dimensions of the texture. []pix_coordinate] can change the texture coordinate data as it is represented by 4 x,y pairs. Geos will then internally map that texture data to each vertex, and again this data is not accessible to the user.
The GEM CVS does have a set of objects in the vertex_array branch that adds a new drawing model which allows for extensive user manipulations. These objects do pass vertex, normal, color and texture coordinate data around, and the user can manipulate them using a variety of objects much like the pix_ ones. This system does correspond more closely to the description of 'a pointer to the data in the graphics hardware' because the arrays get uploaded all at once, straight to the card through a simple set of calls, and the client side arrays do have a 1:1 correspondence to the data on the GPU. The vertex_array system still requires a great deal of work to make it all viable, and currently there is no planned date for final release.
I might take try to take a look at that. Sounds promising, anyway.
Cheers Peter
cgc
hi, few days ago u posted a patch that let u manipulate geos (each accesible for manipulation) at pd list
i was using it becuase i wanted to create hair on gem .... the idea is to create a group of hairs dynamically and each hair is diferent from the others. i have to question : in the patch u posted i can repeat only 15 times the object (uzi) , not more. Why is that?is that an issue of the usi abstraction??.... the other question i have is : which are the difference using uzi and any vs using repeat? Is there any difference in cpu processing?
check the patch
bye punchik
hi, few days ago u posted a patch that let u manipulate geos (each accesible for manipulation) at pd list
i was using it becuase i wanted to create hair on gem .... the idea is to create a group of hairs dynamically and each hair is diferent from the others. i have to question : in the patch u posted i can repeat only 15 times the object (uzi) , not more. Why is that?is that an issue of the usi abstraction??.... the other question i have is : which are the difference using uzi and any vs using repeat? Is there any difference in cpu processing?
This is nothing to do with uzi, repeat, et al. The problem is that the tables only have 15 slots. Try resizing them.
check the patch
bye punchik
-
chris clepper -
chun lee -
james tittle -
Peter Todd -
pun chik