Shop Mobile More Submit  Join Login
An alpine landscape. by greenhybrid An alpine landscape. by greenhybrid
This one will be part of an example set packed in the next release of picogen-wx (I have it ready to be uploaded on my harddisk, both for windows and gnu/linux, but it'd be better with examples, I thought :))

Pure Render Time: 8 minutes
Preparation time (building quadtree etc.): way tooo long (an hour? dunno remember exactly)

For the curious regarding picogen, please visit my gallery and [link] or the new wikipedia page at [link] .

Thanks for watching!
Add a Comment:
 
:iconbeason:
beason Featured By Owner Dec 29, 2008
Are you using a constant ambient term for indirect lighting? I assumed you were doing path tracing but that 20k rays/sec figure works out to something like 5 rays/pixel so that can't be right.

Maybe this is too much technical discussion? :)

I love your sky. Are you hand picking the colors or is it straight Preetham? If the former, nice choice(s) :)
Reply
:icongreenhybrid:
greenhybrid Featured By Owner Dec 30, 2008
Discussions always welcome!

picogen supports brute force monodir path tracing, but these newer images are actually whitted-ray-traced, for the bless of speed that ppl like. I sometimes compare the results of both integrators, and if you look on the picogen-todo-list, you will see that the work on the whitted-integrator isn't over; I want to approximate it as much to the path tracer result.

I am not using a constant ambient term, but rather, at the point of intersection, I peek into the hemisphere (i.e. in the direction of the surfacenormal), to see what preetham offers me.

In the next versions, somewhen, I will use a blurred version of preetham (by sampling the hemisphere for each normal in R^3) (into a lookup table of course), because at some points the artifacts are visible. A bigger challenge will be to ambient-occlude the points, but from the pure color-standpoint, I think my approach is promising.

I think the last manual color picking was 2 yrs ago or so :), *looking up* in "Glossy Spheres on Noisy Ground", at [link] :D
Reply
:iconkram1032:
kram1032 Featured By Owner Dec 28, 2008
from wikipedia:
"pronounced picogen"
well, "c" is inaccurate on its own....
is it pronounced "k" or "z" ?
Reply
:icongreenhybrid:
greenhybrid Featured By Owner Dec 29, 2008
oh, erm, k. i guess. but i'll ask the picogen-crew :S
Reply
:iconkram1032:
kram1032 Featured By Owner Dec 29, 2008
xD yeah, I thought so^^

"g" is also inaccurate... generation or genesis g? :P

as it *seems* to be English-ish, it's probably generation, though^^
But I always imagine the Genesis-g xD

else, it should be accurate ^^
Reply
:icongreenhybrid:
greenhybrid Featured By Owner Dec 30, 2008
:D
though I don't see the difference in genesis-g and generation-g, aren't they both spelled something like "D'Sh" ... :o hmmm
Reply
:iconkram1032:
kram1032 Featured By Owner Dec 30, 2008
oh? xD I'd have pronounced Genesis-g more like, wait... THAT'S the word xD gay...
Reply
:iconkram1032:
kram1032 Featured By Owner Dec 28, 2008
8 looks perfectly fine to me. I'd say, it's "normal" xD
great shaders :D
Reply
:icongreenhybrid:
greenhybrid Featured By Owner Dec 29, 2008
thx,

the shaders are really easy: f=some_perlin, then color=f*superwhite + (1-f)*gray
Reply
:iconkram1032:
kram1032 Featured By Owner Dec 29, 2008
so, a linear blend between 2.0 and 0.5 gray, with the blendfactor, given by perlin noise :)
you might want to make sharper blends ;)
try bicosine or bicubic :)
Reply
:icongreenhybrid:
greenhybrid Featured By Owner Dec 30, 2008
ah yes, that reminds me of the mission where you could tweak the interpolator :]
Reply
:iconkram1032:
kram1032 Featured By Owner Dec 30, 2008
yeah :D
Reply
:iconbeason:
beason Featured By Owner Dec 27, 2008
Beautiful!

Funny lyc said it was slow. I was going to say that was fast :/
Reply
:iconlyc:
lyc Featured By Owner Mar 27, 2009
i should have better qualified that statement, the building stage seemed kinda slow for the amount of data visible; the rendering itself is pretty quick at just 8 minutes on seb's machine :D
Reply
:icongreenhybrid:
greenhybrid Featured By Owner Dec 29, 2008
Thanks Kevin!

Hmm now I am confused ... If I am right, than those images have been traced at around 20k rays per second, whish is really not that fast, but then I think 8 minutes is okay at the moment, for such resolution with 2x2 anti-aliasing + simple shaders (which itself includes a Perlin term of 20 octaves).
Reply
:iconlyc:
lyc Featured By Owner Dec 24, 2008
having said that, it does look pretty good :D
Reply
:icongreenhybrid:
greenhybrid Featured By Owner Dec 29, 2008
Thank you Tom!
Reply
:iconlyc:
lyc Featured By Owner Dec 24, 2008
hmm, that's a hell of a rendertime for such an image, seems to me that you could cut it down a hell of a lot with some lod!
Reply
:icongreenhybrid:
greenhybrid Featured By Owner Dec 29, 2008
I am not sure where exactly the bottleneck is, maybe the shader system is so slow, but yes, LOD could help, especially with the building phase (or I really stuck to intersecting implicits, but I haven't found a method yet that saturates my needs).
Reply
:iconlyc:
lyc Featured By Owner Dec 29, 2008
perhaps keeping track of screenspace derivatives (basically, you also generate two rays for dx and dy and intersect them with the plane defined by the intersection normal) and which brdf you're using, you can switch between lods based on distance.

adding lod for a terrain should add only 33% extra storage requirements, and if you use a caching/paging mechanism you'll get good use out of a reasonable fixed amount of memory even for very large and complex (procedurally defined) terrains.
Reply
:icongreenhybrid:
greenhybrid Featured By Owner Dec 30, 2008
I think the storage would even decrease in size, as I would build the tree lazily (I have done lazy building before, but without LOD, it looked promising).

What I learned when I overused my large_array-class was that after wakeup, only a small fraction of the whole terrain was paged back in, say around 1-2GiB of a total of 32GiB was paged back (paging always goes on demand in my class; though I think "Most recently used" could fit better into quadtrees than the "Most often used"-pattern I now use; basic thought was to stabilise the large_array a bit, but for large screen resolution and path tracing, MRU could do better; dunno)
Reply
:iconlyc:
lyc Featured By Owner Dec 30, 2008
for sharp reflections (e.g. off water) you won't gain anything, but the soft light bouncing around should benefit a lot from using a lower res representation. lazy geometry caching sounds like it could work well for you :)

having said that, i am thinking about adding another 6gb of memory, for 12 total ;P
Reply
Add a Comment:
 
×




Details

Submitted on
December 24, 2008
Image Size
1.8 MB
Resolution
1680×1050
Link
Thumb

Stats

Views
1,738 (2 today)
Favourites
7 (who?)
Comments
22
Downloads
125
×