I have been playing around with distance field rendering, inspired by some of Iñigo Quílez’s work. Along the way I needed to define analytic distance functions for a number of fairly esoteric geometric primitives, among them the logarithmic spiral:
New in this version:
- Support for multiple windows
- Java-style flow layout
- Full batching
- Numerous performance enhancements and bug fixes
- Minor theme tweaks
- setuptools/easy_install support
Given the speed of development, simplui has moved to its own googlecode project:
You can obtain the source from Mercurial, or download the binary package there.
In addition, simplui has been integrated with setuptools/easy_install. You can find the package listing in the PyPI directory (here), or you can install immediately with easy_install:
(note that easy_install will not install the demo application and themes)
This release does come complete with a few of caveats:
- simplui is only compatible with pyglet 1.1 maintenance – not the experimental version in trunk
- There is a bug in pyglet 1.1.3 which can cause crashes if un-patched.
- On Mac OS X, you may need to upgrade setuptools (sudo easy_install -s /usr/bin setuptools)
Various things have been snowballing recently, with the result that both development and blogging have fallen by the wayside. A few interesting things are happening however, take a look and see for yourself, after the jump…
No major features this time, instead a slew of small bug fixes, an update to the API, and the rendering code has been rewritten for performance (primarily though batching).
I wasn’t intending to push a release out until more features were added, so consider this a maintenance release.
Today brings the 1.0.2 release of simplui. This is a beta release, previewing major enhancements, and I need as much feedback as possible on the new features. As such, this release isn’t heavily optimised – that is on the wishlist for next release.
The big news for this release is themes support. The GUI is now fully skinned, using a variant on the ninepatch method code developed by Joe Wreschnig and Alex Holkner on the pyglet mailing list.
Each GUI frame can use a different theme (even in the same time!), and the theme can be changed at runtime. I have included two sample themes, one modelled on the Mac OS X ‘Aqua’ interface, and the other on the PyWidget GUI toolkit.
Also included are the usual crop of bug-fixes, including the squashing (hopefully for the last time) of the persistent event clipping bug.
I just posted a quick youtube video to demonstrate the current state of the planet renderer. This is early development stuff, and the eye candy is minimal, but it should give you some idea of the scope.
I will follow up with a more technical blog post in the next few days, explaining all that is going on behind the scenes, and can’t be seen in a video.
Part of the rationale behind this video is to stremline the whole video capture and posting process. Unfortunately, it hasn’t been entirely straightforward so far. I went through a number of video capture tools before settling on FRAPS, which works well enough (though I would have prefered a free tool).
I also have had a terrible time converting the video for youtube – ATI’s Avivo video converter is blazingly fast, but apparently produces an incompatibe audio codec in any of the high-quality settings. I was forced to fall back to the CPU-based Auto Gordian Knot, which both does a worse job, is very slow on my little Athalon 64 x2.
I am now experimenting with ffmpeg, but the command line options are confusing to say the least. If anyone has any clues/tips/tricks for getting FRAPS encoded video (and audio) into a suitable format for youtube HD, please let me know.
I am going to be performing a number of small releases for simplui over the next few weeks, as features are added and bugs are patched.
Today’s 1.0.1 release introduces a slider control, docstrings for all widget constructors detailing the keyword arguments, and a couple of bug fixes.
If anyone feels like taking it for a spin, I could do with bug reports and feedback on the API.
I like pyglet a lot. Much more than a lot.
However, the lack of a compelling GUI toolkit for development purposes has been a major irritation of late. This week I finally sat down and wrote my own GUI toolkit, from scratch, and I am happy enough with the way it works to release a first version to the public.
There have been a couple of requests here and on the pyglet mailing list for my code to perform pixel-perfect sprite collisions. I finally had a bit of down time, post-exams, and put together a demo, complete with source code.
The source is pretty clear, and thoroughly commented, so it should be very easy to follow. The demo is very simple, but the concept translates to more complex applications as well.
Let me know if you have any issues, or questions about the source, and note that it does require a fairly recent version of python (2.5+, for generator expressions and the built-in set class).
The semester is over at last, and my grades should be in by Monday. It has been a tiring semester, but not a bad one, with interesting courses in database implementation and parallel architectures, not to mention philosophy.
With the end of the semester comes a little more free time, and I have spent a chunk of it recreating my old procedural planet demo in Python/Pyglet.
The first big plus is that whereas my previous implementation was over 5,000 lines of C++ code, the python version is under 1,000 loc, plus a few hundred lines of tightly optimised C for the tile generation back end.
The other plus is that this version actually works. I finally found the time to fully implement the crack fixing algorithm, and the results are very good (although there are still a couple of unresolved edge cases).
I also implemented normal map generation in GLSL, to offload the computation to the GPU. This more than doubles the performance of tile generation, to the point where several tiles can be subdivided or combined each frame.
From a technical standpoint, the planet starts as a cube, and each face is subdivided to form a quad tree. For each tile at the deepest level of the quad tree, a small heightmap is generated using 32 octaves of 3-dimensional simplex noise. This heightmap is used to generate the vertices for the tile, and passed as a texture to the GPU in order to generate the normal map.
Because applying tangent-space normal maps to a sphere is an absolute nightmare, I take the unusual approach of generating object-space normal maps. These are considerably more expensive to generate, but avoid the tangent-space mismatch at cube edges, and look fairly decent in practice.
Interestingly, this version allows one to fly right down to the planet surface, and maintains interactive framerates even on my Intel integrated X3100 (complete with the awful Mac drivers). By the time I add atmosphere shaders and detail textures, I expect that I will have to switch over to my desktop, but for now, I am very happy with the performance.
Of course, there are still several challenges to overcome, in particular the issue of depth buffer precision. The planet you see above does not suffer from a lack of depth buffer precision, but it is only 1/10 scale of the Earth, and ideally I would like to be able to render gas giants on the order of Jupiter as well. This requires some clever on-the-fly adjustment of the camera frustum, and I don’t quite have a handle on the best way to accomplish it.