Forum unknown
· Programming
#Three-Dee graphics
21 messages in this thread
Jack –
I get about 20 frames per second, using a similar technique to the one you
describe.
However, I don't use Vector maths… I use Matrix maths with Cartesian
coordinates. Its faster, especially if you want to do Nested Instancing…
(the art of having lots of simultanelously moving and rotating aliens all
independant!)
In terms of graphics… I use Vector lines drawn to represent each facet of
an object. I also use Hidden surface removal to determine which faces are
obscured by the rest of the object.
Hiden surface removal actually SPEEDS UP the graphics processing, because
less lines are drawn, hence the frame rate is pushed up.
A typical rotate is 9 multiplies (and 6 adds). This allows an arbitrary
rotation about all 3 axes simultaneously, thus allowing an arbitrary
viewpoint from anywhere in the 3d Universe to view any direction
instantly.
— Jez.
ps. Project in question is 'StarGlider'.
Since I'm presently freelancing (read "unemployed") I had time to go to the
Universtiy of Washington (Seattle) Engneering library….in one of the
technical jounals of computer graphics there was an algorithm to reduce
ray-tracing operations from 0(N**2) operations to O(N), a significant
speed-up. Thought you'd be interested.
Since I'm presently freelancing (read "unemployed") I had time to go to the
Universtiy of Washington (Seattle) Engneering library….in one of the
technical jounals of computer graphics there was an algorithm to reduce
ray-tracing operations from 0(N**2) operations to O(N), a significant
speed-up. Thought you'd be interested.
"Hiden surface removal actually SPEEDS UP the graphics processing, because
less lines are drawn" — is that true on the Amiga (where the blitter helps
a bunch on line speed), or only on the ST? (That's an unfair question,
because I'm sure it's hard to measure… how hard is it to reassemble the
program to leave out the hidden line removal? If that's not so hard, it'd
be interesting to see if the Amiga's greater line draw speed makes up for
the additional lines that have to be drawn). – Bela
Bela –
Its certainly true on the ST. Ill let ya know if its also true on the
Amiga when I have benchmarks to hand.
I have a secret button I can press that turns on and off the hidden line
removal on StarGlider. You can press it any time you want to see the
effects. Dont konw if Ill leave this in, yet.. hehe!
Oh, by the way… even though Amiga's blitter can draw lines 10 times
faster than a Software routine….. it has to draw the entire line into
each bitplane separately. Thus if you were drawing into 5 bitplanes, you
would have to draw 5 lines!!!! On my ST linedraw subroutine, it draws
into all bitplanes simultaneously with almost negligible overhead.. so the
Blitter isn't THAT much faster at worst case!
— Jez.
Bela –
Its certainly true on the ST. Ill let ya know if its also true on the
Amiga when I have benchmarks to hand.
I have a secret button I can press that turns on and off the hidden line
removal on StarGlider. You can press it any time you want to see the
effects. Dont konw if Ill leave this in, yet.. hehe!
Oh, by the way… even though Amiga's blitter can draw lines 10 times
faster than a Software routine….. it has to draw the entire line into
each bitplane separately. Thus if you were drawing into 5 bitplanes, you
would have to draw 5 lines!!!! On my ST linedraw subroutine, it draws
into all bitplanes simultaneously with almost negligible overhead.. so the
Blitter isn't THAT much faster at worst case!
— Jez.
"Hiden surface removal actually SPEEDS UP the graphics processing, because
less lines are drawn" — is that true on the Amiga (where the blitter helps
a bunch on line speed), or only on the ST? (That's an unfair question,
because I'm sure it's hard to measure… how hard is it to reassemble the
program to leave out the hidden line removal? If that's not so hard, it'd
be interesting to see if the Amiga's greater line draw speed makes up for
the additional lines that have to be drawn). – Bela
Jez: I also would use matrix math. I was trying to make it simple for
Jeric. Too late, though … he's already slithered away in embarrassment,
or something. Took a short course some years ago on Computer Graphics, and
learned that all the hot dogs use a 4 x 4 matrix approach, so you get the
rotation and translation in one step. Assume that's what you mean.
Not sure I follow your comments re hidden line removal speeding things up.
For skeleton figures, hidden line removal is _THE_ big problem, and lots of
papers have been published on the subject. A friend and I came up with a
pretty slick way to do it for simple figures, but when you go to arbitrary
shapes and multiple bodies, there's really no recourse but to compare every
surface with every other surface to see which one's in front. That takes a
_LONG_ time, so I fail to understand your comment.
BTW, about the same time frame did a little research on the Evans &
Sutherland approach ( my company was working on a real-time simulator using
same.) Their approach is very clever… it's based on the idea that at any
instant of time, the raster point on a CRT represents a single line in
space, sweeping across a plane that corresponds to the current raster line.
So "all" you have to do is extend this line till it hits some surface. Neat
thing about it is: color and shading comes almost free, and the idea of
clipping or windowing goes away entirely. The catch: many comparisons to
make to find out which surface is hit. E & S do it with mucho parallel
hardware, hardwired for the specific algorithm.
COme to think of it, the idea fits very well with the Amiga's
raster-oriented Blitter control. If you could compute fast enough, perhaps
you could compute the next color change _BEFORE_ it has to happen, so the
Blitter could be set up for it while the CPU is continuing to compute
ahead. It has possibilities.
Jack
Jack –
Most interesting, what you said about E & S techniques! I know some guys
here who have a similar algorithm that they called Polyscan, and they
claimed it was theirs but it sounds so near to what you dedscribed by E &
S!
I agree about the horrendous maths you describe for hidden line removal,
but I agree with you, unless you use Simple shapes, with lots of
assumptions, it cannot be done quickly!
Who says I didnt use Simple shapes and lots of Assumptions in StarGlider!??
(grin!)
Perhaps I should call it Hidden Surface removal, rather than hidden line
removal… !
And I assure you, the technique im using DOES speed up the graphics
processing because the hidden surface checks are very trivial compared to
the horrendously time consuming art of DRAWING the lines onscreen!
— Jez.
Jack –
Most interesting, what you said about E & S techniques! I know some guys
here who have a similar algorithm that they called Polyscan, and they
claimed it was theirs but it sounds so near to what you dedscribed by E &
S!
I agree about the horrendous maths you describe for hidden line removal,
but I agree with you, unless you use Simple shapes, with lots of
assumptions, it cannot be done quickly!
Who says I didnt use Simple shapes and lots of Assumptions in StarGlider!??
(grin!)
Perhaps I should call it Hidden Surface removal, rather than hidden line
removal… !
And I assure you, the technique im using DOES speed up the graphics
processing because the hidden surface checks are very trivial compared to
the horrendously time consuming art of DRAWING the lines onscreen!
— Jez.
The big current method of doing efficient 3d graphics is actually quite
straightforward. You just need a bundle of RAM to do it, though (and fast
dedicated logic).
Idea is this: Each projected point (itself gotten from a dedicated
multiplier/adder that applies the rotation/translation matrix from the
original 3d coords) is tested for the need to be clipped (simple check, 4
compares). If onscreen, check the Z buffer. This is a number, 16 bits at
the min, which is the distance to the currently displayed point!
If closer (Z value < current Z buffer value, lightening fast compare) then
stick the pixel in. If not, then don't (hidden surface). Just do this for
all projected points. The Sun/3 graphic hardware has this technique
implemented in fast dedicated logic, I think.
John, not sure I got what you were saying but seems to me it's not as easy
as you seemed to be saying. You said _EACH_ projected point. Does that mean
each _PIXEL_??? If so, I agree that the approach is simple and works, but I
also agree that'll take a _WHOLE_lot of RAM!
If you meant only the node points (we were talking about skeleton figures)
then it definitely isn't that simple, since a given line may cross the
screen, even tho neither of its end points is on screen. So you have to
solve for the point the line enters the display area.
Then there's that bit about dedicated parallel logic to generate the
rotated figure. No problem believing that would help, but most of us don't
have access to such.
Jack
What's a "whole lot"? RAM is still cheap, though not so cheap as it was before
Big Brother stepped in to help out the U.S. chip manufacturers who can't keep
up with the Japanese.
Well, I guess a "whole lot" is in the eye of the beholder, but to me 360K,
which is the RAM required to digitize an Amiga screen, is a whole lot.
Jack
Well, I guess a "whole lot" is in the eye of the beholder, but to me 360K,
which is the RAM required to digitize an Amiga screen, is a whole lot.
Jack
What's a "whole lot"? RAM is still cheap, though not so cheap as it was before
Big Brother stepped in to help out the U.S. chip manufacturers who can't keep
up with the Japanese.
By the way, I was only talking about high end graphics systems. There are
much less time consuming but still powerful 3d systems that are possible for
Amiga style hardware. I know, I've written one.
By the way, I was only talking about high end graphics systems. There are
much less time consuming but still powerful 3d systems that are possible for
Amiga style hardware. I know, I've written one.
John, not sure I got what you were saying but seems to me it's not as easy
as you seemed to be saying. You said _EACH_ projected point. Does that mean
each _PIXEL_??? If so, I agree that the approach is simple and works, but I
also agree that'll take a _WHOLE_lot of RAM!
If you meant only the node points (we were talking about skeleton figures)
then it definitely isn't that simple, since a given line may cross the
screen, even tho neither of its end points is on screen. So you have to
solve for the point the line enters the display area.
Then there's that bit about dedicated parallel logic to generate the
rotated figure. No problem believing that would help, but most of us don't
have access to such.
Jack
The big current method of doing efficient 3d graphics is actually quite
straightforward. You just need a bundle of RAM to do it, though (and fast
dedicated logic).
Idea is this: Each projected point (itself gotten from a dedicated
multiplier/adder that applies the rotation/translation matrix from the
original 3d coords) is tested for the need to be clipped (simple check, 4
compares). If onscreen, check the Z buffer. This is a number, 16 bits at
the min, which is the distance to the currently displayed point!
If closer (Z value < current Z buffer value, lightening fast compare) then
stick the pixel in. If not, then don't (hidden surface). Just do this for
all projected points. The Sun/3 graphic hardware has this technique
implemented in fast dedicated logic, I think.
Jez: I also would use matrix math. I was trying to make it simple for
Jeric. Too late, though … he's already slithered away in embarrassment,
or something. Took a short course some years ago on Computer Graphics, and
learned that all the hot dogs use a 4 x 4 matrix approach, so you get the
rotation and translation in one step. Assume that's what you mean.
Not sure I follow your comments re hidden line removal speeding things up.
For skeleton figures, hidden line removal is _THE_ big problem, and lots of
papers have been published on the subject. A friend and I came up with a
pretty slick way to do it for simple figures, but when you go to arbitrary
shapes and multiple bodies, there's really no recourse but to compare every
surface with every other surface to see which one's in front. That takes a
_LONG_ time, so I fail to understand your comment.
BTW, about the same time frame did a little research on the Evans &
Sutherland approach ( my company was working on a real-time simulator using
same.) Their approach is very clever… it's based on the idea that at any
instant of time, the raster point on a CRT represents a single line in
space, sweeping across a plane that corresponds to the current raster line.
So "all" you have to do is extend this line till it hits some surface. Neat
thing about it is: color and shading comes almost free, and the idea of
clipping or windowing goes away entirely. The catch: many comparisons to
make to find out which surface is hit. E & S do it with mucho parallel
hardware, hardwired for the specific algorithm.
COme to think of it, the idea fits very well with the Amiga's
raster-oriented Blitter control. If you could compute fast enough, perhaps
you could compute the next color change _BEFORE_ it has to happen, so the
Blitter could be set up for it while the CPU is continuing to compute
ahead. It has possibilities.
Jack