![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> Incidentally, while playing CSS the game engine appears to very
> occasionally get this wrong. (I.e., distant objects appear *in front* of
> nearer ones - typically textures for things like explosions, window glass,
> etc.) The result looks very weird.
That's because the depth buffer has limited precision (16 or 24 bit
usually). If you can, check that it is set to the highest setting your
display driver allows.
The video driver has to map real depths (floating point distances from the
camera) to an integer to store in the depth buffer. It usually does this by
taking the reciprocal of the depth, and mapping a range like 1/1000 to 1/0.1
to the integer range 0-65535 linearly. This would mean that integer 0
corresponds to 1000 metres, and integer 65535 corresponds to 0.1 metre
depth. In this case, integer 1 would correspond to 868 metres depth, so you
can see there isn't much resolution far away!
Obviously the bigger range of distances teh game engine needs to represent,
the less accuracy you can store the depth with and the more depth buffer
problems you get. And of course using a 24bit buffer helps things.
> Presumably if the triangles are allowed to move around you can't
> precompute the splits?
I wouldn't have thought so, and given that grass blades are probably moving
in the wind I don't think you woudl bother. I mean if you 10000 grass
blades swaying in the wind, are you going to notice the odd few that have
sections rendered in the wrong order and thus have slightly incorrect
shading?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
scott wrote:
> Obviously the bigger range of distances teh game engine needs to
> represent, the less accuracy you can store the depth with and the more
> depth buffer problems you get. And of course using a 24bit buffer helps
> things.
I think that was one of the things the Serious Sam engine was trying to show
off. There were levels where you'd look across the level with the 10x sniper
scope and at the halfway mark was a five-story monstrosity you could barely
make out. That and literally hundreds of monsters all attacking at once,
of course.
--
Darren New, San Diego CA, USA (PST)
"Ouch ouch ouch!"
"What's wrong? Noodles too hot?"
"No, I have Chopstick Tunnel Syndrome."
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> Incidentally, while playing CSS the game engine appears to very
>> occasionally get this wrong. (I.e., distant objects appear *in front*
>> of nearer ones - typically textures for things like explosions, window
>> glass, etc.) The result looks very weird.
>
> That's because the depth buffer has limited precision (16 or 24 bit
> usually). If you can, check that it is set to the highest setting your
> display driver allows.
I noticed with Crysis that really distant objects "sparkle" like there's
a coincident surface glitch. I suspect that what's really happening is
limited Z-buffer precision.
The glitch I'm tolding about happens on a custom level at distances of
only a few feet, so I suspect the level author set some flag wrong or
seomthing.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> I noticed with Crysis that really distant objects "sparkle" like there's a
> coincident surface glitch. I suspect that what's really happening is
> limited Z-buffer precision.
Exactly. Even with 24bit precision, when that's spread over viewing
distances between 10cm and 10km you still get problems with far away objects
being drawn correctly.
> The glitch I'm tolding about happens on a custom level at distances of
> only a few feet, so I suspect the level author set some flag wrong or
> seomthing.
More likely he just put two surfaces on the same plane somehow (with
different textures). Of course if the points are in exactly the same place,
it's just going to be down to floating point precision and rounding errors
as to which one gets drawn in front for each pixel. Usually if you really
do want two surfaces at the same point (eg a poster on a wall) you apply a
"z buffer bias" to ensure one always gets drawn on top of the other even
though the geometry is in the same place and even when the z buffer
precision is low (eg far away).
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Me really likes kd-trees!
This scene has 6*40000 boxes and rendered in just 30 minutes - the image
is not very grainy anymore. I'm quite happy with the results so far!
But still, so many things to implement and only so much spare time :D
--
Severi Salminen
http://www.iki.fi/severi
Post a reply to this message
Attachments:
Download 'kuva29.jpg' (93 KB)
Preview of image 'kuva29.jpg'
![kuva29.jpg](/povray.off-topic/attachment/%3C499c3164%40news.povray.org%3E/kuva29.jpg?preview=1)
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Small update:
--
Severi Salminen
http://www.iki.fi/severi
Post a reply to this message
Attachments:
Download 'kuva29.jpg' (99 KB)
Preview of image 'kuva29.jpg'
![kuva29.jpg](/povray.off-topic/attachment/%3C499c4373%40news.povray.org%3E/kuva29.jpg?preview=1)
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
triple_r wrote:
> It's snakes on a *** plane!
augh >_<
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Severi Salminen <sev### [at] NOT THISsaunalahti fi invalid> wrote:
> Me really likes kd-trees!
>
> This scene has 6*40000 boxes and rendered in just 30 minutes - the image
> is not very grainy anymore. I'm quite happy with the results so far!
holy friggin cow!
Where did you get a spare Pixar render farm? o_O
The AA is PPP (pretty pixel perfect), the amount of stuff shown is staggering
and it's not that grainy indeed!
I hope it gets a python, TCL or Lua interface indeed. :)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
nemesis wrote:
> Where did you get a spare Pixar render farm? o_O
Hah :D But witk kd-trees this kind of scene is very easy to render.
Adding more buildings/detail affects the render speed only by very small
margin.
Here is the latest version:
--
Severi Salminen
http://www.iki.fi/severi
Post a reply to this message
Attachments:
Download 'kuva30.jpg' (99 KB)
Preview of image 'kuva30.jpg'
![kuva30.jpg](/povray.off-topic/attachment/%3C499fe96a%40news.povray.org%3E/kuva30.jpg?preview=1)
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Severi Salminen <sev### [at] NOT THISsaunalahti fi invalid> wrote:
> Here is the latest version:
Holy Moly! Impressive stuff, really...
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |