Voxels?

[BladeJunker]

Actually, other than the original voxel demos like on the Amiga and Atari ST, most voxel demos used polgons for rendering. Modern voxel demos use OpenGL to draw the display. Magic Carpet 1 and 2 in the links looks like polygon renderer voxels.

The advantage of using polygons for rendering is it takes fewer rays to raycast, and most platforms can render polys faster than individual columns of pixels. Check out this article for a good look at (fairly modern) voxel rendering of backgrounds. Especially part 6.

http://www.flipcode.com/archives/Rea...oduction.shtml

Okay I guess that ties into its deforming reticulated spline action through its voxel underpinnings. Voxel, the term gets so muddled but I like the term Polygon Rendered Voxels, what do we call the non polygon stuff 2D Rendered Voxels, Sprite Rendered Voxels, Pixel Rendered Voxels?

[BladeJunker]

My understanding is 'Voxels' is not exactly a correct term to use with such old consoles as ours because it takes lots of horsepower to do true 'voxels'. And what we see on our old systems like Comanche or Fallen Angels is height mapping.

Yeah I know I'm not being 100% accurate, hard to keep it straight or make sure everyone understands the exact 'flavor' of voxel type representation or data structure employed on old systems. It's a paradox of definition unless you get really specific, say Voxel people think cubes like Minecraft or old school stuff with 2D square drawing but neither are really what a voxel actually is completely, probably better to avoid it as a blanket term. To tell you the truth I don't understand it completely either which is why Chilly is trying to educate me and others with that recent link.

[Chilly Willy]

The pixel artifacts weren't the real problem, the problem was that the VDP1 was slow as hell and transparent stuff took 3x as long to draw.
That, and it wasn't transparent compared to backgrounds. It was really half-assed.

No, it had EVERYTHING to do with pixel artifacts. The transparency worked fine if only one texture pixel mapped to one or more display pixels (same size or scaled larger). This has to do with how VDP1 actually draws the quads. It walks down two opposite edges, drawing a line between the two. This means that warped quads, and smaller quads overdraw quite a few pixels. Each overdraw of a pixel is done correctly as far as transparency goes, adding the texture pixel color to the background. But EVERY SINGLE OVERDRAWN PIXEL DOES THIS. More than a couple means the background color is reduced almost to nothing, while the texture pixels all add together with the last pixel color being the strongest.

Also, because transparency is read-modify-write, having overdrawn pixels means it's far slower than it should be. So warped or scaled down sprites take much longer to render than non-warped and scaled only larger. But I do agree, that is definitely half-assed.

My understanding is 'Voxels' is not exactly a correct term to use with such old consoles as ours because it takes lots of horsepower to do true 'voxels'. And what we see on our old systems like Comanche or Fallen Angels is height mapping.

Technically, voxels merely mean the source object to be drawn has a volume. That's all. When people said voxels originally, they meant that you used raycasting to read a height map. The height was turned into a column or box of pixels (the "voxel") that was rendered at the raycast location of the screen. Slightly later, the box of pixels were changed into a strip of triangles to render with a hardware accelerated 3D card. Even later, "voxel" became a bounding box at the raycast location in a storage tree than contained one or more 3D surfaces or objects in any format. Quad trees are popular for "voxel" renderers today, and the "voxel" may be a 3DS model or something.

So when we say "voxel" rendering here as concerns a SegaCD or 32X (any similar old console), we are STRICTLY referring to raycasting into a height map to generate a column or box of pixels. Period.

[alextheman]

The Genesis can do 3D equal to an SFX chip via the 68k. If you want to port a Model 1 game like Virtua Fighter (1), you're gonna need the SVP chip. The 32X is overkill for a simple game like that or Star Wars Arcade.

[Chilly Willy]

The Genesis can do 3D equal to an SFX chip via the 68k. If you want to port a Model 1 game like Virtua Fighter (1), you're gonna need the SVP chip. The 32X is overkill for a simple game like that or Star Wars Arcade.

Well, I wouldn't say overkill, but it's certainly up to the task as shown. Both ports were well done, and they're just first generation titles.

[sheath]

If the 32X is overkill for Star Wars Arcade, why is the Arcade version obviously higher detail? I suppose a ~10FPS SVP version might have sufficed, an actually play tested 32X version would have been better.



Start at 6:00


