How much appearance of the 3D accelerators changed 3D on the PC?

File: tmp_32011-Naamloos-2-2114611398.png (138KB, 350x350px) Image search: [Google]

138KB, 350x350px

Pretty much

>>2905890
It made it a thing worth doing, what more is there to say?
3DFX Glide was the fucken shit. I swear nothing will look that good ever again.

>>2905890
To answer your question: yes.

>>2905890
They took it from shit like AITD to shit like Quake in one generation.

How did games look on 3D cards vs. software rendering?

File: quake2renderingcomparison1.jpg (41KB, 524x200px) Image search: [Google]

41KB, 524x200px

>>2906528
3DFX GLIDE, MOTHERFUCKER

>>2906513
Quake had a software renderer as well. There were 4 years between AITD and Quake

File: renderer.gif (695KB, 900x675px) Image search: [Google]

695KB, 900x675px

>>2906528
Eh, this one doesn't showcase it as well but.

File: 1406253736842.jpg (523KB, 2048x768px) Image search: [Google]

523KB, 2048x768px

>>2906528

File: Quake2_opengl.jpg (440KB, 1280x480px) Image search: [Google]

440KB, 1280x480px

>>2906528
One more! I hope this has been educational.

>>2905890
The introduction of the 3D accelerator had various effects, good and bad.
By design, these accelerators supported textured polygonal 3D engines. For them not much changed initially though. Games with accelerator support had a higher display resolution, better framerate, higher bit depth and often bilinear filtered textures; that's all obviously good effects. The models and textures though, were largely unchanged. A primary reason is that 3D accelerators were still largely optional, and any game data had to work in software mode as well. The various comparison shots of Quake 2 in this are a good example. For the next couple months, maybe years, 3D accelerators actually slowed down development a bit. The fixed pipeline put a hard limit on texture sizes, polygon counts and available effects. During that time, software engines like in Outcast successfully competed against 3D accelerator output. While they couldn't offer the same framerate or resolution, they could offer a vast variety of shading and post processing effects, and, thanks to voxel rendering, landscape details that were entirely out of reach for accelerators.
That brings us also to one of the negative effects that 3D accelerators had: they killed all non-polygonal engines. Up to that point you had line scrollers, raycasters, voxel engines, all kinds of mix. The accelerator hardware only worked for textured polygons though. Only recently has voxel development picked up again, because shader programs allow to recreate these effects, and take advantage of parallel code.
Nowaways, the existence of accelerator hardware led to a largely standardized form of rasterizing. Everyone's doing the same straight forward approaches, because that's what the hardware can do. Things are changing up a bit, due to shaders gaining so much traction, that it's viable to bypass most of the T&L stuff, or keep it simple, and do the majority of the output work in parallel in the shaders.

Most of the Quake 2 OpenGL screenshots in this thread have this orange tint. The reason is simply that OpenGL allowed colored light sources, and the game's style is by design dominated by orange. It's not that colored lights were impossible for software rendering, there's no such limit. It's simply that accelerators had higher bit depth, and allowed devs to change more than just the brightness of a light source, to actually put more colors on the screen. It's probably also a reason why stuff like Unreal (Tournament) is super colorful.

>>2905890
Just run a 3D game on dosbox in software mode and see for yourself.

appearance? You mean Quake? That game was the catalyst for the obsessive innovation of 3d hardware. I really dont think it would have been the same without the need to make that game run smoother really.

>>2906648
Back then, some graphics card manufacturers released "minigl" drivers, which supported only the minimum features of OpenGL needed to run Quake.

>>2906648
Quake did not start some kind of revolution. Polygonal 3D rendering has been alive and kicking long before it. Descent, for example, is 2 years older (and supports a variety of VR hardware). Tomb Raider was released in the same year as Quake, its development definitely did not start after Quake's release.

There has been no "obsessive innovation". The first couple accelerator generations just helped a bit with rasterizing and the priority was on throughput.

>>2906667
>Polygonal 3D rendering
I should probabily clarify to textured polygonal 3D rendering. Polygonal 3D rendering, especially flat shaded, had been done for at least a decade already.

>>2906667
Descent and Tomb Raider both supported only distorted cubes. Quake was the first to support arbitrary polygons. Quake levels had much more interesting design because the engine was so much more flexible. Quake also had much better lighting, with realistic (static) shadows. Quake was as big a step forward as Doom.

>>2906673
The Descent engine used connected cubes as its structure, primarily to efficiently model portals. The cubes can and do have arbitrary distortions, and the final levels in Descent are everything but cubic in nature, with twisting tunnels and complex rooms. The robots in Descent are not modelled from cubes at all. The rasterizer itself is not aware of the cubes, it's dealing with triangular primitives.

Similar in Tomb Raider. The level structure is a grid of primitives, which makes visibility computations trivial. Lara herself, and many objects in the environment, are not subject to this cube structure. The rasterizer itself is not aware of the cubes, it's dealing with triangular primitives.

If you are hung up on cubes, I could also add in Screamer, a racing game, with very smooth tracks and complex polygonal surroundings. Its mechanism to simplify visibility checks is that the track is technically a "tube".

Visibility checks are a huge deal, as they allow to discard large parts of the environment before the expensive rasterizing.

Quake has as a big engine feature the ability to use arbitrary shapes to model the levels. A preprocessor would create the BSP and all necessary data for efficient visibility computations. That difference was largely for the developer, not the computer.

Descent had a dynamic lighting model, but of course not as complex as Quake, given that it's two years older. The biggest achievements for Quake were just in the complexity of the visuals, and the tools.

My point is that Quake did not jumpstart textured polygonal rendering. It's been alive and well, used in a variety of ways.

>>2906547
Doesn't look that different outside of the hue. I guess this kind of thing needs a video.

>>2906724
better framerate, colored lighting (especially visible in >>2906537 ), bilinear filtered textures. The accelerated pic has not been tinted or hue changed. It's just using orange light sources, while the software renderer is stuck with white light sources.

>>2906673
>Quake was as big a step forward as Doom.
Doom in comparison to Ultima Underworld?

>>2906734
very true. In the defense of Doom, it beat Underworld in terms of pace and viewport size. Also, similarly to Quake, the real strength of Doom is not necessarily in the engine during playback, but in the tools during creation. To this day Doom is popular, in part because the data structures for the level data are so accessible during editing, it's fairly fast and straightforward to build levels, which is kind of important if you want to license your engine.