No this is not the explanation of the Weather-Technique 2 (see latest picogen-post), but rather an informational post: picogen's source code is now online , you will find it under

The beast is under active development (see last post), and the homepage will get an initialisation soon (at least I hope so...). I have some really funky plans in my Tomboy notes, I can say :)

Viele Grüße,

seb

I\'ve been busy with some basic work for weather effects in picogen. In it\'s shortest possible version, here it goes (Try Number 2 will be presented in the next days, and will maybe yield a full tutorial on the tec behind).

Try Nb. 1

Observation A: When raining or snowing, there are a lot of rain-/snow-elements
Observation B: When raining or snowing, there are a LOT of rain-/snow-elements
Observation C: The dust experiments from the previous post have shown that there is hell not enough memory to render all rain-/snow-elements (from hereon, I say particles) uninstanced.

So, Instancing is maybe a solution, but still the memory usage grows as the scene grows, even if logarithmic. I think I will try out instancing in future to bring back unbiasedness, but now I want something I can also use for clouds-rendering.

A solution to enable constant memory and constant time is then to have some kind of z-buffered skybox. So I wrote a class, inherited by the Intersectable-interface (see here), but only taking into account the ray direction:

• take the direction vector as a position vector, and kick it through some function f(x,y,z) -> R (with R being the realm of real numbers)
• then, take some function f(s) -> 1 or 0, and let the function thus tell you if the ray hits something or not.
• to combine the map properly with the world, create a distance-from-origin value, based on the initial function f(x,y,z)->R
• after having some ache with creating a good distance-value, now make the function f(x,y,z) multilayered, so that each layer is responsible for a specific distance range:

         f(x,y,z) = f_1(x,y,z), if current range is 0..range1,
                  = f_2(x,y,z), if current range is range1..range2,
                  = f_n(x,y,z), if current range is range_n..range_n+1,
   

there is it again, non-constant memory usage, non-constant time (bah). So this is not saturating, especially because the depth-value-creation is a hack. You can nevertheless check out the source-code of the snow class, with which I have created the last image. It is here: header | source.

Results of Try Nb. 1

For now, I am writing too much, and thus schedule my other tec into another post here. Have a look at the two images!

upgrade :)

I have finally upgraded my box to 2GiB, and I eventually had to grind that a bit, so I hacked together a simple scene with hundreds of thousands micro-boxen (if you zoom in you can actually see a bit of the shading), representing the rings of the big moon.

dust experiments

In the first image I concentrated myself to much on the dust and really forgot to create a cool moon-terrain :|

Image 2 then shows a neat sunset, where I tried out the new 2x2-antialiasing-after-HDR-saturation of picogen (but I am not really happy with it, because it still does look a bit blocky in the lower right corner).

Image 3 is very similar to the first image, except that I increased the number of micro-boxen, so did I for the moons. And this time I did not forget the terrain of the moons, and all in all, it was not an easy job for my old box: 2.7GiB for startup paging (that included a lot of swapping, took a good 40 minutes), and then 1.5GiB during rendering.

visual facts, friend. visual facts.

With respect to picogen and this blog I have been pretty lazy the last time :|

picotera

