kaioa.com

A low poly spaceship

Without net access there wasn't much to do. However, modeling was one of the few things I actually could do. Fortunately I had some recent version of Wings3D installed. A few futile attempts later I got something that looked alright. Semi-satisfied with my low poly (52 polygons, 104 edges, 54 vertices) spaceship I went ahead texturing it with Inkscape.

Since the intended rendering size is rather small there isn't a need for fine details. I also wanted to try some bold semi-futuristic look with a touch of military blandness. Using vectors seemed like the most natural choice. Hard vector edges also fit the flat shaded rendering a lot better.

Before I could start with the texturing I had to do the UV mapping first. UV mapping is a bit annoying in Wings3D, but it's alright for simple models. If you aren't familiar with the term: it's about which part of the texture goes where on the model.

EeePC Tile Size Cheat Sheet (SVG)

The current EeePC generation uses the typical UMPC minimum resolution of 800x480 pixels. Accordingly to some rumors future generations will most likely use 1024x600. [Update: The resolution has been confirmed. The EeePC 900 has a 8.9" display with a resolution of 1024x600.]

As you can imagine this will cause some issues with full screen 2D games. One can always bi-linearly scale the sprites (or the whole back buffer/FBO), but the blurring may not be desired. After all it's plain ugly. Additionally, it may cause other side-effects such as color bleeding. That is: color values from one frame of the spritesheet may be mixed with the edges of neighbor frames, which causes visible artifacts such as seams or stray pixels.

Batik 1.7 comes with SMIL improvements (it's almost complete now) and some SVG 1.2 features were added as well. Check out the change log for details.

Batik is pretty much THE reference implementation. If an SVG doesn't work there, chances are very slim that it will work elsewhere. So, even if you aren't a Java developer get it anyways. The SVG-Viewer Squiggle (which is basically just a demo of the toolkit) is a great tool for doing quick cross-checks if the rendering isn't consistent between different browsers.

Intro

In this week's episode of I hate repeating myself I'll explain how to make Apache send the right headers. With the correct headers SVG and SVGZ can be displayed directly in all browsers which support it.

I'll try to keep it as brief as possible and as detailed as necessary. If there are any questions feel free to ask.

Testing

To check the current situation and to verify the results of our changes we need to know how the desired result should look like.

As you can see the Content-Type headers for SVG and SVGZ are identical, but SVGZ also comes with a Content-Encoding header, which is used by the client to determine how to decode the data.

Introduction

SVGs can be optimized for three different things. File size, rendering speed, and editing. For the most part you want to optimize for editing - especially with complex drawings. Towards the end you may want to lean toward the 2 other goals tho.

Optimizing for rendering speed is very interesting for devices with limited capabilities such as cellphones or PDAs. Things to keep an eye on are node counts, overdraw, clones, clipping, masking, gradients, and even simple stuff such as strokes. Nokia published some pretty decent guide (PDF) on this topic.

Optimizing for size shares a few aspects of the speed optimization. Keep the node count as low as possible, combine paths where possible... that kind of thing. However, you completely ignore overdraw, and you use clones/clipping/masking/stroke/gradients all over the place. It's certainly lot more entertaining than speed optimizations and it also won't affect editing speed that much. That's why I'll experiment with that.

I almost forgot to fix this. There was some silly bug, which caused the evaluated new color values to overwrite the old ones. E.g. if your red function changed the red channel and if you use the red channel in the green or blue function, the calculation was way off.

Well, this is fixed now. Finally you can do stuff like custom grayscale functions. For example if you don't like the NTSC/PAL scheme, which is used by Effects->Color->Grayscale, you can now use a different one. For the ITU-R Recommendation BT.709 conversion you would use the following line for all three channels:

0.2125 * r + 0.7154 * g + 0.0721 * b

For comparison the NTSC/PAL one looks like this:

0.299 * r + 0.587 * g + 0.114 * b

Feel free to try your own weights. You can also try slightly heavier weights in the red channel and a tad heavier weights in the green channel for sepia-ish pseudo grayscale. Or something completely different. Since the calculated values are clamped (0 to 255), there won't be any problems.

Thanks to Johan Engelen's bug fixing kung fu it's now possible to export ridiculous huge PNGs via command line. Thanks heaps mate! :)

I just exported some SVG at 524288x256 pixels. That's 512mb of raw data and it only took 45 seconds! That's really plain awesome.

The main reason why I wanted it so badly (sorry for the nagging Johan) is because wide images are faster to export than tall ones (see my previous post), and because slicing it up in only one direction simplifies the code of my yet to be released multi threaded export extension.

Inkscape 0.46 is going to be so sweet.

People often complained that their PNG export took bloody ages. At high resolutions and with some blur it sometimes took over 10 hours. That's really not nice. However, things improved a lot during the last few months, and whenever the issue arose I pointed people at the unstable SVN builds.

It was apparently noticeable faster, but I wasn't sure how much exactly, and there were no facts to backup my claims. That's why I decided to do some benchmarks on my own. I already had the framework for this from my multi core export extension tests. So, this was pretty easy to do.

The test machine was a AMD 64 X2 4200+ with 2GB of RAM.

With Blur

Used SVG: exp5.svg

Without Blur

Used SVG: exp5nb.svg

As I mentioned earlier the upcoming release of Opera 9.5 comes with 2 long awaited features: SVG as background-image (CSS), and SVG via <img/>. The alpha versions were buggy all over the place, but the freshly released beta seems to be pretty stable.

So, what is it good for? Good question. I also wondered about that. This is what I came up with:

svg_demo.html (screenshot)

Be sure to check out the the resize and zooming behavior. It's pretty nifty.

This is truly awesome stuff. The latest snapshot of Opera 9.50 allows you to use SVG in img elements and via CSS (demo) as well.

The Mozilla guys are also on this for a while. With some luck we'll see those features in Firefox in a few months, too. Unfortunately it looks like it will be somewhere after the FF3 release. I really hope that they'll hurry a bit with these features.