
Appleseed – open-source physically-based rendering engine - generic_user
http://appleseedhq.net/
======
franzb
Hello, founder of appleseed here!

Being the top story on Hacker News tonight was completely unexpected, but it's
a good surprise and definitely appreciated publicity!

appleseed has been in active development since june of 2009. It predates a
number of other open source renderers by quite a few years, including Cycles
(another fantastic project!).

I'm a production rendering engineer (e-on software, mental images, NVIDIA,
Jupiter Jazz...). I've started this project out of personal interest for
rendering, and as a platform for learning (there's always tons of new stuff to
learn), research and experiments. All other team members are professionals
currently working in the industry.

appleseed is one of the few open source renderers designed for production
rendering and targeted at animation and VFX. In addition to fully programmable
shading via OpenShadingLanguage, strong support for motion blur and many other
specific features, it supports accurate spectral rendering, which is quite a
unique combination.

We still have a ton of work ahead to make it a truly competitive renderer but
we're making regular progress: we're improving the core renderer every day,
and lately we've been putting massive efforts in improving our integration
with DCC apps and in achieving a comfortable workflow for artists. Loads left
to do !

Let me finally add that I'm blessed to work with such a great team. Top
quality work, persistently. We're a small but welcoming community, and
contributions are most welcome!

Feel free to ask me anything!

~~~
jnem
I'm not in the industry, but I would like to say that I am highly encouraged
by the way you described your offering.

You express a level of care, consideration, and diplomacy that is sadly
lacking just about everywhere.

The product itself looks amazing; I love seeing this high bar for open source.

~~~
franzb
Thank you for the lovely words!

We certainly do put a lot of care and efforts into producing a high quality
software product that is not only open source with a liberal license (MIT) but
which is also developed in the open (we're happy to invite anyone to our Slack
team at [https://appleseedhq.slack.com](https://appleseedhq.slack.com) where
all development discussions and decisions take place).

------
Mathnerd314
2015 Interview with the lead developer:
[http://blenderdiplom.com/en/interviews/607-interview-
francoi...](http://blenderdiplom.com/en/interviews/607-interview-francois-
beaune-on-appleseed-renderer.html)

Seems like it's in around the same place, although the plugins are getting
better and the renderer is starting to support complex scene features (not
quite there yet).

Overall though there are 100's of ray-tracers and scene renderers (seemingly
all in C++), so it's not clear if it has any compelling advantages.

~~~
__mp
I think the most powerful feature of C++ is templating. Templating makes it
very easy to write high-performance math code (no dynamic function calls,
everything unrolled by the compiler...).

Just have a look at the state of the art math libraries in rust and compare it
to something like Eigen or Cgal. The C++ code is way more flexible and
expressive than the rust code. If you don't believe me, check how the rust
libraries handle matrix implementations. Often you will find specialized
implementations of 1x1 to 4x4 matrices but no generic n-dimensional matrix
code.

~~~
steveklabnik
This will get better once we have type level integers. It's just not there
yet. You're totally right that it's a weak point st the moment.

~~~
__mp
Cool, I think rust needs some time to mature.

I'm currently looking for a rust guide that shows me some programming
patterns.

For example:

\- How to best implement an observer pattern

\- Best practices for vector code

\- Best practices for tree implementations and how to implement a lambda on
top of it.

I'm interested in small snippets so that I can get some initial productive
code and progress from there.

~~~
steveklabnik
I agree that more docs on this kind of thing will be good, but I think going
about it this way might be harder than you'd expect. Applying existing
patterns and writing data structures is actually harder in Rust than in many
other languages, and people that try to start with it often get stuck. Rust's
own patterns and best practices are still kinda evolving, hence your maturity
comment.

------
erichocean
Here are some render comparisons for the curious:
[http://appleseedhq.net/stuff/renderers-
comparison/index.html](http://appleseedhq.net/stuff/renderers-
comparison/index.html)

~~~
nickpsecurity
How am I supposed to compare these three on the top as a non-expert in this
area? The middle one looks noisier than the other two. I notice the one on the
left has darker color in dresser which may be an advantage of correct, color
handing but might be incorrect with one on right being brighter due to the
correct handing of window's light on it. And what's up with the graininess of
all of them?

Just a few things that popped into my mind looking at them. Wouldn't mind
learning a little more in objectively evaluating the renderers.

~~~
erichocean
The color differences are from different "tone mapping" implementations after
the render is stopped and can be ignored.

The point of that page is to evaluate renderer correctness (think of them as
visual unit tests), not to really compare "which one looks better". For
example, some of the images show appleseed with hard shadows, when they should
be soft.

If you want to know which one is "right", Mitsuba is the one to look at as
it's generally the most correct.

The graininess comes from not letting the machine renderer longer—the longer
it goes, the less grainy it will be. That said, all of these renderers employ
"tricks" to reduce the graininess that can make it practically impossible to
remove whatever graininess slips through.

~~~
horse3d
You can't say any of these is "more correct" from looking at the renders.
Those hard shadows stem from a difference in light size, which is almost
certainly a problem with the scene parameters being treated differently. The
light size may have been "lost in translation", turned to 0, creating a
perfectly sharp shadow.

