Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Voxel Space (2017)

s-macke.github.io

Post reply on HN
Print view View original

11–20 of 74 posts

Re: Voxel Space (2017)

#11

Post by knome »

swiftcoder wrote: post #8
Jare wrote: post #7

[Edit] ah ok they clarify later as a performance enhancement. I think it was pretty integral to the algorithm, but ok. Wait why do they say painter's algorithm. Comanche and other such voxel terrain engines went front to back and never had overdraw.

Reverse painters algorithm is still painters algorithm. You trade off the cost of a full screen clear before the frame, in return for eliminating overdraw

You could avoid a full screen clear by using the y-buffer to draw in sky segments after rendering terrain.

Re: Voxel Space (2017)

#12

Post by swiftcoder »

knome wrote: post #11
swiftcoder wrote: post #8

Earlier quoted context omitted.

Reverse painters algorithm is still painters algorithm. You trade off the cost of a full screen clear before the frame, in return for eliminating overdraw

You could avoid a full screen clear by using the y-buffer to draw in sky segments after rendering terrain.

You still need to have some sort of mask to tell you which pixels have not yet been written this frame

Re: Voxel Space (2017)

#13

Post by s-macke »

Jare wrote: post #7

[Edit] ah ok they clarify later as a performance enhancement. I think it was pretty integral to the algorithm, but ok. Wait why do they say painter's algorithm. Comanche and other such voxel terrain engines went front to back and never had overdraw.

Author here. Yes, it is integral. I chose this approach to first show how to draw it from back to front, because the code is easier to understand this way.

Re: Voxel Space (2017)

#15

Post by knome »

swiftcoder wrote: post #12
knome wrote: post #11

Earlier quoted context omitted.

You could avoid a full screen clear by using the y-buffer to draw in sky segments after rendering terrain.

You still need to have some sort of mask to tell you which pixels have not yet been written this frame

that's what the y-buffer is that the article mentions in the front-to-back rendering section.

it tracks how tall each columns write is so you can use it to only write the diff between it and the voxel behind it, skipping writing anything at all if the voxel behind is shorter than the current height.

So once you're done rendering front-to-back, you've got a y-buffer of highest-writes you can slap your blue sky across from highest-to-screentop on each line, avoiding the need to clear by write the sky to the full screen before starting the render.

Re: Voxel Space (2017)

#16

Post by nkrisc »

taneq wrote: post #4

If you render columns instead of rows you can render near-to-far without a Y-buffer and with zero overdraw. :)

You just store the last highest Y value as you iterate near to far?

Re: Voxel Space (2017)

#17

Post by swiftcoder »

knome wrote: post #15
swiftcoder wrote: post #12

Earlier quoted context omitted.

You still need to have some sort of mask to tell you which pixels have not yet been written this frame

that's what the y-buffer is that the article mentions in the front-to-back rendering section. it tracks how tall each columns write is so you can use it to only write the diff between it and the voxel behind it, skipping writing anything at all if the voxel behind is shorter than the current height. So once you're done rendering front-to-back, you've got a y-buffer of highest-writes you can slap your blue sky across…

yes, I guess you can get away with only clearing the y buffer, rather than the whole screen

Re: Voxel Space (2017)

#18

Post by cubefox »

nine_k wrote: post #9

Technically this is not related to voxels ("volumetric pixels", so to say), which split the 3D space equally along all three axes. This is just a height map, a set of prisms, not entirely unlike a Doom map. Every prism has a regular fixed-size square base. For 1992, this was mind-boggling though.

No? Each pixel on a height map corresponds to a column of voxels of the specified height. You could represent the same height data with a fully general octree and it would look exactly the same.

Re: Voxel Space (2017)

#19

Post by mthoms »

This sure brings back memories.

I remember figuring all this out as a self-taught teenager (pre-internet) with some books, a whole lot of time, and only a high-school level understanding of trigonometry. I built different versions - first in Pascal, then C, then Assembly.

Figuring out the algorithm was hard, but one of the optimizations I was most proud of was inventing (or so I thought) lookup tables to get around the slow floating point multiplication of my 16MHz 80286 CPU. I also remember "inventing" (ha!) the old bit shift + add technique.

There was something immensely satisfying about squeezing every last drop of performance out of a machine.

Nothing ever came of it. It was more or less a demo, but man did it make me feel like I accomplished something magical. I'd give anything to have a look at that source code today, but this post is the next best thing. So thanks for sharing. This made my day.

Re: Voxel Space (2017)

#20

Post by haruharuha »

This rendering approach reminds me of a project I saw a while back that explored what the world would look like from the perspective of a 1D or 2D being. Someone actually built a interactive demo based on that exact premise.

edited, I found it: https://www.reddit.com/r/gamedev/comments/m19vl2/1d_game_pro...

Post reply on HN