• The Hotline File Transfer Protocol v1.1.1.  I presume I was interested in, or actively doing, a third party Hotline client.  I did tend to make lots of data transfer clients back then (e.g. HTTP, FTP, even POP3 & SMTP).
• My little gallery of childhood toys & memorabilia.  I hadn’t forgotten about this per se, but it’d certainly been a long time since I’d look at it.  In hindsight I’m really glad I took the time to take these photos – most of this stuff is long gone now, so the photos are all the remains to pique my nostalgia.
• Apparently I discovered some ‘fix’ for Apple breaking dial-up modems in a Mac OS X Jaguar (10.2.4) update.  I vaguely recall that, though I’m pretty sure that’s not the only time I’ve had to fix stupid regressions in Mac OS X by reinstalling frameworks, kexts, etc from a prior OS build.  Sigh.
  • Here’s a second reference to the same thing.
• I’m listed in the National Park Foundation’s 2015 donor list.  I’m also in the 2016 one too, though it doesn’t show up in a web search [yet], and expect to be in the 2017 one as well.
  • If you’re interested, here’s the many ways you can contribute to the NPF too.  Not listed prominently, but relevant for others in the tech industry, is that you can donate stock without paying capital gains on it, while still receiving the tax benefits of the stock’s full, current market value.  I wish I’d known this years ago when I started doing non-trivial charitable giving. 😔
• Steven Troughton-Smith gives a call out to me (among others) in his little SceneKit demo program and his pretty impressive “OpenWorldTest” (i.e. Minecraft tech demo clone).  I don’t recall have any specific contribution, but way back when Steven & I did chat a bunch about SceneKit, and other topics.
  • It tickles me now, though I haven’t talked to Steven much in years, that his name appears increasingly often in pretty high profile places (e.g. the ATP podcast mentions him almost every episode lately).  He’s certainly made a name for himself.
  • Someone called “Taka Taka” has also run with OpenWorldTest a bit, to add VR support among other things.  Nothing to do with me any more than Steven’s original version – I mention it just because it’s cool.
• I’m cited in the USF Maritime Law Journal (alas a broken link as I write).  Yep, I’m a big mover & shaker in the legal circle… which is to say, Marisa had an article published there and thanked me for supporting her as she wrote it. 😉
  • And I get a mention on every single page on her website too, for taking one of the photos of her on it.  Booyah!
• In reference to my hacking on CoreGraphicsServices, Nat! (no other name given, as far as I can see) wrote a journal entry about how some people in the Apple community can be, well, wet towels.
• A bajillion years ago I wrote the Keychain Framework, a relatively clean ‘Cocoa’ (Objective-C & Foundation) framework that wrapped Apple’s C-based libraries for keychain access & basic security functionality (which is in turn an implementation & based on the CDSA ‘standard’ that nobody but Apple appears to have ever actually implemented).  Anyway, apparently it’s used in SQLEditor.  I’m pretty stoked – I sunk a spectacular amount of time into that framework, for very dubious benefit in hindsight. 😕
• And another old pet project that shows up is my Mailcash plug-in for Apple Mail.  This was an implementation of Hashcash, which I still think is a neat idea for reducing email spam, by making senders ‘pay’ for every email like a virtual stamp.  I have no idea if anyone ever really adopted it, nor if my Apple Mail plug-in still works at all.  Presumably not – I recall Apple Mail breaking plug-ins repeatedly over the last ten years or so, since I wrote Mailcash.
  • Oh how easy it is to date an open-source project when it’s still hosted on Sourceforge.  Poor, sad, lost-its-way Sourceforge.

Curiously, there’s several other open-source projects of mine on Sourceforge that don’t show up in a web search for my name:

• Build Installer, a template for software installers that build the software from source on the user’s machine – assuming they’ve installed Apple’s developer tools, that is.  From memory this was inspired by the tedious and error-prone nature of various open-source projects, w.r.t. how they distributed & installed their software on Mac OS X.  Sadly, nothing much has changed – there’s now brew & such package managers, but in my experience they make just as a big a mess as doing it manually & ad-hoc did.
• DePC, a tool for stripping files of those nasty DOS-based file extensions, and instead setting the files’ type & creator codes correctly.  Sigh… I lost that battle.  To this day I still think that was a bad choice, that Apple made, to cave in to file extensions.  They’re still ugly and error-prone.
• Mission to the ISS, the horrible group project I did with various folks in university, for the CSE32PRO (3rd-year Computer Science Project) class.  Back in 2004, I’d guess, based on the open-source release being in January 2005.  That was a fun project in many ways, though the end result was a bit embarrassing – we ran out of time, during the class, to actually finish it properly, so for example the underlying algorithms that control the simulation are fundamentally step-based, but are stepped every time the user provides any input, so high user interaction makes the simulation run faster than intended, with silly and sometimes outright broken results.  Sad panda.

