 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I have implemented simple kd-tree support for my renderer ssRay and it
already rocks! See the image attached. Now I can finally use more
interesting models and render complex scenes without unbearable
performance hit.
Now the kd-tree is build with idiotic spatial median subdivision (ie.
simply divide each node in half). That is stupid and I'll implement a
surface area heuristic cost model next. That should improve performance
considerably. But still, all looks pretty good so far!
I love this path tracing stuff :D
ssRay homepage:
http://www.saunalahti.fi/~sevesalm/ssRay/ssRay.php
Post a reply to this message
Attachments:
Download 'kuva28.jpg' (36 KB)
Preview of image 'kuva28.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Severi Salminen <sev### [at] NOT THISsaunalahtifiinvalid> wrote:
> I have implemented simple kd-tree support for my renderer ssRay and it
> already rocks! See the image attached. Now I can finally use more
> interesting models and render complex scenes without unbearable
> performance hit.
It's snakes on a *** plane! I like it. Really, it's no small feat to get this
far. What's after kd-trees?
- Ricky
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I have implemented simple kd-tree support for my renderer ssRay and it
> already rocks! See the image attached. Now I can finally use more
> interesting models and render complex scenes without unbearable
> performance hit.
Wow that's really cool that you have done this all yourself so quickly, at
this rate you'll be ahead of POV in a few months :-)
> Now the kd-tree is build with idiotic spatial median subdivision (ie.
> simply divide each node in half). That is stupid and I'll implement a
> surface area heuristic cost model next. That should improve performance
> considerably. But still, all looks pretty good so far!
I guess the goal here is to have the minimum number of steps down the
kd-tree on average over all rays. My very naive instinct is that you should
split the nodes so there are equal numbers of triangles on each side, but
that's probably wrong if you don't take into account the size of each
triangle.
> I love this path tracing stuff :D
Yes if you have the time it can produce beautiful results, I have been using
MCPov almost exclusively recently for renders, I hope that path-tracing can
make it into official POV at some point.
BTW I have two questions about your tracer:
1) Multi-threaded, this can't be harder than running multiple instances at
once, but does it already utilise all cores or how hard will it be to
implement that?
2) How do you describe the scenes at the moment, are they all hard coded or
do you have some scripting system already?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
> Wow that's really cool that you have done this all yourself so quickly,
> at this rate you'll be ahead of POV in a few months :-)
:D Well, maybe not :) POV has a totally different approach to ray
tracing problem so it is hard to compare. With path tracing it is SOOOO
much easier to get many light related phenomena correct. With POV the
devs had to work hard to get the desired result as many phenomena are
separately implemented. With ssRay I don't have to shoot photons
separately to get caustics, I don't have to implement radiosity to get
global illumination and all related indirect effects etc. I get them for
free. Who doesn't like that :)
> I guess the goal here is to have the minimum number of steps down the
> kd-tree on average over all rays. My very naive instinct is that you
> should split the nodes so there are equal numbers of triangles on each
> side, but that's probably wrong if you don't take into account the size
> of each triangle.
That is intuitively a good solution but in reality it is a bad one :D
Actually you want to cut off big empty regions early. That makes tracing
and traversing the tree cheap. If you take "object median" as the split
point you get two expensive child nodes. That usually is not a good idea.
But there are some very good documents and books about kd-tree creation
so I don't have to re-invent the wheel completely.
Basically you assign a certain cost for ray-object intersection test.
And certain cost for traversing an interior node of the kd-tree. Then
you figure out all the possible splitting plane points (in all 3
directions) and use the cost model to minimize the kd-tree cost. The key
here is to use the surface area of a node to get a probability that a
random ray would actually go through that node.
There is also another very interesting acceleration structure called
BIH: bounding interval hierarchy. It looks quite simple and still very
efficient. I'll stick to ke-tree for now but will definitely try BIH at
some point.
> Yes if you have the time it can produce beautiful results, I have been
> using MCPov almost exclusively recently for renders, I hope that
> path-tracing can make it into official POV at some point.
I hope that too! Fidos has shown that POV can be turned to path tracer.
And POV has a very strong SDL and other infrastructure so it would be
nice to have alternative rendering engine for it.
I still think that most POV users prefer the most realistic outcome of
the renderings. And unbiased is the best way to go if that is the main
goal. I hope the devs will consider that with POV4.
> 1) Multi-threaded, this can't be harder than running multiple instances
> at once, but does it already utilise all cores or how hard will it be to
> implement that?
Yes, ssRay is already multithreaded and scales very well - basically
perfectly. I have 2 cores running at ~100% and ssRay handles as many
threads as the user wants. Now I assign different pixel rows for each
thread. That is actually a good approach. I don't need mutexes and the
load is still quite well balanced in almost all scenes.
> 2) How do you describe the scenes at the moment, are they all hard coded
> or do you have some scripting system already?
Hardcoded at the present. At some point I have to implement a parser but
that is not a fun thing to do and developing a good SDL takes time...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
triple_r wrote:
> It's snakes on a *** plane! I like it. Really, it's no small feat to get this
> far. What's after kd-trees?
Thanks!
Hmm. I really don't know where to start after the SAH cost model of
kd-tree is finished. Most likely I'll spend some time refining the code
and making it more polished etc.
But I'll have to think about the material interface a bit more. Now I
have simple reflections and refractions which are not physically correct
and look unrealistic. Real reflections are angle dependent. A glass ball
reflects more at low angle than when looking form surface normal
direction. This has to be implemented properly.
I want to have Fresnel (or some good approximation like Shlick's
approximation). We'll see :D
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> There is also another very interesting acceleration structure called
> BIH: bounding interval hierarchy. It looks quite simple and still very
> efficient. I'll stick to ke-tree for now but will definitely try BIH at
> some point.
BTW there is an interesting document I came across a while back that
involved working on sets of rays rather than just individual rays, might be
an interesting read.
ftp://download.intel.com/technology/computing/applications/download/mlrta.pdf
> I still think that most POV users prefer the most realistic outcome of
> the renderings.
Agreed, after all we're using raytracers because we prefer quality over
speed, as computers get faster it's only natural that we look for higher
quality methods to use.
> Now I assign different pixel rows for each
> thread. That is actually a good approach. I don't need mutexes and the
> load is still quite well balanced in almost all scenes.
Oh yeh I was going to ask about anti-aliasing, do you get this for free too
with your algorithm - or do you need to specifically jitter each primary ray
somehow?
> Hardcoded at the present. At some point I have to implement a parser but
> that is not a fun thing to do and developing a good SDL takes time...
Yes of course, always the boring bit getting the UI working well, much more
fun to work on the actual algorithm!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Severi Salminen wrote:
> I want to have Fresnel (or some good approximation like Shlick's
> approximation). We'll see :D
I want to see it do polarization. ;-)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> I want to see it do polarization. ;-)
NOOOOOOOOO! Anything but that :D At least I have wavelength dependent
rendering higher on the list to allow realistic dispersion. But it's not
THAT high on the list.
--
Severi Salminen
http://www.iki.fi/severi
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Severi Salminen wrote:
> NOOOOOOOOO! Anything but that
OK, fluorescence, then!
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Severi Salminen <sev### [at] NOTTHISsaunalahtifiinvalid> wrote:
> Hardcoded at the present. At some point I have to implement a parser but
> that is not a fun thing to do and developing a good SDL takes time...
I've always thought it would be neat to leave it as an API. POV-Ray's SDL is
already similar to C, but you'd also get the benefits of being able to use
numerical libraries, object-oriented programming, and of course, there's SPEED.
All without actually having to write or maintain a parser! The renderer would
just be a static or dynamic library. Of course you have to compile and link
over and over, but how bad is that, really?
#include <ssray.h>
int main( int argc, char** argv ) {
Scene s (argc, argv);
vec x (0.0, 0.0, 0.0);
vec dx (1.0, 0.0, 0.0);
Union u;
for( int i=0; i<100; i++) {
u.push(
sphere( x, 1.0,
pigment( Red )
)
);
x += dx;
)
s.push(u);
s.Render();
return 0;
}
Upon reflection, maybe the answer is, "Pretty bad." I think it's still the
approach I'd take since I don't actually know how to write a proper parser.
- Ricky
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Hardcoded at the present. At some point I have to implement a parser but
>> that is not a fun thing to do and developing a good SDL takes time...
>
> Yes of course, always the boring bit getting the UI working well, much
> more fun to work on the actual algorithm!
From where I'm sitting, building a parser is quite easy. Still,
designing the language it's supposed to parse is another matter -
depending on whether you want it to be Turing-complete. ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kd-trees are indeed quite handy. They are eg. used in 3D games in
certain situations where triangles need to be rendered in a certain order.
For example semi-transparent polygons have to be rendered from
farthest-from-the-camera to closest. This is because if you render them
in the wrong order, the result would not look correct (the blending of
overlapping polygons would be in the wrong order and thus the result
incorrect). Also the Z-buffer cannot be used for semi-transparent polygons.
(If you used the Z-buffer and you render the polygons in the wrong order,
some of the polygons would not be rendered at all, even though they should.)
So assume that you have, for example 10000 blades of grass, each one with
a semi-transparent texture, and thus you need to render then from farthest
to closest, regardless of where the camera is. How to do this?
You could, of course, try to sort the triangles at each frame. However,
not only would this be inefficient (after all, you only have about 16 ms
to do *everything* that is needed to render the next frame, and sorting
these polygons would certainly not be the only thing you have to do), but
there's a huge problem with trying to sort the triangles by depth: The
comparison function is far from trivial to implement. Determining which
of two triangles is in front of the other is a surprisingly complicated
task.
In fact, there is no comparison function to sort triangles by depth in
the general case. This might sound like a surprising result, but it indeed
is so. Three triangles may occlude cyclically each other, in which case
they don't have a well-defined order by depth. In other words, triangle A
may partially occlude triangle B, which partially occludes triangle C,
which partially occludes triangle A. In terms of comparison, you basically
have the situation where A < B and B < C and C < A, in which case these
three elements have no well-defined order.
With opaque triangles cyclical occlusion is not a problem because the
Z-buffer takes care of hidden surface removal on a per-pixel basis. However,
with semi-transparent triangles you can't use the Z-buffer (and get a
correct result).
The only way to render correctly cyclically-occluding triangles is
to split at least one of the triangles into two parts and render these
two parts separately (in the proper order compared to the other triangles).
However, you really don't want to start splitting triangles on the fly in
a real-time rendering engine.
It is possible to split triangles as a preprocessing step (even at the
level design stage) so that they can be ordered unambiguously. However,
using a sorting algorithm to sort the triangles at each frame is not
really something you want to do. Even if the triangles could be sorted
unambiguously by depth, the comparison is complicated and heavy, as well
as the entire sorting algorithm, which would be O(n log n).
Step in the kd-tree.
If you add all the semi-transparent triangles into a kd-tree, you will
be able to render the triangles from farthest to closest with a simple
O(n) traversal of the tree, regardless of where the camera is
with respect to the triangles. The comparison to be made at each node
is much simpler than the comparison which would need to be done for a
sorting algorithm.
And that's not all. When adding triangles to the kd-tree, it's trivial
to detect cyclical occlusion situations, and perform the necessary triangle
splitting, as a preprocessing step. After this has been done, no more splits
are ever necessary, and everything can be rendered in a depth order
regardless of where the camera is (using a simple linear traversal of the
kd-tree).
(Of course which triangles to split is not unambiguous, and algorithms
can be developed to minimize the number of triangles which need to be
split, but this is only related to the preprocessing. The rendering stays
the same.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Kd-trees are indeed quite handy. They are eg. used in 3D games in
> certain situations where triangles need to be rendered in a certain order.
>
> For example semi-transparent polygons have to be rendered from
> farthest-from-the-camera to closest.
Ah yes, the "painter's algorithm".
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.
> Step in the kd-tree.
>
> If you add all the semi-transparent triangles into a kd-tree, you will
> be able to render the triangles from farthest to closest with a simple
> O(n) traversal of the tree, regardless of where the camera is
> with respect to the triangles. The comparison to be made at each node
> is much simpler than the comparison which would need to be done for a
> sorting algorithm.
>
> And that's not all. When adding triangles to the kd-tree, it's trivial
> to detect cyclical occlusion situations, and perform the necessary triangle
> splitting, as a preprocessing step. After this has been done, no more splits
> are ever necessary, and everything can be rendered in a depth order
> regardless of where the camera is (using a simple linear traversal of the
> kd-tree).
Presumably if the triangles are allowed to move around you can't
precompute the splits?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> From where I'm sitting, building a parser is quite easy. Still,
> designing the language it's supposed to parse is another matter -
> depending on whether you want it to be Turing-complete. ;-)
Or one could use something like Lua or Tcl, which is specifically designed
for putting extensibility parsers into existing programs, and just implement
the bits you want and leave Tcl or Lua to do the subroutines, while loops,
GUI interactions, and so on.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
triple_r wrote:
> Of course you have to compile and link over and over, but how bad is that, really?
Nah. Just embed a decent language and invoke it. Tcl might be OK for this,
and I've heard good things about Lua. Python is hooked into a number of
programs I've seen, including Blender.
In Blender, you write your python code to invoke Blender objects and frob
around the internals how you like, then tell Blender "hey, here's your new
scene." Kind of like the way web languages have a "Request" object and a
"Response" object, and you (say) assign things to response.cookies to set
cookies at the browser.
REXX is another way to go - sort of like Windows COM only less Microsoft.
Or go with Windows COM or .NET if you're not worried about non-Windows machines.
> Upon reflection, maybe the answer is, "Pretty bad." I think it's still the
> approach I'd take since I don't actually know how to write a proper parser.
Use one someone already built for you, with the intention that you use it as
your parser.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
triple_r wrote:
> All without actually having to write or maintain a parser!
Or you could have a really simple parser, or something that takes XML (or
JSON or some other complex format for which there's already a standard and
parsers), and build up your objects from that. Then your scripts are
programs that output that. Just don't have any loops or variables or whatever.
I mean, it's not really hard to turn something like this into your library
calls:
1 union
2 pigment 1.0 0.0 0.0
3 sphere 0.0 0.0 0.0 2
4 sphere 1.0 0.0 0.0 2
5 sphere 2.0 0.0 0.0 2
...
push 1 3
push 1 4
push 1 5
...
Basically, each call to your library is just the name of the routine
followed by the arguments, and if the line starts with an integer, it's
declaring something to go in that slot, and you refer to the slots later
with numbers. Awful to parse by hand, but trivial to generate in a program,
or even a macro language or scripting language or whatever. Then you don't
have to worry about parsing much, and you can write a different library for
each language like you described that when you're done you say "output this
to a file and feed it to the renderer."
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Nah. Just embed a decent language and invoke it. Tcl might be OK for this,
> and I've heard good things about Lua. Python is hooked into a number of
> programs I've seen, including Blender.
Good advice. This is what happens, though, when people with no business
programming try to solve common problems. They reinvent the wheel, shape it
like a square, weld two tons of steel to it, and argue that, "Hey, it works."
> In Blender, you write your python code to invoke Blender objects and frob
> around the internals how you like, then tell Blender "hey, here's your new
> scene."
So with this method, do you have direct access via python to methods and
functions? That sure would be useful. I think I'll need to figure this out
for my soon-to-be-job anyway.
> Use one someone already built for you, with the intention that you use it as
> your parser.
Point taken. Thanks for straightening me out on the subject.
- Ricky
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
triple_r wrote:
> Good advice. This is what happens, though, when people with no business
> programming try to solve common problems. They reinvent the wheel, shape it
> like a square, weld two tons of steel to it, and argue that, "Hey, it works."
Yup.
> So with this method, do you have direct access via python to methods and
> functions? That sure would be useful. I think I'll need to figure this out
> for my soon-to-be-job anyway.
Yup. Decent blender tutorial that'll give you the idea how it looks when done:
http://jmsoler.free.fr/didacticiel/blender/tutor/python_script00_en.htm
(Follow that to the next page for an actual Python example script.)
Mind, this is the sort of thing Tcl was built for. Indeed, Tcl was up to
version 3 before you could run a program written entirely in Tcl. (I.e.,
version 3 was the first version of Tcl that came with main() :-)
Unfortunately, Tcl never really got the reference-semantics thing going, so
it's difficult to bolt useful OO constructs onto it. But it's pretty easy to
build your own OO style constructs that Tcl can invoke.
Blender is also open source, so you can peek and see how they integrated the
Python stuff.
>> Use one someone already built for you, with the intention that you use it as
>> your parser.
>
> Point taken. Thanks for straightening me out on the subject.
No problem. Just offering suggestions. Writing your own parser can be fun,
too, but there's way too much reinvent-the-wheel in this world. Why make
someone learn a new scripting language when you can say "use this, that you
already know"? :-) Indeed, the point of things like COM and .NET is "use
whatever you already know to run this, including scripts like WSH and
PowerShell."
There's also something called YAML (Yet Another Markup Language) which is
semantically identical to JSON but it's readable. You might want to peek at
that too, if JSON is sufficient. (JSON is basically maps and arrays of
strings and numbers, nested. I.e., data structures common to all the
scripting languages, but surprisingly flexible for a lot of stuff.)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> (Follow that to the next page for an actual Python example script.)
Oh, and if you notice, it's simple enough you can probably generate it
programmatically too. That is, if you wanted to use something other than
Python, you could probably have your Haskell program output Python script
that would brute-force its way though the construction of your stuff in a
very straightforward manner. So you're not losing anything by not having a
sophisticated scripting language, and it's probably not any harder than the
"trivial scripting language" example I made up.
The whole blender docs are rooted at blender.org. The manual is broken up
into pieces that makes it not *too* hard to find stuff, but makes a lot of
back references, so I'm not sure the "scripting" section would stand on its
own if you don't know the difference between (say) an Object and an ObData.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"triple_r" <nomail@nomail> wrote:
> So with this method, do you have direct access via python to methods and
> functions? That sure would be useful. I think I'll need to figure this out
> for my soon-to-be-job anyway.
(Don't worry though. I know you're thinking, "Wow, I hope they're not paying
him much," but the job has nothing to do with programming.)
- Ricky
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
triple_r wrote:
> "triple_r" <nomail@nomail> wrote:
>> So with this method, do you have direct access via python to methods and
>> functions? That sure would be useful. I think I'll need to figure this out
>> for my soon-to-be-job anyway.
>
> (Don't worry though. I know you're thinking, "Wow, I hope they're not paying
> him much," but the job has nothing to do with programming.)
Uh, no, I wasn't thinking that at all. I can't even imagine why you'd be
likely to have known how Python gets embedded in desktop programs even if
you *are* a professional programmer. :-)
Me, I've never started a job knowing what I need to know. :-) I'd say maybe
1 out of 5 jobs I take I wind up using a programming language I've used before.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
> Oh yeh I was going to ask about anti-aliasing, do you get this for free
> too with your algorithm - or do you need to specifically jitter each
> primary ray somehow?
Every ray from the camera goes through one single point. So yes, I have
to rotate each primary ray a bit to cover the area of a single pixel. So
basically I choose a random position within a pixel and trace that
direction. And because you normally do hundreds or thousands of passes
you end up getting perfect antialiasing.
--
Severi Salminen
http://www.iki.fi/severi
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
triple_r wrote:
> It's snakes on a *** plane!
augh >_<
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Severi Salminen <sev### [at] NOTTHISsaunalahtifiinvalid> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Severi Salminen <sev### [at] NOTTHISsaunalahtifiinvalid> wrote:
> Here is the latest version:
Holy Moly! Impressive stuff, really...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
