Gentoo Archives: gentoo-dev

From: Sebastian Pipping <sping@g.o>
To: gentoo-dev@l.g.o
Cc: trustees@g.o
Subject: [gentoo-dev] [rfc] Rendering the official Gentoo logo / Blender 2.04, Python 2.2
Date: Fri, 29 Apr 2011 00:30:28

Gentoo's official logo originates from a Blender file [1] created by
Daniel Robbis over 8 years ago.  He used Blender 2.04 and Python 1.6 at
that time.

When rendering that .blend file with Blender 2.49b (or a more recent
version), Blender does not apply the reflection texture needed [2] to
give the metal look that you know.  I don't know why that is.  All I
know is that Blender does find the file: it's not about the location.

Trying Blender 2.04 binaries on a Windows VM, it turned out that Blender
2.04 is still able to render our logo as expected.  In my eyes rendering
our logo should not depend on a proprietary operating system or binary
blobs.  The source tarball of Blender 2.04 is hard to find (if available
at all), the available sources of 2.03 [7] are incomplete.  Binaries of
2.04 [8] are 32bit only and crash on startup on my system.

The earliest source tarball after 2.04 that upstream offers for download
[3] is Blender 2.26.  That version does not compile with GCC 4.4 and
turns out to be home with Python 2.2.  In hope that this version would
be able to render our logo in the way that Blender 2.04 did, I tried
fixing compilation against GCC 4.4.5.  That worked [4].  The need for
Python 2.2 became clear when all of Python 2.4, 2.4 and 2.6 made it
segfault in Python related code instantly.  Therefore I tried bringing
our old Python 2.2-r7 ebuild to life.  Smaller changes like -fPIC were
needed but it wasn't too hard.  You can find the Python 2.2-r8 in the
betagarden overlay [6].  In the end I could do

  sudo eselect python set python2.2

to compile and run Blender 2.26 and make it render g-metal.blend (after
adjusting the path to the reflection texture) with metal look in a
resolution of a few megapixel on transparent background.
I have the impression, that the rending is the same as of Blender 2.04.

However, this is not a good long-term solution.  For instance Portage
doesn't operate under Python 2.2 so an ebuild for Blender 2.25 is a
tricky thing to do nowadays.

Among the options I see is the following:

 A) Find out how to render g-metal.blend with recent Blender
    (2.57b at best) to give pixel-identical results to Blender 2.04.
    Needs an advanced Blender user ideally.

 B) Port Blender 2.26 to a recent version of Python.

Are there any other options?

What do you think?

I would also like to encourage you to reproduce the process I described
to spot any problems I overlooked.

Thanks for reading up to this point.