Ugh.  SceneKit supports shaders, technically.  But it’s almost unequivocally unusable.  Let me count the reasons:

1. It doesn’t support geometry shaders at all.
2. There’s absolutely no example code anywhere on the web.  Certainly none from Apple.
3. There’s essentially zero documentation.  Not even from 3rd parties.
4. You must set both a fragment and a vertex shader on every SCNProgram.  This is actually documented, though poorly, and the behaviour is certainly not intuitive.  It’s not hard to write a “no-op” version of either, but it’s stupid and it exacerbates all the other issues below.

Those are just the warnings.  I should have paid heed.  Instead I decided to reverse-engineer it anyway.  Turns out it was a waste of time, because:

1. Once you start using shaders, you lose all the functionality of SceneKit.  The most obvious being textures, but it’s actually everything – geometry, projections, positions – everything.  Now you must load and bind everything manually.  Vertices must be fed into your shader manually.  Everything is manual.  No intrinsics, no built-ins.  Stupidly simple things like gl_Color and gl_ModelViewProjectionMatrix are considered arbitrary and treated as uniforms, that must be bound manually.  And to do so you have to implement an Objective-C delegate method, so your performance is going to be shit unless they utilise IMP caching, in which case it’s merely going to be terrible.  I don’t understand how this could possibly be made to work.
2. Your shader is compiled not only once for every single material it’s used on, but plus 50 percent.  i.e. if you create a single SCNProgram and assign it to 100 distinct SCNMaterials (each on their own unique SCNNode), SceneKit will compile both the vertex & fragment shaders 150 times each.  This only makes sense when you consider it in the context of the above observation; all the SceneKit objects your shaders happen to hang off are completely irrelevant.  So of course each use is treated as a completely independent shader, because each one has to be completely setup manually.  Though I have no idea what the extra 50% are about.
3. Since your shader is not shared between materials or nodes, it gets set up and torn down once for every single drawable.  Every SCNNode.  So you get ~twenty OpenGL calls minimum per drawable.  Admittedly some of these are SceneKits usual drawing commands, but most are related to the shader, and include gems like resetting the blend function every single time, and glMatrixMode + glPopMatrix + glMatrixMode + glPushMatrix in sequence, repeated, for the same matrix & value (the identity matrix, naturally).

As far as I can tell, if you want to use any shaders at all, you can’t use SceneKit.

Unfortunately, it turns out frequently recreating that geometry (as is necessary each time you change the segmentCount of an SCNSphere) is not cheap.  So I went from a consistent but low frame rate to a fast but wildly varying frame rate – with stutters of a second or more at a time.  Ick.  It seems the GPU can handle that – the bandwidth involved is pretty tiny, and I don’t have any relevant latency concerns [yet], but the CPU cost is substantial.

An obvious thought is to create multiple versions of each sphere, one for each desired segmentCount, and then swap them in and out on demand.  This does actually work “fine”, though I worry about its efficiency – I haven’t yet measured the RAM cost of the cached geometry, let alone what impact it might have on the OpenGL side (e.g. does it store every one in an FBO for the lifetime of the SCNSphere? OpenGL Profiler shows a lot of FBOs active at one time).

The best solution would probably be a geometry shader to perform the generation on the fly (or tessellation in some form).  Unfortunately SceneKit doesn’t currently support geometry shaders.

It’s interesting that when not layer-backed, all that happens is that the SCNView draws over any overlapping views.  If its background colour is transparent you can actually see the views overlapping it.  In any case, they can receive events just fine.

Tangentially, that you can use translucency to reveal other views “underneath” your SCNView is interesting.  You could use it to present a relatively fixed backdrop for your 3D world, for example, rather than having to deal with actual SCNNodes and camera movement and all that.

