scott wrote:

>> Right. So trace rays, let them bounce off diffuse surfaces at 
>> semi-random angles, and gradually total up the results for all rays?
> 
> Yes.

OK. Sounds simple enough...

>> Presumably that won't work with point-lights though? (You'd never hit 
>> any!)
> 
> Unless you start some rays from the point light to add into the mix (in 
> a physically correct way of course).

Well... presumably it still traces rays "backwards" from camera to 
source, right?

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

Post a reply to this message

Invisible a écrit :
> scott wrote:
>>
>> Unless you start some rays from the point light to add into the mix 
>> (in a physically correct way of course).
> 
> Well... presumably it still traces rays "backwards" from camera to 
> source, right?
> 

Not in every method. For example bi-directionnal path tracing, if I 
reckon correctly, creates random (but physically correct, of course) 
paths linking light to camera. So it works with point lights pretty well.

-- 
Vincent

Post a reply to this message

> 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, 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.

> How about something that can do metalic paint? That would be nice...

Have you seen the "car paint" demo from the ATI developer website?  That's 
pretty cool.

> 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...

>> NURBS are not isosurfaces though.
>
> Oh. Wait, you mean they're parametric surfaces then?

NURBS are just 2D equivalent of splines, basically one way to mathematically 
define a surface.  An isosurface defines a scalar field in 3D, and then a 
surface is constructed where the field equals zero.

> Does it add more triangles to the areas of greatest curvature and fewer to 
> the flat areas?

No, it just uses 32x32x32 marching cubes for each "block".  The block size 
depends on the distance from the camera.

> 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.

> 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.

> 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 :-)

> 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.  Like in POV you can draw the same mesh with very little 
extra memory, ditto for the GPU.  In fact you can even make subtle changes 
to each mesh as you draw it (eg colour, vertex displacement, animation 
cycles etc).  You can draw a field of trees and grass moving in the wind, 
with an army of 1000 men running over it with just a handful of meshes very 
quickly.  Nowhere in RAM or GPU RAM is the total triangle array held at any 
time.

Since DX10 you can now use the GPU to actually create geometry on the fly, 
so you are no longer limited to only modifying existing meshes.  For 
instance the CPU could provide a simplified mesh of a person, and a list of 
10000 points where the person should be drawn.  The GPU can then generate 
more detailed geometry when needed (if the mesh is near the camera), animate 
the mesh based on some walk cycle, change the colour of the clothes or 
whatever, and then render it.  It gives the impression of billions of 
polygons, but taking up a tiny amount of RAM.

Also big games tend to load in data from the disc in the background when you 
get near a different part of the level.  They also need to shuffle about 
things in the GPU memory as they go along.

Post a reply to this message

Mike Raiford wrote:

> Wouldn't you still need to tweak light sources to get the scene to look 
> "right"

BTW, I'm going to let my true fanboyism show.. Give me an unbiased 
renderer connected to POV SDL, and I'll surely be happy. Been browsing 
the galleries for the one, and I'm impressed, but I like my CSG!

Post a reply to this message

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

47bd77a2$1@news.povray.org...

> But then, as you know, most of my renders are pretty trivial. For example, 
> the image attached to the first post in this thread. I have no idea how 
> the hell it's possible to model something that complicated. Surely 
> something like that must take many months of modelling?

More likely a few hours. We're not in the early 90s anymore. Modelling apps 
have come a long way.
Now have a look at the images below for some state-of-the-art rendering.
http://thirdseventh.cgsociety.org/gallery/573528/
Note that this is done with VRay, which is not an unbiased renderer, but a 
"traditional" raytracer with GI and *** lots *** of improvements. 
http://www.cgarchitect.com/news/Reviews/Review007_1.asp

G.

-- 
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

>> But then, as you know, most of my renders are pretty trivial. For example, 
>> the image attached to the first post in this thread. I have no idea how 
>> the hell it's possible to model something that complicated. Surely 
>> something like that must take many months of modelling?
> 
> More likely a few hours. We're not in the early 90s anymore. Modelling apps 
> have come a long way.

People have moddeling apps now? Damn, I just type everything in as text...

[Only kidding!]

> Now have a look at the images below for some state-of-the-art rendering.
> http://thirdseventh.cgsociety.org/gallery/573528/

Sorry - due to my extremely lame monitor at work, most of these come out 
nearly black... :-(

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

Post a reply to this message

> Right. So trace rays, let them bounce off diffuse surfaces at
> semi-random angles, and gradually total up the results for all rays?

Basically yes. Although there are many ways to reduce the amount of rays needed
to achieve certain noise level without affecting "unbiasness". The point is
that the rays keep on going without stopping them artificially.

> Presumably that won't work with point-lights though? (You'd never hit any!)

There are no point light sources in real life. They always have some volume.
Even a small one. But as mentioned, there are methods to allow them and also
speed up rendering. Like bidirectional path tracing.

For the same reason path tracing works well for outdoor scenes. See image
section for an example.

Post a reply to this message

Severi Salminen wrote:
>> Right. So trace rays, let them bounce off diffuse surfaces at
>> semi-random angles, and gradually total up the results for all rays?
> 
> Basically yes. Although there are many ways to reduce the amount of rays needed
> to achieve certain noise level without affecting "unbiasness". The point is
> that the rays keep on going without stopping them artificially.

Right. Well presumably there must be *some* limit on the maximum 
recursion depth though?

>> Presumably that won't work with point-lights though? (You'd never hit any!)
> 
> There are no point light sources in real life. They always have some volume.

Yes indeed...

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

Post a reply to this message

On Thu, 21 Feb 2008 11:53:40 +0000, Stephen wrote:

> On 20 Feb 2008 15:09:52 -0500, Jim Henderson <nos### [at] nospamcom> wrote:
> 
> 
>>I've seen photos that don't look photorealistic to me.  It most
>>certainly is a matter of opinion.
> 
> As an aside is a black and white photograph, photorealistic, or a sepia
> one? Are the Pre-Raphaelites or chocolate box paintings?

You read my mind, Stephen. :-)

Jim

Post a reply to this message