Tag Archives: design

Personal Tech Web

Blog revamp

As I promised, I’ve given this blog a bit of an overhaul in anticipation of posting more often again. For those who are interested, here’s a run-down of the updates:

  1. New responsive design
    Responsive design is all the rage these days; in summary, it’s all about making your site adapt fluidly to the reading environment so it looks good on a variety of devices, even resizing images so they always fit. Try resizing your browser window, and you’ll see that the layout adapts, dropping the sidebar when it gets too thin and so on. I’d love to take credit for it, but monkeying about with CSS is one of my least favourite things in the world so I just used/tweaked an existing theme which took my fancy. Clearly, I’m in a minimalist phase right now.
  2. Commenting via Disqus
    Previously I’d used the standard WordPress commenting system plus a reCAPTCHA plugin to cut down on spam. That worked well enough, but Disqus has some advantages, chief of which is that you can comment using existing accounts such as Twitter, Google, OpenID and Facebook, which is much faster and frictionless. Also if you have a Disqus account, it collates all your comments across all websites so you can reference them more easily – I’ve found this useful myself in the past if I’ve commented on a post I found on Twitter and then forgot where it was. Importing all the blog’s existing comments to Disqus was easy, and allegedly all comments in future will be stored in both places (edit: confirmed, this is working), so you don’t have to worry about being exposed to external data loss, you always have all the comments in your own database too.
  3. Replaced many scattered plugins with Jetpack
    I used to use a bunch of different plugins for twitter feeds, subscriptions and social sharing buttons, but then I found Jetpack, which packages a bunch of them in one plugin.  Seems to work well, and it beats having to upgrade a bunch of separate plugins.

So, I hope you like the new design. Apologies for any lingering issues, I’m sure there will be some tweaks to do in the coming days but generally I think it’s a big improvement.

Development OGRE

SpatialGraph, SceneTree, RenderQueue – sound familiar?

I was quite gratified to read this post on Wolfgang Engel’s blog, in which he refers to some other posts discussing the recommended categorisation & nomenclature for the various stages / structures of scene rendering. If you read it and you’re an OGRE user, you’ll find them all rather familiar concepts, because OGRE has been based around these principles for years :)

“SpatialGraph: used for finding out what is visible and should be drawn. Should make culling fast”

That’s our SceneManager and it’s subclasses. One of the core tenets of my design for OGRE from day 1 was that the mechanism for performing fast culling should be customisable based on the scene type independent of the scene content, and therefore be able to be divorced from, but derived from, the primary scene structure (the SceneTree, see below). While other engines either tended to hardcode their culling strategy, or retrofit it into the ‘main’ scene graph as custom node types (which tends to encourage the ‘parallel inheritance hierarchy’ anti-pattern, because you mostly specialise nodes for other reasons too, and also makes macro-level decisions difficult), specialised SceneManagers build separate and derived culling structures which are entirely theirs to own.

“SceneTree: used for hierarchical animations, e.g. skeletal animation or a sword held in a character’s hand”

That’s easy – that’s our Node and all it’s subclasses like Bone and SceneNode. It’s rare for an engine not to have this concept, but too many engines make these nodes do too much IMO – like holding material state, being derived for custom culling routines, etc. I’ve always liked the idea of keeping the focus of a class tight (the principle of cohesion), it tends to work better long-term.

“RenderQueue: is filled by the SpatialGraph. Renders visible stuff fast. It sorts sub arrays per key, each key holding data such as depth, shaderID etc.”

Yep, we have exactly this structure and unsurprisingly it’s called RenderQueue :) We have the concept of queue groups for user-customisable ‘fire breaks’ between rendered objects, and the ability to sort by pass, by distance, or via a custom RenderQueueInvocationSequence.

It’s nice to read posts like this – makes me think we’ve been doing things the right way :)