scott wrote:
>> So how does that affect the end visual result? Are we talking about a 
>> big difference or a subtle one?
> 
> A subtle one that makes materials look more realistic.  There's a 
> section in most 3D rendering books about it.

You must be reading different books to me... The last one I read spent 
several chapters discussing the various methods of performing hidden 
line removal, skipping over Z-buffering because it's "probitively 
expensive" except in "high-end scenarios". (AFAIK, it's the standard 
technique that all GPU rendering systems use today...)

> The one I remember has a 
> bronze vase, and repeatedly compares the different algorithms to a 
> photo.  It's surprising how tiny changes in the highlight can make you 
> believe it's really bronze or plastic or some unrealistic material.

Right. So we're talking about something so subtle that I'm unlikely to 
notice any difference...

>> LOL! I think POV-Ray probably beats the crap out of my ray tracer with 
>> just 1 sphere. ;-) But hell yeah, faster == better!
> 
> I meant compare the speeds relatively, like do 10^N spheres on your 
> tracer, and then on POV, and compare the curves.  POV doesn't simply 
> test each ray with every object during tracing...

Yeah, it uses bounding volumes and so forth. If you have enough 
geometry, I would think that starts to make a pretty big difference...

>> Even so, I would think that something like heavily textured rock would 
>> take an absurd number of triangles to capture every tiny crevice.
> 
> But it only needs to cover the ones you can see close up, and modern 
> graphics cards can render 10 billion vertices per second, so it should 
> be doable.

Damn, how do you even *store* 10 billion vertices?! o_O

>> And how do you avoid visible discontinuities as the LoD changes?
> 
> Alpha blend the old and new blocks (very old technique for LOD), apply 
> some bias to the isosurface function based on block size (this stops 
> "fighting" between the two surfaces during the transition).  The 
> transitions are so small in screen space that you don't notice them.

Mmm, OK.

This is one of the major annoyances with playing various Source-based 
games. When you move past a certain place, you see objects abruptly 
change LoD. It's really quite distracting. The human eye is very 
sensitive to movements like that...

>> I often look at a game like HL and wonder how it's even possible. I 
>> mean, you walk through the map for, like, 20 minutes before you get to 
>> the other end.
> 
> Try driving at 150mph for an hour before you get to the other end :-)

Presumably the map is in much lower detail in that case. ;-)

(Question: Is there a limit to how small a texture can be? Because in 
every game I've ever played, all the props seem to be textured at the 
same resolution as the game world. The result is signs on walls that are 
barely readable due to the low resolution...)

>> The total polygon count must be spine-tinglingly huge. And yet, even 
>> on a machine with only a few MB of RAM, it works. How can it store so 
>> much data at once? (Sure, on a more modern game, much of the detail is 
>> probably generated on the fly. But even so, maps are *big*...)
> 
> Mesh instancing.

Oh, OK.

How does that work with every room in the map being a completely 
different shape though? (Altough I guess most walls are flat, so...)

Also, how does it figure out which polygons to draw? It can't possibly 
draw all 10 million polygons every frame - and yet, figuring out which 
ones are visible would seem to take more effort than actually drawing 
them all...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message