Archive for June, 2009

Flexing my 3D-muscle a bit again

Sunday, June 28th, 2009

I used to be a Linux-beta-tester of Realsoft3D long time ago. Even wrote a .r3i import-plugin for gimp once. I also got into RenderMan (RM), wanting to write a RM-binding (using RIB) for Realsoft3D. The RM-display-driver I got done and had RM (actually the free RM-implementation BMRT) render into Realsoft3D’s viewports. That was quite something! But as time went on, I watched blender accelerate in development and surpass numerous commercial 3D-suites in features… not to mention the user-community which formed behind it, after blender became OpenSource. It was obvious that Realsoft3D was a dead end for me, although I regard my CG/3D endeavours as a modest hobby at best.

Concepts for CG are the same, independent of the tools you use. Still, using fast and sophisticated tools makes your work/hobby more enjoyable. So I need to transfer my knowledge from Realsoft3D to blender. There are many disciplines in CG which you need to tackle, if you want to create good results. There’s the idea for an image or animation (which you need to cut into scenes to tell a captivating story), you need to build your characters/environment (modeling), then you need to “dress them up” (shading/texturing), the scene has to be properly lit (lighting) and you have to animate all of that (rigging/animation, sometimes involves physical simulation if you want to go the full stretch). All that is a huge pile of work, where I usually only enjoy the modeling-, shading- and lighting-parts.

Let’s get used to a new workflow then.

Thanks to Shawn Kirst’s normal-map plugin for Gimp 2.6.x, I created from this source color-map a derived bump-map and a derived specular-map. These put to use for a floor-material, together with a nice lighting setup in my scene, I get…

… as a result (it’s not about the monkey, but the lighting and floor-material).

Not photorealistic, but good enough to look decent. Such scene setups are commonly used to show off models you built in near life-like lighting-settings, without the need for hour long renderings. The above scene rendered in a couple of minutes on an intel Core 2 Duo (2.0 GHz) using the internal renderer of blender.

I also looked into luxrender, which is an unbiased renderer under the GPL, that comes with a blender-plugin. An unbiased renderer models its lighting calculations after the physical properties of light in the real world: wavelengths. It does not use a RGB-colormodel for its internal computations like many other renderers do. Furthermore the term “unbiased” means it does not make any assumptions or takes any shortcuts during the calculation. This has a huge advantage: true photorealism. The advantage comes at the cost of huge rendering times. An unbiased renderer is never done with an image-rendering. Instead it continues to improve it over time. After the first few seconds the image is very noisy and blocky. As it continues the noise gets finer and finer. You can let it go at an image until the noise resolution falls below the threshold of the images pixel-resolution. But that can take ages. What blender became for the 3D-suites in the OpenSource domain, luxrender will for the field of unbiased renderers I believe. I would not be surprised, to see it prosper as well as blender does. But luxrender has some tough commercial competition to beat Maxwell and indigo among a few others. Unbiased renderers are still new territory for me and I don’t wield this tool well yet, thus I don’t feel confident enough to show something in public right now.

Attention-to-detail ’till you bleed

Tuesday, June 23rd, 2009

It’s amazing what you can spend half a day on. But in the end it meant bugs got squashed and text in notifications should look more sound now. Now the interaction designers need to make up their mind what’s the best default width for a notification-bubble. So I provide them with a gazillion screenshots. Clicking on any one gives you the full screenshot, so one can see the bubbles size in relation to a typical desktop-screen size. Doing that for other form-factor screens (e.g. netbooks) they can do themselves :)

Visual results of recent work

Monday, June 22nd, 2009

What the urgency-level bar-display looks like (see also here):

Corrected throbbing and proximity-fade in action:

Last but not least here is a sneak peak of work-in-progress on better and faster blurring:

Finally…

Sunday, June 21st, 2009

… after the 10th iteration it built. Go and grab notify-osd - 0.9.14-0ubuntu1~ppa10 here.

I got a lot of feedback and help-advise from people over the last two days. Huge thanks for that! I tried it all, but what only worked in the end for me was this:

  • (fix the autotools problems, thanks again njpatel)
  • (verify they work locally)
  • (commit those to notify-osd trunk)
  • bzr branch lp:~ubuntu-desktop/notify-osd/ubuntu
  • bzr branch lp:notify-osd
  • cd ubuntu
  • bzr merge ../notify-osd
  • bzr commit
  • autoreconf
  • ./autogen.sh
  • dch -i
  • dpkg-buildpackage -S -sa
  • cd ..
  • dput my-ppa notify-osd_0.9.14-0ubuntu1~ppa10_source.changes

