Mini render programma's

ray tracing algoritme 


Sirat a simple Ray Tracer to render realistic images. With a high degree of photorealism. GNU GPL license.

smallpt (open source)

Global Illumination renderer

met slechts 99 regels C++ codes voor het programma

Smallpt render programma met Cornell Box als voorbeeld

Renderingen met dit kleine perfecte renderprogramma onder de MIT licentie, dat maar 99 regels C++ code bevat en Open Source is.

Het effect van langer renderen met meer Sampels perfect in beeld gebracht.

Van 13 seconden tot aan 10,3 uur aan toe. Renderingen met 2,4 GHz Intel 2 Quad core processor met 4 threads.

Met behulp van nummer integratie (Monte Carlo path tracing) en de render vergelijking zijn ze tot stand gekomen. Anti-alias is uitgevoerd met supersampling, die alle jaggies eruit haalt, behalve die rond het licht. Dit wordt bereikt door het gebruik van 2 x 2 subpixels die worden ingeklemd en dan het gemiddelde wordt genomen. Deze manier wordt ook vaak bij computer Game programma's toegepast. Het is dus downsampling. Het nadeel is dat er op een hogere resolutie moet worden gescand, waardoor de rendertijd toeneemt. Het aantal samples bepaald uiteindelijk de kwaliteit.

( HRAA = High-Resolution Antialiasing )

Timings and resulting images for different numbers of samples per pixel (spp) on a 2.4 GHz Intel Core 2 Quad CPU using 4 threads.

The box scene is constructed out of nine very large spheres which overlap. The camera is very close to their surface so they appear flat, yet each wall is actually the side of a sphere. The light is another sphere poking through the ceiling which is why it's round instead of the normal square. The black area visible in the mirror ball is the front of the box colored black to appear like empty space.



a (not too) small physically based renderer

Small vcm
diverse kleine bollen met render methodes in beeld gebracht


Dit was een testmodel voor Luxrender in het verleden


LuxRender is Physically Based renderer

SmallLuxGPU is het demonstratie programma dat voor Luxrender ontwikkeling (blijft free software) wordt gebruikt. Het bevat LuxRays en het is een CPU + GPU path tracer. Waarbij duizenden paden tegelijkertijd worden getraced.

De GPU loopt via de OpenCL API en de processor via threads in de processor.

Er is ook SLG history beschikbaar.


interieur rendering in SLG (Small Lux GPU)


* LuxRender is a physically correct, unbiased rendering engine. This means that LuxRender does not use tricks to imitate real world behaviour: all calculations are done according to mathematical models based on physical phenomena.

Unbiased rendering engines have both advantages and disadvantages - generated images are very realistic but take a long time to produce; physical correctness limits artistic freedom. In LuxRender we will always make the 'unbiased' design choices.

* More than just a toy or an experimental sandbox, we want to create a robust and high-end production renderer, directly usable by artists, with the tools and features they need.

Vanaf dec 2012 wordt de SLG technologie geïntegreerd in LuxRender uitgebracht.

Mitsuba (GPL)

Physcially based renderer

version 0.5.0 Wenzel Jakob, febr. 25, 2014

Onder Mac, Linux en Windows. Met Collada file format voor het 3D model.

Documentatie op internet (36 MB PDF) ziet er verzorgd uit, waarom toch zijn er nog steeds commerciële render programma's, die dit kennelijk niet voor goed voor elkaar krijgen? Wellicht druk met sociale media zelf in te vullen, waardoor er geen tijd meer is voor echt essentiële elementaire zaken rond het programma.

In deze blog: Painting with light using a moving point source. Een leuk idee dat navolging verdiend.

Energy-based Self-Collision Culling for Arbitrary Mesh Deformations (by Changxi Zheng and Doug L. James)

5 juni 2012

mitsuba beeldschoon voorbeeld
Inverse Volume Rendering with Material Dictionaries.



parallel raytracing program which can create realistic images.



