Things you find googling yourself

In no particular order.

  • 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.
  • 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.
  • 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. 😉
  • 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.

SceneKit & shaders

Note: Since writing this originally I’ve figured out how to get at least some aspects of shaders working.  I’m still trying to flesh out the rest.  I’ll post an update or revised entry at some point.

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.

SCNSphere can be expensive to recreate

In a current project I’m drawing hundreds of spheres, of varying sizes.  I discovered at one point that with them all in view simultaneously, performance was very bad (<10 FPS on my 6970M).  Trial and error revealed that changing the geometry complexity – by changing the segment count of my spheres – made a huge difference.  Seems logical.

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.