~~~
franzb
One limitation of appleseed today is that our physically-based sun model is a
purely directional light, not a far away disk with a finite radius. This
explains the hard shadows on some of the scenes.

------
TOGoS
Hierarchical instancing YEAAHHH!!!!

Thanks guys; I no longer need to go write my own path tracer.

(I say this because I really like the idea of things like Chunky (the
pathtracer for Minecraft), but I'd rather be able to simply export data to a
more mature, full-featured renderer. Hierarchical instancing means you can do
things like make bricks out of grains of sand, make brick blocks out of
bricks, etc, without /necessarily/ blowing your memory budget when rendering a
large map.)

------
pasta
If you like this you also might like Luxrender. Also an open source physically
based render engine: [http://www.luxrender.net/](http://www.luxrender.net/)

------
wmccullough
This looks really beautiful. The fact that it's open source adds to that
beauty. I'm not even interested in physically based rendering and it makes me
want to play with it.

~~~
swerner
If you want to learn about state of the art rendering, check out pbrt.org.
Even without the book, the source code contains a wealth of information and
was written for teaching.

------
object_destroy
If you're into graphics pipelines, here's a few interesting videos of Gaffer
node networks rendering with Appleseed:
[http://www.gafferhq.org/demos/](http://www.gafferhq.org/demos/)

~~~
softwarelimits
how does gaffer compare to BMD Fusion? Thanks!

BTW it would be really great if the webmaster of gafferhq.org considered to
add some contrast to the parts of the website that should be read by visitors.

(aka [http://contrastrebellion.com/](http://contrastrebellion.com/) )

------
flixic
There are quite a few interesting options for 3D, what is the best thing for
2D? Fast open source 2d rendering engine? Is Skia pretty much the only option?

~~~
santaclaus
I've seen Cairo and Antigrain used in the wild for 2D rendering, too.

------
redpanda_ua
It's all cool and awesome, but why put all those resources into new renderer,
when one could contribute to Blender and such, which are way more mature?

~~~
hellofunk
Two points:

Blender is not a renderer, it's a modelling and animation program with a
built-in renderer, Cycles. But it can connect to other renderers, too.

Cycles is not that old. It replaced Blender's prior renderer just a few years
ago.

~~~
object_destroy
Appleseed has also been under active development for 7+ years; so not that
young, especially considering that physically-based renders really only
started coming into full production use 3-4 years ago. There are still many
visual effects studios using approximation-based setups today, so I'd say
there's lots of room for "new renderers" to carve their niche.

------
lawnchair_larry
Can someone Explain Like I'm Five: "Physically-based rendering"? As opposed
to...?

~~~
gribbly
Non-physically based rendering :)

Kidding aside, as I understand it (I'm certainly no expert), the terms most
often used are biased versus unbiased rendering, were biased has artificial
limitations, while unbiased employs 'real world' calculations.

So why use biased renderers ?

Well they can typically create a very good result using much less time
compared to a unbiased renderer, on the other hand they typically also require
that you mess around with a lot of knobs in order to get good results,
meanwhile with a unbiased renderer you can just set up a 'real world' scene
and it will render as such (albeit more slowly).

My guess is that Renderman is the most widely used biased renderer today, with
Arnold being the most used unbiased.

~~~
berkut
That's not really what 'biased' and 'unbiased' mean - unfortunately the terms
have been miss-used quite a bit, and are actually open to interpretation to a
degree anyway.

You can have biased physically-based rendering and you can have unbiased 'not
quite physically-based' rendering - in the latter case for example, it's
possible to render direct lighting only (so no secondary bounces, or global
illumination), which while obviously not the correct real result in physical
terms, to the extent that you're evaluating direct lighting only the result is
technically unbiased in terms of light transport. Similarly, it's possibly to
have a spectral renderer (which in theory should be more accurate) which is
biased, and a non-spectral renderer (RGB only) which is unbiased.

Biased can mean things like taking short-cuts or approximations - e.g.
irradiance caches for diffuse results, or caching occlusion in order to
slightly bias which light to sample per vertex in order to sample lights more
efficiently: Both of these biased techniques generally give faster less noisy
renders, but it's possible you might not notice they are biased in terms of
the effect they have on the render - it all depends on the scene, materials
and the lighting. For simple scenes you probably won't notice, for more
complex scenes with nested medium materials with glossy/pure specular
responses or with refractive caustics, it's very likely you will notice the
effects biased rendering has compared to unbiased rendering.

Renderman RIS can be set up to be unbiased (but with default settings -
radiance clamps) it's not. Similarly Arnold's default settings of having a
light threshold (under which it won't sample a light) is also biased, but
obviously this setting can be changed. Arnold can also cache diffuse
contributions on hair, which is also biased.

~~~
gribbly
Thanks for the correction!

------
softwarelimits
what happened with the Ramen compositor?

------
skratlo
No word on GPU acceleration?

------
kkapelon
The name clashes with a well known anime movie, which also uses CGI. Maybe
change the name of this engine?

~~~
franzb
Think of it has a homage! :)

~~~
franzb
( _as_ a homage, sorry)

