radium renderer

Discuss stuff not about Indigo.
Posts: 34
Joined: Sat Jul 22, 2006 7:05 am

radium renderer

Post by leope » Sat Dec 09, 2006 5:26 am


java mlt renderer


Posts: 153
Joined: Fri Aug 25, 2006 3:13 am

Post by IanT » Sat Dec 09, 2006 6:52 am

It was Indigo's existence that inspired me to implement MLT :)

Radium's not quite up to Indigo performance but not too bad considering it's Java. Useful if you want to play around with MLT on a Mac, for example.

Ian (the entire Radium coding team :wink: )

User avatar
Posts: 1395
Joined: Fri Oct 13, 2006 5:12 am

Post by zsouthboy » Sat Dec 09, 2006 8:06 am

Nice job Ian :)

Indigo has inspired me to try my hand at writing a MLT renderer too! But in C++ :)

About Radium:

Even though it's Java, can't it be compiled so that it runs natively (instead of in a sandbox)? (I'm not knowledgeable on Java)

And I haven't had a chance to play with it yet, but what kind of file formats do you support? As a coder AND a user, I love Indigo style XML files now.

Posts: 153
Joined: Fri Aug 25, 2006 3:13 am

Post by IanT » Sat Dec 09, 2006 8:27 am

Thanks :)

Re: native Java...

The latest JVMs effectively do already compile critical code sections into native machine code anyway. Non-coders often assume that Java must be slower but imagine the situation where someone decides to distribute their C++ programs as source code, bundled with a clever tool that makes the source code native at the point of execution (i.e. a "compiler" :wink: ) So, 5 years ago, Java was mostly interpreted but now it's mostly compiled. Big advantage here that the JVM is platform-specific, can detect the instruction set of the host CPU and can optimise the code specifically for the platform it's running on. Obviously it means a Java program takes a bit longer to "warm up" but who cares when your render is going to take 24 hours?

A few months ago, I tried out a couple of native Java compilers (i.e. they produced a .EXE from Java source) and the "huge performance gains" I got were in the order of 1-2% :?

At the end of the day, all a renderer is doing is throwing floating point instructions at the FPU, and there's no reason why Java shouldn't, now or in the very near future, be able to do that as quickly as C++.

Re: file format...

Radium uses a proprietary text scene file format, which (as far as I can tell) is Turing-complete ... it supports fully-typed variables (double, vector, image, material, shape, map etc.), if-then-else, while loops, do-while loops, for loops, recursive functions and the renderer supports primitives other than meshes (sphere, plane, square, cone, cylinder, torus) and full CSG operations (merge, subtract, clip, intersect, union). It's similar to POV-ray's SDL in terms of it being a programming language. It lacks arrays but the functions are much more powerful than POV's.

Like POV-ray, any mesh or primitive can be arbitrarily scaled, rotated or translated and meshes can also be instanced to save that precious memory. Shape-space <-> World-space transformation is built into the core (via ray transformations).

The only exporter implemented at the moment is (predictably) Blender but it seems fairly problem-free now. I use Blender to swing various other file formats (.3ds, .obj, .kmz) without too many problems.

I'm rambling now (although this is off-topic :wink:)


User avatar
Posts: 23
Joined: Wed Nov 15, 2006 3:20 pm
Location: Seattle, USA

Post by codemonk » Sat Dec 09, 2006 8:37 am

Indigo inspired me to try writing a renderer as well.

However mine only got to about 200 lines and the ability to render a harcoded scene of 4 spheres with 3 hard coded lights and output to a really basic image file.

I suppose I could have chosen an easier project to do as my second C++ program ever...

Good luck to both of you with writing your renders and I hope you have better luck than I did...

Posts: 153
Joined: Fri Aug 25, 2006 3:13 am

Post by IanT » Sat Dec 09, 2006 8:54 am

Yeh, you didn't pick an easy one. I eased myself in with a Sudoku generator/solver/helper...


Then I relived my boyhood passion for Mandelbrot sets. Here's a cool video generated by my Java "Mandelbrot Explorer/Animator"...

http://www.trackvids.co.uk/mand.mpg (3.2Mb, please "Save target as...")

And then I started a ray tracer. I've been developing it on and off for a couple of years now, but only a few weeks since I implemented MLT and finally managed to render stuff that looked vaguely life-like.


User avatar
1st Place Winner
Posts: 1295
Joined: Sun Jun 25, 2006 1:25 am
Location: Berlin

Post by psor » Sat Dec 09, 2006 10:00 am

Wow Ian! :shock:

You did an awesome job there dude!

And now get in touch with Nick and work together! ;)



:D ;)

take care
"The sleeper must awaken"

User avatar
Posts: 1395
Joined: Fri Oct 13, 2006 5:12 am

Post by zsouthboy » Sat Dec 09, 2006 3:06 pm


Wow, thanks for the response. Shows how up to date I am on JVM :)

The idea of Turing (or mostly) complete file format had never occurred to me, but now that I think about it... I like!

I'm actually playing with the idea of allowing a material to be defined in a way that describes what will happen to a ray at its surface.
e.g., instead of having a diffuse (or lambertian) surface, simply define the material as bouncing the ray in a random direction x% of the time, and absorbing y wavelengths z%.

Then again, other than allowing for creativity of others in material design, I'm not sure that isn't a solution looking for a problem.

However, being able to define the properties AND having the ability to do loops, if elses, etc....

My mind is rolling here. Some sort of "plugin" system... that allows you to plug in materials like that, only if you need them, that are not hardcoded into the program.... keeping those things separate...

Whoa, I'm getting way off topic. This thread is for talk about Radium!

