Deviation Actions

phresnel's avatar

picogen 0.3 - volumetrics-pfx

By phresnel
Software: To learn more about picogen, the free software used to create this image, visit #picogen or [link] .

About the image: It is the same image as [link] , but which is without post-fx applied. The following three paragraphs are a copy of that deviation (enclosed in ++--).

About the image, programming-wise: This week I implemented volumetric rendering in picogen, largely influenced by PBRT (actually, one could call the renderer to be of the "PBRT kind" :) ). After 3 days of spare time hacking (yay, that is not even a normal working day:D) I got this result.

About the image, image-wise: This is not a lens flare effect. Lense flare effects occur due to very bright light bouncing inside your camera's lens construction ([link]). What you see in this image are so called "crepuscular rays", sometimes called "god rays".

Shadow is the absence of light, so the dark regions are really volumetric shadows thrown by the mountains, into the dense atmosphere. Those light shafts are actually (near-) parallel (*), and it is the position of the observer and the wide distance of view that make them look like emerging from a common center. I still think this is a fascinating effect, even, or better, especially, after "implementing" them. More about that phenomenom: [link] .

(*) While god rays are indeed only near-parallel in nature (but that "near" is not obvservable by us), they are really parallel in picogen, as they are implemented in terms of a directional light source, which is programmerish for an optimized light that has no position, which is a very good approximation for sun light

Why this post-fx version? Because I was surprised what a simple post-effect like unsharp-masking, a technique to increase perceived sharpness of an image, in use by photographs since the 30s, can do about the image.

Decide for yourself which one you like, for my part, I seriously think about making this post-effect an optional part of picogen.


Sidenote for DigitalLandscapes and everyone else: Please grill and fry me, I am programming this thing, so I might loose my sense for aesthetics from time to time.
Image details
Image size
1680x600px 944.17 KB
© 2010 - 2021 phresnel
Join the community to add your comment. Already a deviant? Log In
dpow3r's avatar
Without a doubt,your raytraced terrains are the most beautiful ones that i've seen so far in the internet.
I hope one day i'll have the time and courage to do something similar to your work =).
phresnel's avatar
Merci beaucoup, it's always great to hear if someone likes ones images :)

Keep up your great work so far, comes time comes wisdom (and it took me years before reaching the still highly improvable quality). Waiting for more of your stuff :)
dpow3r's avatar
Yesterday i had a dream about me implementing a terrain renderer ,the view was not very clear but as far as i remember it worked but i was disappointed when i woke up and realized that it was a dream :D (seriously).
Anyway,i'm planning to implement a terrain-raytracer soon but not before i finish my exams ,may be you can give some directions on how yo do it?I read it is possible to render terrains with ray-marching or using height maps to displace vertices...But i'm not sure which way to choose.
phresnel's avatar
That's a quite cool dream, I think :)

There exist several interesting technique. *lyc once recommended ray surfing to me, where you trace rays from bottom to top on the screen. You do a full ray-marched intersection at each (x|height), remember the distance D, then go to (x|(height-1)), starting at D. This can give astounding performance ([link]), but I think you only have 4 degrees of freedom (x,y,z, yaw).

Then, of course, you can do it with quadtrees. In current picogen, I use a lazily created quadtree, where I have a rough measure of the terrain size, and then create the nodes on demand.

You could also try small heightmaps for starters, like 256x256, and then use a 2d-line drawing algorithm that will test each voxel that is (even if only slightly) touched.

I have also experimented with hybrids that use some acceleration structure (like quadtree or kd-tree), and ray marching at the leaf nodes (for intersecting implicits).

None of those techniques is perfect, each has its use. The ray-surfing thing is superiour for 4DOF situations, the current picogen approach gives fast startup and quite good performance, plus has quite low memory consumptions, the ray march + heightmap(or implicit) without acceleration structure is the lowest memory consumption of all and fastest startup, but also the lowest performance for larger heightmaps (but is also the most easy one to implement, also on GPU).

Hope this gives a basic overview :)
dpow3r's avatar
Thanks phresnel for the quick introduction to terrain-rendering,it is much appreciated especially from a pro :).
I think I'll start with the first technique that lyc told you about.It seems pretty easy and fast but i guess it is difficult to do proper shading.
BTW,the link to the win32 binary of Picogen 2.0 is dead,it would be nice if you update it.
Thanks ,and keep those nice-looking terrains coming ,I'm sure that a lot of people enjoy seeing your work ;).
phresnel's avatar
Not a pro over here, hobbyist ;)

Ah thanks for the reminder on the link. Soon it wil be replaced anyways, the SimplexGui for picogen is approaching release in some weeks :)
Join the community to add your comment. Already a deviant? Log In