MiniLight is a minimal global illumination renderer. It is primarily an exercise in simplicity. But that makes it a good base and benchmark (in some sense) for development and experimentation. And it just might be the neatest renderer around (on average, about 650 lines). There are translations into several programming languages.

Someone asked me how to develop a renderer in three months. It seemed not nearly enough time. But then I began to think how small such a program could be, whilst still being a complete physically based simulation with a clear, well-formed design. (A somewhat different aim from the 'Minimal Ray Tracer Programming Contest' of 1987.) I couldn't resist an attempt.

It is a command-line application. It reads a simple text model file and writes a PPM image file. Supported platforms include Mac mac icon, Linux linux icon, and Windows windows icon.


Monte-carlo path-tracing is described as 'unbiased'. The term is now sometimes used in the manner of a marketing tag. Its real meaning is too abstract for that purpose. It denotes a lack of consistent error&emdash;the only error is in the effects of the randomness. Such niceties are appropriate for mathematics but for engineering we must live by practicalities. All implementations are biased and incorrect in various ways. The task is to arrange them acceptably.



Render formule met dome

The rendering equation describes the total amount of light emitted from a point x along a particular viewing direction, given a function for incoming light and a BRDF.

Postscript Ray Tracer

John Hartman and Paul Heckbert

Anyone using mini render software?

Rad-gauss - It is a simple and naive radiosity solver

GNU GPL license.

Simple and Naive Radiosity Solver. project rad-gaussin honour of a German mathematician


a ray tracing program from 2010 - 2011


joons-renderer was moved to GitHub.

This google codes internet page is no longer in use.

joons-renderer brings Sunflow's ray-tracing to Processing.

joons-renderer reads geometry from Processing, applies Sunflow ray-tracer engine to it and returns the rendered image from the exact same viewpoint. It supports:

* Texture
* Light
* Depth-of-field

.. and more. Check out the full list of supported & unsupported functions.


Basic examples


Java based global illumination renderer

April 11, 2007

Sunflow is an open source rendering system for photo-realistic image synthesis. It is written in Java and built around a flexible ray tracing core and an extensible object-oriented design.

House in Sunlight with Sunflow renderer by Hasan Celik.

Klik in de afbeelding voor een vergroting


2 bounce path tracing, render challenge

Klik in de afbeelding voor een vergroting

Content and text from their Sunflow render website

I've been using the java-based global illumination renderer Sunflow together with Processing for quite some time now. The first ever video I made with Processing (only 10 months ago!) was actually one that employed Sunflow through the P5Sunflow library. Two months ago I went a little further to create a short motion graphics experiment for the 5 second project. All my Sunflow projects until that time worked through the P5Sunflow library.

The main advantage of this library is that it automatically 'translates' a sketch. This means you don't have to make any changes to your original sketch, except change the renderer. This is ideal. Unfortunately however, this library was never fully developed. So although it supports geometry, it does not allow for more advanced Sunflow functionalities such as shaders, lighting and Sunflow's built-in primitives.

SunflowP5 alternatives

For the last few months I've been looking at different alternatives to bring full Sunflow functionality to Processing.

Processing en Sunflow renderer

I checked out some of the P5Sunflow clones like Sunflow4P5. See the discussion in this thread on the old forum. Didn't work out at all. I then downloaded Sunflow itself and examined the possibility of exporting geometry from Processing, which is subsequently rendered in "the real" Sunflow. This is possible. You can export stuff from Processing as regular 3D models or try to export it in a Sunflow-ready format. Many 3D applications already have plugins to export to Sunflow format and it's a relatively simple format. Interestingly enough, a very recent attempt to bridge the gap between Processing and Sunflow seems to focus on this technique. Like a hybrid between full translation and using the Sunflow .sc format or something. See this thread in the new forum for more details about this library-in-development called JoonsRenderer. Looks really interesting, although I haven't tried it yet. It wasn't around at the time I started my search. Getting back to the story, my attempt to export geometry and then manually render in Sunflow, worked. But it was very time-intensive and for my end goal (animation) not a viable solution at all. So I decided to look into different alternatives.