It does appear to do it from the main runloop at least, as documented. So there is technically a delay, as a consequence of that scheduling. Not helpful though.

Update: turns out that you have to set the completion block before calling +[SCNTransaction begin].  Grrr.  Undocumented behaviour #bajillion+1.

Update:  rdar://problem/12758940

NSDate *nextFrameCounterReset;
NSUInteger frameCount;

- (void)draw {
    NSDate *now = [NSDate date];

    if (nextFrameCounterReset) {
        if (NSOrderedDescending == [now compare:nextFrameCounterReset]) {
            [frameRateView setLabel:frameCount];
            frameCount = 0;
            nextFrameCounterReset = [now dateByAddingTimeInterval:1.0];
        }
    } else {
        nextFrameCounterReset = [now dateByAddingTimeInterval:1.0];
    }

    ++frameCount;

    [super draw];
}

Update:
However, if you’re layer-backed the “draw” method isn’t used. Instead you can override:

- (void)drawInBackingLayerWithCGLContext:(CGLContextObj)arg1;

Like so:

NSDate *nextFrameCounterReset;
NSUInteger frameCount;

- (void)drawInBackingLayerWithCGLContext:(CGLContextObj)arg1 {
    NSDate *now = [NSDate date];

    if (nextFrameCounterReset) {
        if (NSOrderedDescending == [now compare:nextFrameCounterReset]) {
            [frameRateView setLabel:frameCount];
            frameCount = 0;
            nextFrameCounterReset = [now dateByAddingTimeInterval:1.0];
        }
    } else {
        nextFrameCounterReset = [now dateByAddingTimeInterval:1.0];
    }

    ++frameCount;

    [super draw];
}

But don’t. Because in actual fact you can get this information via supported API – the SCNSceneRendererDelegate protocol.  You can register your view as its own delegate, or put your frame rate calculation in another object.  Either way, your code should look something like:

NSDate *nextFrameCounterReset;
NSUInteger frameCount;

- (void)renderer:(id<SCNSceneRenderer>)aRenderer
  didRenderScene:(SCNScene*)scene
          atTime:(NSTimeInterval)time {
    NSDate *now = [NSDate date];

    if (nextFrameCounterReset) {
        if (NSOrderedDescending == [now compare:nextFrameCounterReset]) {
            [frameRateView setLabel:frameCount];
            frameCount = 0;
            nextFrameCounterReset = [now dateByAddingTimeInterval:1.0];
        }
    } else {
        nextFrameCounterReset = [now dateByAddingTimeInterval:1.0];
    }

    ++frameCount;

    [super draw];
}

It doesn’t appear to have any performance impact though, oddly.  At least not in fairly trivial scenes.  It might be that it uses more RAM (and VRAM) for the duplicates behind the scenes; the geometry in my testing isn’t complicated enough for that to matter.

So amongst the many strange, undocumented foibles it has, one in particular is quite egregious.  When you add an SCNNode to your SCNView-rendered scene, containing an SCNCamera, the pointOfView property of the SCNView is magically updated to point to it.  Pretty cool.  I’m not sure when – not when it’s added to the scene, that’s for sure… perhaps when the scene next draws, and find it doesn’t have a pointOfView assigned yet?

Anyway, so far so good.  What’s not good is when you switch apps and come back to find your camera hasn’t visibly moved – your scene renders as you left it – yet none of your camera controls work anymore.  WTF?  An hour of NSLogs and lldb tedium later, and I discover that the pointOfView has been “magically” changed to some other node.  This other node doesn’t appear in the scene, wasn’t created by me, still has my SCNCamera attached to it – I hope it’s not fighting with my real SCNNode, which still thinks it owns the camera – and has no identity other than the name kSCNFreeViewCameraName.

What’s weirdest in all this is that it only happens if you switch apps in a certain way.  Command-tab or clicking on another window won’t do it, but clicking on an app in the dock will.  WTF?

Update: this only happens if the “Allow Camera Control” property is set on the SCNView.  It appears it’s not the changing of apps or focus or anything else that triggers this bug – perhaps better dubbed “a deliberate but poor design choice”, given this new information – but rather a mouse event arriving at the view.  I’m not sure how you’re supposed to deal with that… I guess if you’re doing any custom camera work yourself, you’ll just have to turn that property off.