Also I had to get pbuilder up and running again to speed up those iteration cycles. That also took some time, to remember its usage and research the web for hints how to make best use of it.

  • pbuilder –create –distribution karmic (this takes ages)
  • sudo pbuilder –build notify-osd_0.9.14-0ubuntu1~ppa10.dsc

I think I should rename /var/cache/pbuilder/base.tgz to /var/cache/pbuilder/base-karmic.tgz and symlink it to base.tgz. Because in the future I will probably forget to do:

  • sudo pbuilder –login
  • (in the created chroot environment)
  • lsb_release -a

… to figure out what pbuilder distro-environment I’m I have. Then I also should remember this before using pbuilder again, to be on the save side:

  • sudo pbuilder –update

… and not be surprised if stuff which builds locally, will not build on the PPA-buildservers. Hm… that killed the symlink of course *sigh*.

My productivity goes out the window, when I have to do a release. Initially I assumed a realease means testing trunk, giving it a tag in bzr, creating tarballs with “make dist” and uploading them to launchpad. Then you get a “Just upload it to a PPA”. Well that little sentence turned out to be 2 days of overtime work. I wish I was a bit more like seb128, mvo or pitti, so “Just upload it to a PPA” really is just work for 30 minutes or so.

I’m can’t fix it, I’m to dumb

Saturday, June 20th, 2009

I keep getting this error from the PPA-buildsystem:

chmod: cannot access `/build/buildd/notify-osd-0.9.14/./configure’: No such file or directory

I don’t know how to correct that. I’ve tried it six times already. If you want to waste your weekend, please… be my guest:

bzr branch lp:~macslow/notify-osd/ubutu

If it ever builds…

Saturday, June 20th, 2009

In notify-osd trunk are things I’d like people under Karmic to get their hands on. Namely:

  • proximity-based fade-on-hover
  • debug-display bar for notification urgency-levels
  • corrected under- and overshoot behaviour of value-indicator

What you’ll get will look like this screencast. Due to the changes to the value-indicator you’ll also have to get new versions of g-s-d and g-p-m.

From my PPA you will need:

  • notify-osd 0.9.14
  • gnome-settings-daemon - 2.27.3-0ubuntu2~ppa1
  • gnome-power-manager - 2.27.1-0ubuntu4~ppa1

If you want to help out with identifying wrongly tagged notifications (in terms of urgency-level) start notify-osd with “DEBUG=1 /usr/lib/notify-osd/notify-osd”. That will give you this debug-bar display at the top. This is meant to gather data for the Do-Not-Disturb mode, where we want to filter the display of notifications based on their urgency-level and the state of the system (e.g. screensaver on, doing a presentation, watching movie). So if you run notify-osd with that thing on and then for example see a “Battery low” notification with low urgency, file a bug against the application which triggered this (hint: look in your ~/.cache/notify-osd.log). Thanks in advance!

If the world ends, it’s because of autotools!

Friday, June 19th, 2009

“Thanks” to the steaming pile of crap that is autotools, I’ve had some unproductive 6h of overtime today. It’s midnight and I need a break. Sorry, no notify-osd 0.9.14 today! :( Also “thanks” autotools for killing my motivation to do some weekend hacking.

path-drawing improved

Saturday, June 13th, 2009

I hooked up the cubic curve patch rendering to the preliminary cairo-path drawing. With it fonts look better now (compared to the first try).

The same clip on YouTube.

I feel happy now for the weekend :)

Brushed up math-skills

Friday, June 12th, 2009

That’s what I did over the last couple of days. The reason was following the Loop/Blinn paper on “Resolution Independent Curve Rendering using Programmable Graphics Hardware” turned out to be harder than I first thought. Implementing just quadratic curves segments is a piece of cake compared to cubic cuves (read: Bézier curves). The dynamic generation of 3D texture-coordinates to feed the fragment-shader evaluating the cubic curve inequality v3 - wt > 0 is nasty. But I’m seeing a light at the end of the tunnel… or rather this:

There’s still much left to be done (and many bugs to fix), but piece by piece it’s getting there. The same clip on YouTube.

While working on this I also had a look at what a cairo rendering-backend actually needs to implement. Sofar I did not find hooks in a backends callback table to just hand over paths from cairo. That’s a bit unfortunate, because that’s what I want to be able to grab from cairo. I don’t want the decomposition to triangles/trapezoids to happen in cairo itself (on the CPU). That’s meant for the GPU. Well, it’s still a good stretch to go before it is time to thoroughly think about such issues. I assume folks on the cairo mailing-list help me sort things out, once the time has come.

I still have a few (vacation) days left before work starts again on monday. Let’s see what I can motivate myself to accomplish until then.

Fast twirling text… for real!

Tuesday, June 2nd, 2009

Remember that old cairo-demo. These days twirling text can actually be edited in real-time:

The same clip on YouTube.