Anders Haglund wrote:

> The basic 3D operations are the same, like matris and vector operations.
> And if I  remember right the p3 have instructions just for those kind of
> operations. But to use them would require a rewrite of the matris and vector
> code used in povray, i't can't be done by just setting the compilator to
> 'P3 optimize'. Anyway, to rewrite the code shouldn't be too hard but I don't
> think the speed increase would be very big.

	How do we say this. 

	An important thing to learn in the computer business is that the
same words can mean entirely different things depending upon
context. It is the same in common english, there are the valves
on your water faucets and there are the valves at Hoover Dam.
Same word, same idea, radically different in implementation. 

	For example, vector simply means an ordered set of numbers.
Compare a color vector with a translation vector. Both are
vectors. And there are many other ordered sets. Technically our
number system is a vector as it is an ordered set of units, tens,
hundreds, etc. Simply because it says it manipulates vectors does
not necessarily mean it applies to all vectors. Without spending
much more time, a matrix is an ordered set of vectors. You can
look at a color map as a matrix. A transposition matrix is
something quite different. (And next we study TENSORS! "That's
not my department, says Wehrner von Braun.") 

	Lets say there are no problems at all with what you suggest. The
results of the P3 instructions are dumped directly to the screen.
Now if possible your best image would be limited to doing a
screen capture, as is, not resized as in a window. 

	If that problem could be overcome the instructions are designed
for a Doom/Wolfenstein-like input of objects and the manipulation
of those objects. It does not create the objects. Creating the
objects is exactly what POV does as its most fundamental
function. There is freeware around for creating your own
whatevers for the games. Get some and look at your limitations. 

	Now if you want to use the instructions themselves and can
redirect them to a screen buffer that is fed to the screen (that
is why it updates per line and not per pixel - 1.0 DOS users may
not have noticed this) then, as another as noted, speed is gained
by single rather than double precision. Single precision should
be only of historical note for every reason. 

	But then why not use the floating point package built into the
P3 instead? Same processor, same speed UNLESS they MMX
instructions cheat by being less precise? 

	Someone may implement a faster algorith but as time goes by
faster algorithms become fewer and farther between and the
improvements become less and less. At some point the algorithm
hunters go on to more profitable pastures. 

	In the last year Intel went from 333MHz to 500MHz. Processing
floating points increased proportionately. That is faster
progress than the algorithm hunters have mede in a couple
centuries. 

-- 
<blink>-------please--don't-----------------</blink>

http://www.giwersworld.org/artii/
http://www.giwersworld.org/artiii/

Finally up on 99/06/22 updated 06/30

Post a reply to this message

Attachments:
Download 'us-ascii' (1 KB)