🚀 go-pugleaf

In article <56rk4i$h...@scam.XCF.Berkeley.EDU>,
Jonathan Blow  <j...@bolt-action.com> wrote:
>In article <01bbd5de$e8e68ca0$0300...@caladium.lw.net>,
>Ryan Alyn Porter <r...@endymion.com> wrote:
>>
>>S.A. Janczewski <fa...@faza.win.net> wrote in article
>><328FCA...@faza.win.net>...
>>> For a long time, I have felt that the existing 3D rendering methods are
>>> inefficient (especially for interactive games) and that a better,
>>> degrees of magnitude faster, universal rendering method could be found.
>>
>>>From your documentation, I think that I see a problem: I don't think
>>that most people will consider five frames per second on a 200MHz 
>>Pentium Pro to be anywhere near "fast".
>>
>>You seem to be describing raycasting. BTW, which is not really that
>>revolutionary.  Pretty screenshots, though.
>
>
>Yes, I downloaded and ran the software.  It looks to me exactly
>like a raycasting voxel engine, so I assume that Mr. Janczewski
>has independently "discovered" this technique.  (He mentions on
>his web page "the two main types of graphics techniques" and doesn't
>at all mention voxels, so I assume he'd never heard of them.)
>
>Since there are no controls for tilting the viewplane, it looks like
>he's figuring out which plane of Z a given pixel's projector casts
>into (orthographically), and doing a 2D raycast in that voxel
>slice.  This might explain why the perspective seems fairly weird
>(at first I thought it seemed entirely orthographic, but upon 
>examination I saw that there was indeed some perspective; perhaps
>there is perspective only in the horizontal direction.)

	Yes, I did notice some artificating when moving up/down, which
may mean your hypothesis is corect.

>It also looks like he combines voxels into lower-resolution models
>8-to-1 (analagous to mipmapping), though he does it early, so the
>results are visible (you can see the voxels blur together pretty
>distinctly.

	Yes, this does explain the lack of banking on the view
port, but nonetheless the constant reference to the ability of
this to be resolution independent (ie: arbitrary precision of
t-maps) suggested an octree style organization.  By holding colour
& child mask in two bytes, you could get "free" mip mapping
(by cutting search inside each voxel off at a depth based on
distance to viewer) along with storage space proportianal to
the perimeter of the objects.  Of course, if this were the case,
why not have banking?  (And could this be implemented at 10 fps
on a 200Mhz PPro?  ie: Is a ppro 200 fast enough...)
	Oct-trees would provide a basis for the "Magic Cube"
description.  :>
-- 
		- Jeff Lait (SOL)