As much as I appreciate the 32X for what it is, I was always disappointed that such a seemingly simple game like Star Wars Arcade didn't turn out as well as it possibly could have.

[Chilly Willy]

The arcade version was higher detail for a few reasons: first, it ran in a higher resolution, so it NEEDED more detail. At 496x384, it has more than two and half times as many pixels. At 320x224, more detail would just be lost in the smaller polygons. Second, higher detail models need more rom space. Home video games ALWAYS cut detail to save on rom costs. Many games could have been far better if the company had been willing to pay for a bigger rom. One of the biggest examples was the original A2600 PacMan. And finally, the arcade version ran on the model 1. If you aren't familiar with it, here's a spec sheet:

Main CPU: 32bits RISC NEC V60 uPD-70616 @ 16 MHz (2.5 MIPS)
Graphics Co-Processor: Fujitsu TGP MB86233 FPU 32bits 16M flops

Sound CPU: 68000 @ 12Mhz
Sound chip: 2 x Sega MultiPCM Custom 28 channel PCM chips @ 8 MHz, 1 for Music and 1 for Effects. Each can access up to 8meg sample rom *per chip*
Sound Timing Chip: YM3834 @ 8MHz (only used for its timers)

Co-Processor Abilities: Floating decimal point operation function, Axis rotation operation function, 3D matrix operation function
Geometry: 180,000 polygons/sec, 540,000 vectors/sec
Rendering: 1,200,000 pixels/sec
Video: Shading Flat Shading, Diffuse Reflection, Specula Reflection, 2 Layers of Background Scrolling, Alpha Channel
Video resolution: 496x384 in 65536 colors.

The 32X has plenty of CPU power - more than the model 1 (lower on the slower 68000, but the SH2s were much higher than the V60s). What it lacked was that graphics coprocessor. The higher power in the SH2s barely allowed it to come close to the speed the model 1 achieved with its graphics coprocessor. While those poly figures in the spec sheet are probably optimistic, it's still far beyond what the 32X was rated at. So models also needed to be simplified to allow for the missing coprocessor.

[sheath]

Model 1 has no texture mapping ability too, right?

I've mused a couple of times that the 32X targeted Model 1 and Super Scaler adaptations while the Saturn targeted Model 2 adaptations. Obviously ROM size and RAM limitations were always going to mean cuts, not to mention the 32X's hard limit to 320x224. If all the 32X version of Star Wars Arcade was missing was a few boxes on walls and surface detail on Star Destroyers I would have been much happier with it. What really ended up killing the game for me was the Audio, tie fighters flying through the Death Star's surface and the brutal time limit artificially raising the difficulty. Star Wars Arcade continues to be one of those games I just wish I could enjoy for what it is, but it drives me nuts. I always end up playing Rebel Assault instead.

All that said, the Super Star Destroyer at 2:07 and 16:00 in the Model 1 and 32X videos respectively always makes me want to give Star Wars Arcade 32X another chance.

[Chilly Willy]

Yeah, the Model 1 just does flat or shaded colored polys. No texture mapping. The 32X should be fastest at flat colored polys, shaded should be a little slower, texture mapped a little slower than that, and shaded textured polys the slowest. Plain flat colored polys can use the SuprVDP fill hardware to render the raster line at the faster rate than the CPU is capable of. The fill hardware can store data to the frame buffer at 3 cycles per word. That data is a single word, however, so you're pretty limited - flat unshaded polys. When storing data to the frame buffer with the SH2, the best write speed is 3 cycles per word, but only until the frame buffer write FIFO fills, then it's 5 cycles per word. The FIFO is only a couple words, so you can count on most writes in a tight loop being 5 cycles.

[BladeJunker]

Yeah, the Model 1 just does flat or shaded colored polys. No texture mapping. The 32X should be fastest at flat colored polys, shaded should be a little slower, texture mapped a little slower than that, and shaded textured polys the slowest. Plain flat colored polys can use the SuprVDP fill hardware to render the raster line at the faster rate than the CPU is capable of. The fill hardware can store data to the frame buffer at 3 cycles per word. That data is a single word, however, so you're pretty limited - flat unshaded polys. When storing data to the frame buffer with the SH2, the best write speed is 3 cycles per word, but only until the frame buffer write FIFO fills, then it's 5 cycles per word. The FIFO is only a couple words, so you can count on most writes in a tight loop being 5 cycles.

