Given that my blog doesn't get updated much and there is no other obvious output, lots of people ask me what exactly I am working on at the moment and why it seems to be taking forever. Usually I just mutter the odd platitude, but today I thought I would combine a bit of a rant with an actual example of the kind of problems I am currently and seemingly constantly wrestling with. This one involves the ideal of determining NatHERS compliance directly from a fully integrated building information model (BIM).
PerformativeDesign.com has gone into a short code-freeze for some external testing now so I have finally got a bit of time to catch my breath. As part of that work, I have had to do quite a few small experiments and proofs-of-concept, just as a way of seeing what was possible and then working out the best ways to do various things. Some of these were a bit interesting and often a lot of fun so I thought I'd polish up a few and make them available as a small taster of things to come, hopefully quite soon.
I've been doing a fair bit of low-level optimisation work on my solar calculations code recently and, whilst I have a reasonably extensive test suite for it, nothing beats being able to actually see things in action and interactively put them through their paces. Also, I've been wanting to update my old Earth/Sun Relationship app for a while now with some new ideas and graphics, so the synthesis seemed pretty logical. Thus, I just finished a brand new version with lots of new features as a way of both examining and visualising the relationships involved and letting me test and validate the core code.
As I've mentioned in previous posts, I have been working on a graphical user interface and 3D modelling library in Processing for some time now. I originally chose Processing because it was truly cross-platform and the only tool that also supported embedded web applets. I got to a reasonably advanced state in v1.5.1 and then, of course, everything changed. Processing 2 moved entirely to OpenGL and completely abandoned web applets.
There are a plethora of WPF charting solutions out there, both commercial and open source. I have tried quite a few but have yet to find one that is capable of handling highly dynamic data whilst also providing useful customisations such as centered axis or generating polar diagrams. I do most of my dynamic charts in OpenGL but labelling axis and data points using textured fonts lacks some of the polish I have seen in many WPF-based solutions. Thus I thought that, for my Windows apps, I would try porting my OpenGL chart library to WPF.
My wife and I had a bouncing baby boy late last year and man, did he arrive like a shrieking banshee from hell. That was four months I hope never to experience again and, thanks to a serious and prolonged lack of REM sleep, I hope soon to forget. Like all new parents, you just dig in and pray for things to slowly get back to normal. However, with the passing of time comes the dawning realisation that this is the new normal. Even though I really liked my previous life, this post isn't a rant about that. It's about some of the things I've discovered about my new one.
As I have mentioned in a couple of other posts, I have been working on the API for a suite of building performance analysis classes, with a particular focus on dynamic visualisation and interactive manipulation. Part of this involves implementing an event notification system so that changes can propagate through even the most complex object hierarchies without the user having to worry about the internal plumbing. Unfortunately the standard approaches that I have found aren't particularly suitable here, so I have had to hack out something of my own.
Whilst working on an analysis library recently, I have been trying to reconcile how best to define positional and directional information. Most 3D frameworks and APIs use a single
Vector class (or similar) to define a generic object with X, Y and Z properties, which is then used interchangeably to describe both points in space and direction vectors. The closer I look, however, the more I think that it's important to clearly distinguish between the two and treat them as separate classes in an API in order to avoid inadvertent user mistakes. Unfortunately there is no single knock-out justification for either approach, so the following are some simple contemplations on the subject as I try to work out which way to go.
One of the projects I have been working on over the last few months is a graphical user-interface (GUI) library for Processing. The Java API to the library makes extensive use of sub-classing and the intention is that it be easily sub-classed by the end user to allow for deep customisation of its functionality. Deep customisation means allowing for any property in any of its classes to be easily overridden. Sounds trivial as this is what object-oriented programming and Java is all about, but it actually leads to an interesting code-design dilemma.
Technical illustrations and 3D graphs tend to need lots of different kinds of text - some bold/italic, some large/small, and often in a range of different colors or shades of grey. Having struggled with image-based font glyphs in 3D for ages, I've kinda had enough - so set out to develop my own parametric vector text in Processing/OpenGL. This applet is a demo of some of the types of 3D text object I've been playing with as well as some experiments with annotation arrows.
I recently upgraded to Reason 6 and had a bit of time over Christmas for some remixing and further experiments. Okay, I know what you are thinking, but I do have history here as I used to have a great MIDI setup in the late 80s and early 90s when I was a student. I've had Reason 4 for a while, but never the time to properly finish anything before. They're not everyone's cup of tea, but if you are interested in a little electronic music...
When interactively manipulating objects in 3D, having clear dimensions that update dynamically while dragging around allows for much greater confidence and accuracy in the process. This is especially true on a tablet where accurate alignment is well near impossible as your finger (and sometimes hand) effectively obscures the drag point. However, what started out as a quick experiment ended up sucking me into a 6 day vortex, swirling around with quaternion maths and 3D text manipulation in an attempt to get radial dimensions visible when viewed from any direction. This tiny applet is the result of those 6 days.
I have been struggling for a while in Processing with the reverse projection of 2D screen coordinates back into 3D world coordinates. It's relatively straightforward in OPENGL sketches using the JOGL view matrices and the GLU.gluUnproject() function. However, I could never get anything solid when using the P3D renderer or the PGraphics3D matrices. For some reason there was always a slight scaling issue which varied with different views. Previously I've used fudge factors to get it pretty close but, as I still prefer P3D for browser embedded work, I finally spent some time on it and made the breakthrough I needed. This is a brief description of what I learnt along the way as well as a demo applet and custom gluUnproject() function.
I have recently been building a small multi-node cluster of Mac Mini Servers as a development tool to explore some cloud services and parallel processing techniques. For this purpose, the Mac Mini is great as they are dead quiet, use very little power, boot with no problems without a keyboard, mouse or monitor attached and are easily set up to allow full remote management, configuration and screen sharing. For me the Server version is best as only they come with an Intel quad-core i7 CPU, giving effectively 8 processing nodes each. The CPU speed is a bit slower compared to the best non-server version (2.0MHz vs 2.7MHz), however the non-server version is only dual-core.
When dealing with complex analytical models, visually checking that all the spaces within a building have been generated correctly is never easy. This is because there are usually so many of them and their bounding surfaces are invariably adjacent to those of other spaces. You often wish that there was a way to 'explode' the building apart so you could see all of its constituent parts. Well, this the first of my experiments to do exactly that.