Tag Archives: SYN

SYN: First images

“Do you know that feeling of satisfaction when your program runs immediately without errors?”
“Me neither.”

Even if not at the first run, seeing your own program working is a big satisfaction. Today after several weeks of programming I finally got the skeleton of SYN working. Here is one of the first images I was able to render:

Power 8 Mandelbulb

It’s a simple Power 8 Mandelbulb raytraced with one directional light. The image itself is not impressive, but there are a couple of properties that make me consider it special:

The rendering time: The image was rendered at 16k x 10k pixels (160MP) in 77.6 seconds using all available resources on my PC: CPU Intel i7 2600k, GPUs NVIDIA GTX680 and GTX560Ti. I have no real comparison with other softwares at the moment and the code may not be optimized, but I believe this is a good result.

The flexibility of the rendering system: For casual users who just want to play with fractals, creating an image like this one  will be as simple as selecting the formula from a list, playing with the options and pressing Render. For advanced users who want to push their creativity to the limits or want to experiment with new formulas, SYN will be a huge playground. Do you remember the pipeline described in the first post? It’s designed to offer to the user the greatest customizability. The pieces of code that can be inserted at the different stages are now called bricks, since they can be assembled to build your world like LEGO bricks. Here is an example shader brick:

<SYN type="shader"
     author="Mattia Gollub"

      <float3 name="direction"/>
      <float3 name="intersection"/>
      <float3 name="normal"/>

      <float4 name="color"/>

      <float4 name="diffuse" default="0.0, 0.0, 1.0, 0.0" min="0.0, 0.0, 0.0, 0.0" display="Diffuse"/>

      <!--Shader code here-->

Objects are defined with the same XML syntax. The code must be written in OpenCL C Language (which is very similar to C). SYN will automatically check the bricks for compatibility, build visual controls for the parameters, and assemble the code fragments in a complete OpenCL program.

It’s all for today. In the next weeks I’ll fix some bug and improve the work balance between multiple devices. I will also try to add support to multiple objects in the same scene.

Until next time,

Don’t trust fseek(), it lies!

When I press the Build button I Always hope to see a compilation without errors. Obviously this almost never happens, but yesterday it did! Too good to be true: when I ran the application OpenCL failed to compile the rendering kernel and I got errors at lines beyond the end of the file. Since I was sure that the error was not in my code I started blaming everyone: Intel for a buggy compiler, NVIDIA for his lack of support and Khronos for some other invented reason. Of course it wasn’t their fault, I just should have been a bit more careful when reading the .cl files. This was my code:

// Read the source code file
char* buffer;
FILE* file = fopen(fileName, "r");

fseek(file , 0 , SEEK_END);
long size = ftell(file);
buffer = (char*)malloc(size);
fread(buffer, 1, size, file);

// Create OpenCL program
char* sources[] = { buffer };
size_t lengths[] = { size };
cl_program program = clCreateProgramWithSource(
     context, 1, (const char**)sources, lengths, &amp;error);

It turned out that the problem was in the function fseek(). The C standard states:

A binary stream need not meaningfully support fseek calls with a whence value of SEEK_END.

This means that the code above doesn’t really get the real size of the file. In my case the value of size was sometimes bigger than the real file size, causing dirty memory to be included in the source code. To fix this problem I took advantage of a powerful library that I was already using for other tasks: boost.

boost::filesystem::ifstream fIn;
fIn.open(fileName, std::ios::in);

std::stringstream ss;
ss << fIn.rdbuf();
char* buffer = ss.str().c_str();

This solved the problem. Now the kernel compiles smoothly. I had an access violation exception in nvcompiler.dll when running the kernel on x64 but I fixed it recompiling everything for x86 and then for x64 again. Don’t ask me why does it work! I have no idea and the NVIDIA OpenCL compiler is well-known for his bugs. Anyway I was finally able to run a basic raytracing pipeline with OpenCL!

SYN: A way to explore the fractal universe

My first reaction when I see a beautiful image is to ask myself if and how can I do something similar. Fractals were no exception for me: I tried some existing softwares like Mandelbulb 3D and Ultrafractal, but none of them really satisfied me. I felt somehow limited, and as a programmer I prefer to build myself the tools I need. Fractals are a huge world and, to explore it deeply, a flexible software is needed. Speaking with the people of fractalforums.com I discovered that many artists are also waiting for more powerful tools, so, in collaboration with a friend who will write the GUI, I decided to start my own project: SYN.

SYN is an image synthesizer: a software that allows definition and real-time exploration of procedural shapes. It will also include a raytracer for the final rendering of images and animations. To ensure a high level of customization the rendering pipeline will be programmable at different stages:

  • Sampling stage: defines how rays are shot from a pixel. This allows effects like depth-of-field and motion blur.
  • Shape definition stage: the engine accepts scripts that defines either a distance estimator or a brute force intersection function.
  • Shading stage: defines the color of the light on an intersection.
  • Post processing stage: once the raytracing process finishes it’s possible to apply custom effects on the final image.

For those people who don’t like writing code, SYN will allow scripts to be loaded in a GUI where parameters can be modified with visual controls. In the image below you can see an early storyboarding draft showing how the user interface is going to look like.

SYN GUI draft

Since raytracing requires heavy calculations, SYN will use all available resources through OpenCL. The rendering process will be distributed over both CPU and GPU for real-time previews. For the final renderings the engine will be able to distribute rendering tasks over multiple computers.

In this post I tried to give a general idea about what is SYN going to be. We will spend the next weeks programming, I hope to be able to publish a demo soon. In the meantime feel free to give suggestions and to express your opinion about this project.