Yay: 2148 MTris ~= 2.1 Giga Triangles

(L) [2008/09/23] [greenhybrid] [ Yay: 2148 MTris ~= 2.1 Giga Triangles] Wayback!

the full news item can be found here: [LINK http://picogen.org/news/2008/09/23/2008-09-23-quadtree-enhanced.php]
the description on the picogen-site is not very technical (well, picogen.org is meant to be a kind of user-site; maybe I'll write a short paper on how to render such large datasets when my ray tracer is fast enough to pathtrace the below scenes (images have been rendered in Whitted-Style)). the biggest piece of tec is the use of the huge_array-class ([LINK http://ompf.org/forum/viewtopic.php?f=8&t=999&p=9928#p9928 viewtopic.php?f=8&t=999&p=9928#p9928]), without which the rendition of those 32769^2-Height-Slang-maps would not have been possible on my lame 32bit box without sacrifiing the array-based implementation. The quadtree (64byte nodes) takes up to 21GiB in size, where each node is self-contained in that it stores it's own height-vals, plus the index of it's children. This layout will help we with LODs and fast (low-detail) previews of pre-computed terrain.
pls click on the images for fullsize (2480*1280, 2x2 supersampled, Whitted-Style)
[IMG #1 Image]
[IMG #2 Image]
[IMG #3 Image]

thanks for watching by [SMILEY :D]

[IMG #1]:

[IMG #2]:

[IMG #3]:

(L) [2008/09/23] [greenhybrid] [ Yay: 2148 MTris ~= 2.1 Giga Triangles] Wayback!

Thanks, Brother Jogshy [SMILEY :)]
>> tone map
none ... meh.
I used to use the one Hugo Elias describes, but it failed in some situations. Yes, I really need tonemapping.
... and I need to get rid of the bug that causes those rectangular artifacts on the lower right portion of the Orodruin-image.
Btw, no Interpolated Normals have been used in all of the renditions, everything is as The Veach recommends (surface normals only). But then I really *should* use them when rendering Whitted-Style ...

(L) [2008/09/24] [tarlack] [ Yay: 2148 MTris ~= 2.1 Giga Triangles] Wayback!

you could use his advices to minimize shading normals influence on the mathematical results, they are quite easy to take into account if you are ready to give up the nice BSDF symmetry in your code, and thus actually say in which way the BSDF is sampled (direct or adjoint)

(L) [2008/09/24] [greenhybrid] [ Yay: 2148 MTris ~= 2.1 Giga Triangles] Wayback!

I think I should really re-read the relevant chapter, yes. Probably the impact isn't too bad as I have no plans currently to implement bi-directional techniques.
I also have another (vague) plan of an specialized hypertexture, or a kind of tiling/repeating microterrain on the macroterrain, where I think that even 1024^2 heightmaps can give stunning results (and maybe hide away the "flat-shading-artifacts" (I know it's not really flat-shading:P)).

(L) [2008/09/26] [greenhybrid] [ Yay: 2148 MTris ~= 2.1 Giga Triangles] Wayback!

>> jogshy wrote:And which method are you using for drawing the sky? A bitmapped sky dome? Looks like a full sky scattering integration!
The usual Preetham one, though I am thinking about implementing more models: Preetham is actually not too correct for turbidities <2 or >10 ([LINK http://wscg.zcu.cz/WSCG2007/Papers_2007/short/E59-full.pdf]), and from time to time I have the feeling my code/the results are not correct, and it doesn't help much that there are two Yxy-RGB conversion routines around the net. I will start a thread on the latter.
Other models I'd like to have:
* Nishita (I like the evening sky)
* HDR-Cubemap
* HDR-Environment-Map (because there are some free resources in the net)
picogen's skies are currently pure directional, not taking into account the ray-position.

(L) [2008/09/27] [phresnel] [ Yay: 2148 MTris ~= 2.1 Giga Triangles] Wayback!

I love how you say 'pls' [SMILEY :)]
Unfortunately I have never digged in any more filtering than (bi)linear, cosine or cubic for when you have to magify something. At least for those you find some pseudo code on [LINK http://freespace.virgin.net/hugo.elias/models/m_perlin.htm] . the book [LINK http://pbrt.org/] has good instructions (I have a copy of that book, but didn't find much time to read it yet, so I can't tell more).

(L) [2008/09/27] [beason] [ Yay: 2148 MTris ~= 2.1 Giga Triangles] Wayback!

Can you just treat the cube map edges as not being edges? That is, treat the cube map as an infinite texture, using logic to wrap pixel coordinates to adjacent faces.
For example, whatever you do to blend pixels 0 and 1,
do the same thing for -1 and 0. -1 will not be on the current cube face, but on the adjacent face. They should be the same resolution, so just give it the same treatment. In the corners you may have to access 3 faces.

(L) [2008/09/28] [phresnel] [ Yay: 2148 MTris ~= 2.1 Giga Triangles] Wayback!

I am not sure. I have a cubemap implementation for picogen (with zbuffer, normals, color, and i want to store material information later) which I want to use for dense weather-fx like fog, rain, snow, etc.
The way I calculate is the canonical one: biggest scalar in direction-vector gives the face, the remaining scalar divided by the biggest one give the uv. ([LINK http://cvs.savannah.gnu.org/viewvc/picogen/quantum/src/picosrc/graphics/objects/ZBNCubemap.cc?root=picogen&view=markup])
(edit: i see i have written "pos" instead of "direction", which would make more sense)
Code: [LINK # Select all]void ZBNCubemap::getCubeCoords (face_t &face, real &u, real &v, const Vector3d &pos) {
static const face_t lut[3][2] = {
{ x_negative, x_positive, },
{ y_negative, y_positive, },
{ z_negative, z_positive, },
};
int index = 0;
real max = fabs (pos[0]);
if (fabs (pos[1]) > max) {
index = 1;
max = fabs (pos[1]);
}
if (fabs (pos[2]) > max) {
index = 2;
max = fabs (pos[2]);
}
face = (pos[index]<0) ? lut[index][0] : lut[index][1];
switch (face) {
case x_negative:
u = pos[2] / -pos[0];
v = pos[1] / -pos[0];
break;
case x_positive:
u = -pos[2] / pos[0];
v = pos[1] / pos[0];
break;
case y_negative:
u = pos[0] / -pos[1];
v = pos[2] / -pos[1];
break;
case y_positive:
u = pos[0] / pos[1];
v = -pos[2] / pos[1];
break;
case z_negative:
u = -pos[0] / -pos[2];
v = pos[1] / -pos[2];
break;
case z_positive:
u = pos[0] / pos[2];
v = pos[1] / pos[2];
break;
};
// [-1..1] >>> [0..1]
u = u*0.5+0.5;
v = v*0.5+0.5;
}

(L) [2008/09/28] [madd] [ Yay: 2148 MTris ~= 2.1 Giga Triangles] Wayback!

If you're lazy you could embed the unfolded cube map cross in a single texture. Then you would only have to handle wrapping at the borders like with normal textures. Of course embedding wastes a bit of memory.. You could also convert to lat-long format or similar.

Yay: 2148 MTris ~= 2.1 Giga Triangles back

Board: Board index ‹ Ray tracing ‹ Visuals