What I am currently working on actively is picotera, the picogen scene scripting language (which maybe becomes general enough to be used in other programs). The language is inspired by C, and provides some neat features, like builtin L-Systems, Substitutions (a kind of macro) and maybe real functional programming (http://en.wikipedia.org/wiki/Functional_programming).

Lots of fun, but it was hard to get flex and bisonc++ (not bison++; where's the difference, huh ;)) to do what I wanted to be done.

teasers

The images show some experiments with real geometry moons, that is, the moons are not part of a two dimensional skybox, but you could actually zoom onto their surface (in the image called 2097 there is even a moon that throws a shadow onto another one).

Of course, if you would zoom in, you could see that the detail is limited (actually, I used around 140,000 triangles for each moon), but at that range, it is okay.

Enough words, please enjoy the glimpse on the future :)

the quest

I wanted to see how to do basic arithmetics (addition,subtraction,multiplication,division) with a minimal set of axioms. I ended up with the Subtraction only, by which you can 'emulate' the other three operations, if you allow recursive functions and a bit of if-ness. Let me know if you can do it even more interesting!

the code

... is here ('code.cc' is the c++-source, 'code.html' is the browser-pretty version):
http://picogen.org/me/gpl/typerhappy/bootstrap_by_subtraction/

Heterofractal Landscapes

I have implemented heterofractal ridged perlin noise now, that is a multifractal, that influences it's contribution by itself. Basically speaking, in picogen/perlin-function the height and the roughness is based on the height and the roughness at a given surface point. That definition being said, try to implement that ... Really, I don't know if my implementation is like Ken Musgrave meant it, but the hills do really look neat, I guess (have a look at them below). If you are interested, try this text by Dr. Kenton Musgrave.

Porta Verde

Mirrorland

the picogen frontline

the imagery

The second render shows some really excessive use of motion-blur, it is called The Apocalypse Dream, and the reason for the name should be clear ...

the source of motion

/***************************************************************************
 *            VelocityInstance.h
 *
 *  Thu Nov  8 01:10:06 2007
 *  Copyright  2007  Sebastian Mach
 *  [email protected]
 ****************************************************************************/

/*
 *  This program is free software; you can redistribute it and/or modify
 *  it under the terms of the GNU General Public License as published by
 *  the Free Software Foundation; either version 3 of the License, or
 *  (at your option) any later version.
 *
 *  This program is distributed in the hope that it will be useful,
 *  but WITHOUT ANY WARRANTY; without even the implied warranty of
 *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 *  GNU General Public License for more details.
 *
 *  You should have received a copy of the GNU General Public License
 *  along with this program; if not, write to the Free Software
 *  Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
 */
 
#ifndef _VELOCITYINSTANCE_H
#define _VELOCITYINSTANCE_H

class VelocityInstance : public abstract::IIntersectable{
		abstract::IIntersectable *intersectable;
		misc::geometrics::Vector3d velocity, offset;
		misc::prim::real timeexp;
	public:
		VelocityInstance() : intersectable(NULL), timeexp(1.0) {}
			
		void SetTimeExponent( misc::prim::real t ){
			timeexp = t;
		}
		void SetVelocity( param_in( misc::geometrics::Vector3d, V ) ){
			velocity = V;
		}
		void SetOffset( param_in( misc::geometrics::Vector3d, o ) ){
			offset = o;
		}
		void SetIntersectable( const abstract::IIntersectable* I ){			
			intersectable = const_cast(I);
		}
		
		virtual bool Intersect( 
			param_out(structs::intersection_t,intersection), param_in(misc::geometrics::Ray,ray)
		) const
		{
			using misc::geometrics::Ray;
			using misc::prim::real;

			if( NULL == intersectable )
				return false;
			Ray newRay;
			newRay.x() = ray.x() + offset + velocity * ( powf( real(rand())/real(RAND_MAX), timeexp ) );
			newRay.w() = ray.w();
			return intersectable->Intersect( intersection, newRay );
		}
};


#endif /* _VELOCITYINSTANCE_H */

greets,

sebbb

screw me

Screw me for not blogging for a good 1/4th of a year :P
I have not really been inactive, but stressy job business soaked a bit of my "update-yer-blog"-time, and yet more to come. Additionally the finals of my apprenticeship (app-coder) are coming nearer and nearer, and thus the next weeks are going to be the most un-productive ones for years...

picogen

But without further babble, the good news (at least to me ;)) are that I began writing picogen, a terrain ray tracer. It will go open source as soon as I have implemented some sort of scene scripting. I have posted some wip's on deviantart, plus now here in the following. Very much inspired by a siggraph course-note by Ken Musgrave I have implemented some basic function-functionality (heh :D), I mean, some sort of "xyz-to-h-mappings" (applied onto the sphere, using a simple cube-sphere-mapper, on top of yet another BIH).

I have also tried to implement 2d-clouds, based on the Perlin Noise function and punched through Hugo Elias' exp()-mod. The shading of the clouds is based on a paper by Anthoine Bouthors. For some reason, the higher dimensional scattering did contribute to the final luminance only by a factor around 0.000001-0.001. I have written him an e-mail with fine LaTeX markup, but he did not answer .... I guess it's the study- and research-business, so I don't blame him.

A quick and dirty copy-and-paste+search-and-replace did the rest for the Preetham based skylight. Lycium might remember I told him of strange colors for higher sun positions, and just recently I finally found the bug (it was in the Perez-function), and only the last of the following images shows correct Preethamness (unfortunately I've made the colors a bit to light, so it looks white overally).

More picogen to come!

greets,
seb

the imagery

Clicks for full-size appreciated!

the first rendition, shows some neat caustics on the ground	the clouds look realistically shaded to me, and never be before I recognized the actual darkness of clouds in the reality
a high altitude capture (radius of the "earth" is around 80 kilometers): you can see the curvature of the planet-sphere	implementing Anthoine Bouthors shader (very much purple'ish); a 360� panorama shot
one more shot	implementing some functions onto the spheres: Lava-Perlin (negated ridged), Normal-Perlin and Ridged-Perlin
Hugo Elias' sphere-version of Fault Formation	Sine, and Lava-Sine

finally fixed the Preetham bug, unfortunately a bit too light