mccaugh@uiucdcsb.cs.uiuc.edu (03/14/88)
I would be very interested in any info on the emerging concept of "point graphics" which is a graphics model assuming 'smart pixels' -- w.g., in an animation sequence involving the possibility of 2 or more objects colliding, the first (i.e., fastest) object first sets a pixel-set to the value 'occupied' so that other objects moving into the set will cause a collision to be sensed. Presumably, the intent is to avoid computation of first- and second-degree simultaneous equations to decide presence of collision. I believe each pixel is represented by a record containing more info than just whether it is occupied (color, hue, etc.) Thanks for any help whatever. -- Scott
jbn@glacier.STANFORD.EDU (John B. Nagle) (03/16/88)
Hidden surface elimination is often performed in hardware by
storing a Z value for each pixel and updating pixels in such a way that
points further than the one already stored at a given X,Y do not update
the screen, while nearer points update both the screen and the Z value.
This is called a Z-buffer. A number of high-end graphics machines have
Z-buffers, including the high-end HP and Apollo solid modelling workstations.
Matrox makes a graphics board set for the IBM PC that includes a Z-buffer.
Collision detection in 2D is standard on low-end game machines.
Expansion of this concept into 3D is an obvious next step. I've been
thinking idly about 3D sprites, and suspect that it wouldn't be all that
hard to do. Z-depth is just like sprite priority, but with more bits.
That alone would give you 3D isometric sprites that could be moved in
X,Y and Z. Perspective will require a bit more support. But recognize
that you can probably get away with recomputing the perspective view
of the moving object only a few times a second (assuming that the
3D sprite is double-buffered) since it will blur as it moves and this
will conceal any transient effects.
All this just gets you the ability to move a few objects around
in real time against a generally static background without having enough
computational power to redraw everything on every fram cycle. But
you still don't have full collision detection. A true voxel-based
collision detection system is likely to be a bit expensive for now.
But it might be possible to fake it for some common situations.
John Nagleterry@wsccs.UUCP (terry) (03/23/88)
In article <165500005@uiucdcsb>, mccaugh@uiucdcsb.cs.uiuc.edu writes: > > I would be very interested in any info on the emerging concept of "point > graphics" which is a graphics model assuming 'smart pixels' -- w.g., in > an animation sequence involving the possibility of 2 or more objects > colliding, the first (i.e., fastest) object first sets a pixel-set to > the value 'occupied' so that other objects moving into the set will > cause a collision to be sensed. Presumably, the intent is to avoid > computation of first- and second-degree simultaneous equations to > decide presence of collision. I think that it would be possible to determine a graphics object via rubber-banding bezier curves. The method involved would be to simply define your object in cubic arrangements of points, thereby giving sort of spline-fractals. Then you could determine collisions by determining if any two lines defined by the edge of the cubic had a collision by using any 3 of the 4 points involved to define a plane and determining whether or not the fourth point was above or below the plane. Admittedly, if your curve exceeded the length of the line segment forming it, either above or below the segment when projected into the plane defined by the curve and the points defining the curve, you would have points sticking up which could not be detected. I believe this method would work if you were to do several things: 1) All points must be an integer unit distance apart, with implied points at one unit intervals, therby describing equally sized cubics which define the objects. 2) All line segments must exceed or equal in heighth/depth the curves they define, as projected onto them. 3) The unit distance must be smaller than the resoloution of the collisions to be detected (if your unit length was one millimeter, you collision-detection accuracy could vary -+ a millimeter) This would have the effect of defining an orthogonal 3 dimensional grid, within which you could define your points defining your object. If you have two objects, this would have the effect of defining cubic objects in a single reference frame, or multiple reference frames, if the objects are not defined in cubics which are mutually perpindicular to each other. Either way, you would simply have to do a matrix transformation for any angle of approach of any two objects. You calc the curves only for display purposes. Much simpler! | Terry Lambert UUCP: ...{ decvax, ihnp4 } | | @ Century Software : ...utah-cs!uplherc!sp7040!obie!wsccs!terry | | SLC, Utah | | These opinions are not my companies, but if you find them | | useful, send a $20.00 donation to Brisbane Australia... | | 'There are monkey boys in the facility. Do not be alarmed; you are secure' |