Again, good job! :)

Posts: 153
Joined: Fri Aug 25, 2006 3:13 am

Post by IanT » Sat Dec 09, 2006 10:32 pm


For a really good implementation of user-definable shaders, check out Sunflow (also Java). Christopher has used the Janino library, which is effectively a just-in-time Java interpreter/compiler that allows new code to be imported at run-time.

A general rule-of-thumb, for any programming language, is that calls to plugin methods are slow compared to their hard-coded counterparts. C++ allows explicit inlining (and Java does it automatically) so short method calls to, say, Spectrum/RGB methods are extremely fast, and I imagine this might also be applied to simple BSDF methods too.

However, allowing users the option to write their own materials, test them etc. and THEN the developer coding their efforts directly into the program ... that would definitely be a cool feature :)

Re: probability-based materials ... essentially, any renderer that uses importance sampling already does this to a certain extent, especially where a material has both a BRDF and a BTDF (e.g. di-electric) ... the algorithm randomly chooses between reflection and transmission based on the specific properties at the intersection point (i.e. russian roulette).

Also check out some of the work being done by Cornell on precisely measured surface reflectance properties ...


This is like the diffuse counterpart to Indigo's support for NK data.


Posts: 153
Joined: Fri Aug 25, 2006 3:13 am

Post by IanT » Mon Dec 11, 2006 9:47 am

Mainly because...

a) They're GREAT scenes
b) I have some kind of performance reference point so that I can see the speed is vaguely on track.

If you fancy donating any more .blends, just for my own testing, please let me know (goes without saying they'll be kept non-public)...


Posts: 8
Joined: Wed Dec 20, 2006 3:07 pm

MLT Renderer...Starting Point

Post by Smaug7800 » Wed Dec 20, 2006 3:49 pm

Great job on Radium! This is something I would like to challenge myself with too.
I however, need a starting point on writing a renderer? Any suggestions on what to do first? Any special books or gathering an essential list of formulas needed? Any kind of project structure I should follow to keep from getting off track? Thanks and I apologize if this question doesnt make sense.


Posts: 153
Joined: Fri Aug 25, 2006 3:13 am

Post by IanT » Wed Dec 20, 2006 5:00 pm


It's a daunting task but worth having a bash at if you have a decent grasp of maths and have a fast PDF viewer :wink:

There are loads of essential resources out there on the web. If you like, I can send you plenty of links but key ones are:

Global Illumination Compendium (Dutre)

A Practical Introduction to Metropolis Light Transport (Cline et. al)
http://rivit.cs.byu.edu/a3dg/publicatio ... torial.pdf

Metropolis Light Transport (Veach & Guibas)

Robust Monte-Carlo Methods for Light Transport Simulation (Veach)
http://graphics.stanford.edu/papers/vea ... sis-bw.pdf

A Robust Mutation Strategy for the Metropolis Light Transport Algorithm (Keleman et. al)

The "Physically Based Rendering" book is very useful if you want a head-start on key areas such as BSDFs, geometry intersection, image reconstruction etc. etc. I only found this 18 months AFTER I'd figured all this out lol.

The Sunflow Global Illumination Rendering System (by Christopher Kulla) is an extremely well-architected, open-source Java renderer at http://sunflow.sourceforge.net/ It supports a number of global illumination methods (path-tracing, photon mapping, instant GI etc.) along with advanced primitives, decent intersection accelerators etc. and is very easy to both understand and extend. The notable missing feature is MLT :wink:

Although Radium isn't open-source, I'm quite happy to donate bits of source code to anyone who asks.

Use an OO language, abstract/interface as many things as you can (especially the things you'll want to change/augment often such as primitives, image objects, intersection accelerators, image filters, cameras etc. etc.). Spend a few weeks designing your interfaces first.

Hope that helps,


User avatar
Posts: 103
Joined: Tue Oct 24, 2006 11:38 pm
Location: Germany / Berlin

Post by skypa » Wed Dec 20, 2006 8:37 pm

Everytime a new MLT engine is born it's either commercial and/or closed source, which makes me, as someone who feels pretty strong about free software, cry a little.
Don't get me wrong, I love Indigo, and I'm excited to see you, IanC, taking your own approach on the subject (especially with your nice emphasis on an intuitive GUI), but as a long-term *NIX user who saw some of the greatest pieces of software evolving into community driven, highly productive projects it makes me sad to see such promising implementations developed closed source in one-man teams.

Posts: 153
Joined: Fri Aug 25, 2006 3:13 am

Post by IanT » Thu Dec 21, 2006 2:05 am

Hi skypa,

I've stated before that Radium will be open source one day, it's just that, because it's developed so quickly, especially in the last few weeks, the sheer amount of obsolete code in there would be confusing to almost anybody.

Once I'm happy with the GUI and the MLT implementation, I'll do a big sweep-out of the cobwebs and release the source code. I'll be dictating my own schedule though, not for commercial reasons (Radium will NEVER be commercial), but just for the pure reason that this is a hobby :wink:


User avatar
Posts: 748
Joined: Tue Aug 01, 2006 4:14 am
Location: Colombia

Post by afecelis » Thu Dec 21, 2006 3:14 am

Radium will NEVER be commercial
Amen...Amen... :wink:
AMD Ryzen 7 1800 @3.6ghz, 32GB ddr4 3200 mhz Ram, 2X Nvidia Gtx 1070 8GB, Win10/Elementary OS 5.0 Juno (ubuntu 18.04), Blender/Sketchup/Modo/Cinema4d

Post Reply
19 posts

Who is online

Users browsing this forum: Ahrefs [Bot] and 5 guests