I then found a java-wrapper called SunflowAPIAPI, created by Christopher Warnow back in 2008. It functions like an easier-to-use API for Sunflow's functionalities. After some figuring out, I got it to work directly from within Processing. I've been spending some time (between vacations, my day job and other personal projects!) on learning this wrapper and the possibilities of Sunflow in general. The three big advantages of using SunflowAPIAPI are that it allows for (a) full Sunflow functionality (b) directly from within Processing and (c) can be tweaked at will; as the code is directly accessible from Processing's IDE. The big disadvantage, especially compared to SunflowP5, is that it requires special syntax. So it will not translate existing sketch code automatically. Instead it requires some manual translation. How much work this will be, depends on the sketch. The syntax itself is not difficult. In fact it's fairly straight-forward, as it completely mirrors the terminology used in Sunflow. So it all makes sense, but you gotta consider the translation-issue beforehand If you're aiming for an efficient workflow.


Workflow alternatives

I've found two main workflow options. Either work fully in SunflowAPIAPI-ready code and render to Sunflow in preview mode. The advantage of this method is that it's 1:1. You write it, you see it etcetera. The disadvantage is, that Sunflow is SLOW even for low-resolution, low-quality preview renders. The second method is to program your sketch in OPENGL and have a 'mirror copy' of all your code for the SunflowAPIAPI. The advantage is that OPENGL works in real-time. Then at the press of a button you could start rendering to Sunflow. The disadvantage is that all your code is basically doubled and you have to sync geometry, camera's etcetera. I've used both methods. It really depends on your needs and the complexity of the scene, which one you'd wanna use.


How to install SunflowAPIAPI

For people interested in using this API, let me elaborate on the steps you need to make it work.

1. Create a new empty sketch.
2. Compile a version of Sunflow or download the latest version 0.073 here.
3. Copy this file "sunflow-and-janino.jar" into the "/code" subdirectory of your sketch.
4. Go to the Google repository for SunflowAPIAPI.
5. Checkout the code via a Subversion client or directly download the files via browse.
6. The main file you will need is "". Copy this file into the main sketch directory (besides your "sketchname.pde").
7. Now when you code your sketch &endash; using the correct syntax &endash; it should render using Sunflow. A basic code example is provided below.


How to use SunflowAPIAPI (code example)

Once you have followed all of the above steps, all that remains is the content of the sketch. The examples provided with the API are useful, but you have to make some small changes for them to work in Processing. Here is an example for learning purposes, which only has the extremely bare essentials needed to make a simple test render. Code example:

Programma onderdeel van Render programma in Processing

import joons.*;
JoonsRenderer jr;
boolean rendered = false;
float eyeX = 0;
float eyeY = 120;
float eyeZ = 40;
float centerX = 0;
float centerY = 0;
float centerZ = 40;
float upX = 0;
float upY = 0;
float upZ = -1;
float fov = PI / 4;
float aspect = (float) 1.3333;
float zNear = 5;
float zFar = 10000;
void setup() {
jr = new JoonsRenderer(this,width,height);//just declare like this.
jr.setRenderSpeed(1);//render speed is 1 by default. Set it to 2 for x2 speed. Set it to any number. Lowers quality.
void draw() {
beginRecord("joons.OBJWriter","");//just call like this. Leave the second parameter as "".
perspective(fov, aspect, zNear, zFar);//call perspective() before camera()!!
camera(eyeX, eyeY, eyeZ, centerX, centerY, centerZ, upX, upY, upZ);
// if(rendered)
//void keyPressed() {
// if (key == 'r' || key == 'R' && !rendered) {
// render using render("ipr") to render quick and rough,
// and render("bucket") to render slow and smooth
// if successfully rendered, render() returns true
// }

video's about joosrenderer

Processing + Sunflow + 3D flocking + ProGAL alpha shapes + Haxademic + Cornell Box from CacheFlowe on Vimeo.

rendered from Joon Hyub Lee on Vimeo.