Do you think Big Red Racing could work on 32X, it's sort of in that vein of flat shading, gouraud shading, and texture mapping at the same time?
http://www.mobygames.com/game/big-re...ng/screenshots

[Chilly Willy]

Do you think Big Red Racing could work on 32X, it's sort of in that vein of flat shading, gouraud shading, and texture mapping at the same time?
http://www.mobygames.com/game/big-re...ng/screenshots

Maybe a little lower detail (fewer polys) on some of the vehicles, but otherwise it looks like something the 32X can handle.

[j_factor]

But could the 32x handle Battlesphere?

[Chilly Willy]

But could the 32x handle Battlesphere?

Probably. Maybe not quite as good as the Jaguar version, especially since the Jag version looks like it runs in a higher resolution. The 32X is kinda stuck with 320x224.

[BladeJunker]

Guess I should have asked this, does the Genesis or Sega CD actually render 2D voxels(squares/tiles) well and or faster than flat shaded polygons? It doesn't share the same issues that prevented the Amiga from doing 3D well?

Curious about what kind of texture quality one could expect on this platform as the Alex Champandard post in the later part mostly goes into some beefy hardware options?

Do most people use 2 layers when rendering 3D on these platforms or just one?

So basically regardless of what you use to render the graphics a voxel engine runs fastest with the most bumpy ground possible and flatness kills its benefits? Guessing that's where a mixture of polygons or 2D planes for flat spots and 2D voxels for hills would come into play?

Is it impossible to increase the view frustrum or will it just perform badly, like you need to cheat some rendering on Sega CD for adequate performance but less so with the 32X?

So a heightmap is the only efficient way to render voxels given the limits, do you think a height/cube map could describe a full object model IE. teapot?

[Chilly Willy]

Guess I should have asked this, does the Genesis or Sega CD actually render 2D voxels(squares/tiles) well and or faster than flat shaded polygons? It doesn't share the same issues that prevented the Amiga from doing 3D well?

The Genesis is okay at rendering columns IF they're a byte or word wide. Trying to render a single column means inserting nibbles in a byte, which will take a lot of time. Look at the MD version of Wolf3D gasega68k has been working on as an example - he draws the columns as bytes, partly for speed, and partly as a pair of pixels that simulates more colors. This could be done for voxels as well. The ASIC in the SCD could be used for drawing columns of various widths. That would probably speed things up quite a bit.

Curious about what kind of texture quality one could expect on this platform as the Alex Champandard post in the later part mostly goes into some beefy hardware options?

Not sure what you mean here - what textures? What platform? Be more specific.

Do most people use 2 layers when rendering 3D on these platforms or just one?

Most raycast games use a 2D far plane for a background. Wolf3D simply fills the far plane with a floor and ceiling color. Doom only fills the far plane where it isn't covered by the foreground. If you have a separate layer for the far background, it might speed things up to put it in the other layer. For example, put the background on the MD side for Doom.

So basically regardless of what you use to render the graphics a voxel engine runs fastest with the most bumpy ground possible and flatness kills its benefits? Guessing that's where a mixture of polygons or 2D planes for flat spots and 2D voxels for hills would come into play?

Pretty much. When doing voxels, you get the best speed if the height map has hills that block the view behind them. The lower the foreground, the further you have to raycast into the height map. Looking up a smooth incline would be the slowest as your columns would only be one pixel tall requiring carrying on the raycast for a single ray for every single vertical pixel.

Is it impossible to increase the view frustrum or will it just perform badly, like you need to cheat some rendering on Sega CD for adequate performance but less so with the 32X?

It will ALWAYS be a problem. Even the N64 had horrible pop-up on many games. Even modern PCs with quad-core multi-GHz processors and dual video cards often show horrible pop-up on games. If you've ever played with the settings on Skyrim, you know that the rendering engine has certain distances you set that tell when to start/stop rendering objects, and distances at which to switch back/forth from/to different models with different levels of detail. Low detail polys for farther away, and higher detail for closer.

So a heightmap is the only efficient way to render voxels given the limits, do you think a height/cube map could describe a full object model IE. teapot?

I think you'd probably be better to have special codes in the height map that signaled an object rather than the height. You'd look that object up in a table/list, and it would reference sprites or poly models (sprites for speed on lower systems). Maybe a separate map from the height map to avoid needing special codes. You look at the height map for the ground, and the other map for any objects.