Time for another Interlude, wherein I take a break from my career journey and reflect on what we're doing. I say we, not because I have been taken by delusions of royalty, but because there is more than just me involved now, as you will find out below, in the second half of this post.

It occurred to me the other day that I am developing alternate reality software. And what, I hear you cry, do I mean by that?

I have been a science fiction fan ever since I can remember. I was a nerdy kid who watched “Star Trek (TOS)”, “Lost in Space”, and “Land of the Giants” on TV. I read all the science fiction I could get my hands on. Later in life I even wrote stories for SF movies, and created an SF TV show which was never picked up. If I were an optimist, I would say “has not yet been picked up.”

One of the subgenres of science fiction is alternate reality (aka alternate history), where history took a different turn from our world. The most famous example is probably Philip K Dick's novel “The Man in the High Castle”, where the Axis powers are victorious in World War II and partition the USA.

From a purely practical point of view, the software we are developing does not make much sense. Common Lisp is a niche language, with very weak support for graphics and graphical user interfaces, and mediocre tooling at best.

No one has really tried doing serious computer graphics and animation with Common Lisp in the past 30 years. It may be seen by some as a quixotic quest at best. But in an alternate reality, one in which Common Lisp retained its popularity and remained a mainstream language, this development effort would make perfect sense.

For me, the most fun part of writing science fiction is the world building. Pure imagination running free. So let's engage in a few scenarios in which Common Lisp could be a mainstream language today.

Scenario one: the US does not get involved in the Vietnam war, there is no budget deficit, and ARPA funding for computer science academic research is not cut. Well-funded Lisp-based projects continue and prosper.

Scenario two: AT&T does not sign a decree with the US government which forces Bell Labs to give away the UNIX source code for free. Instead AT&T tries to sell UNIX as a commercial operating system, becoming just one of many such vendors. Unix’s popularity (and therefore that of C/C++) is curtailed and it does not take over the world. Lisp Machines and a variety of other operating systems survive in this ecosystem.

Scenario three: the government decides that instead of inventing a new language known as ADA, it will require Common Lisp as the standard language for government and military work. Common Lisp becomes a mainstay of government contract work and ensures a steady supply of funding and Lisp development opportunities. (Yeah, I know, this one is kind of out there.)

In these scenarios (and if you buy me a coffee I can come up with a half a dozen other ones), Lisp trudges along nicely, perhaps along with Fortran, Cobol, and C/C++.

That is the software we are writing. The one that comes out of these timelines. One where people naturally expect their software to be extensible and customizable and programmable, and not regularly crash due to things like buffer overflows.

I can dream. It's one of the perks of being a science-fiction fan.

Code & Design

When I start a project, I make a "to do" list. This list always grows much faster than I can actually get the enumerated items on it accomplished. I use it to keep track of features, ideas, or even just vague notions of what I might want to do or work on. When I am done implementing one of these items, it will go on the "done" section. The listing above is that section for my graphics project, and represents several months worth of work.

The to do list remains well-populated and represents a lot of work for us. Yes, us. I have gone ahead and publicly announced this system as an open source project. As a result, a small team is gathering around and we are planning the future development of the system.

It was always my hope that this project would grow beyond a personal endeavor of mine into something that could have some real world impact. Not sure what that impact might be yet, but the first step is to get into the hands of people, both artists and developers, who can use it. So our first task is to port the system beyond the Macintosh, to Linux and Windows platforms. Currently work in progress.

If I were to be honest, and that is something I try to do in this blog (otherwise what is the point), I would have to admit that I am equal parts nervous and excited. I had kept putting off making the open-source announcement, but then I remembered a quote I read somewhere to the effect that the biggest mistake we can make is to wait until we think we are ready. So I wondered what I was waiting for. I am not getting any younger. Just get the ball rolling and see what happens.

For those who are geeky enough to want to see the project on Github, here is a link.

While the filming for Encounter was in pre-production, I had started work on the graphics for the game. What today we would call the assets.

Using a Power Mac 9500, I modeled the spaceship interiors for the QuickTime VR scenes. Multiple renderings of each scene were done and stitched together to create 360-degree panoramas.

Once the video footage was edited, the scenes were composited on CG backgrounds and all the assets, complete with some basic gameplay, were assembled into a demo of the game using Macromedia Director.

I recall using a multiple-brick-sized external hard drive with a massive 9GB capacity to store the game assets and video files.

John and I travelled to the E3 (Electronic Entertainment Expo) in LA (either 1996 or 1997) to meet with potential distributors. We returned to Montreal without any serious leads, and around that time the production company which had been bankrolling our project ran into financial troubles.

So another of my projects got mothballed, though recently John was kind enough to send me a copy of the screenplay and artwork for the game, which I had lost in the house fire. Never at a loss for crazy ideas, it has occurred to me that Encounter would make an excellent VR game! Now I just need to assemble a team and find investors. Cue maniacal laughter.

Not for the first time, my life and career would take a major turn with a phone call. This time from Honolulu.

Code & Design

The above listing shows some of the macros whose output I showed last time. I have found that having a GUI, rudimentary as it may be, does allow me to more easily explore the possibilities of the system. It also has allowed me to give the first ever demo of the system, an event which was recorded and can be seen here.

Yes, so late in life I have created a YouTube channel. Kind of like being dragged kicking and screaming into the 21st century. Perhaps unexpected from a guy who develops software in a half-century-old language, but the fame and fortune of celebrity culture proved too tempting. It can't be far behind. Can it?

Once I created the channel, I began thinking of the Common Lisp lessons which launched this whole to-do, and how it had been suggested that I make videos of them.

So after my usual overthinking — no one will want to watch this! — that’s what I have been doing recently.

I downloaded some screen recording software, the kind that allows you to record a video of yourself, reworked the lessons, and went for it. The whole “should I record video of myself?” question stymied me for a while, but here you have it, in glorious 21st-century digital video: my face on YouTube. Enjoy.

Next Episode

John, my producer, rounded up a first rate crew and talented local actors for the video production the game would require. Given his experience as a commercial producer, he had many connections. He also booked a sound stage for the one-day shoot, and we had props and wardrobe made.

My downstairs neighbor at the time worked in wardrobe for the film industry, so she made us custom spaceship crew uniforms based on the excellent concept art, and they looked as good as anything in the movie “Alien”, which was a favorite of mine and a touchstone for the project.

I remember having a surreal feeling as we began our table read of the screenplay. This was the first time I had heard actors speak my words. But by the end of the read, hearing my words spoken aloud felt natural.

As a first-time director, I was in John’s capable hands. We had meetings with the DP and production designer, and he scheduled and arranged everything.

On the day of the shoot, everything went as well as I could have hoped for. The crew and actors were wonderful, upbeat, and professional. We shot on schedule and wrapped on time.

For the technically inclined, we shot on D1 format digital video, with eye to needing to do green screen in post production.

I had discovered a new venue for storytelling, and the desire to write and direct films was one which would stay with me for the next twenty years.

Code & Design

Writing GUI code such as dialog boxes for creating and editing objects typically involves a lot of boilerplate code. To me, this calls for Common Lisp macros supported by the language’s introspection and reflection facilities.

Macros are often touted as one of Lisp’s biggest strengths, due to the homoiconicity of the language. That’s a ten cent word which describes a language where the code is also data, and can be processed and generated using macros. Another term for this is metaprogramming, another fine high-value word.

I find writing macros satisfying and somewhat nerve wracking at the same time. As I start diving into deeper and deeper macro code, I can't help but wonder whether I'm doing the correct thing or just creating highly obfuscated code which I will be unable to understand two weeks from now.

In the listing above, the first line (in bold) is a macro call which generates the two functions below it. The macro takes a class name, a list of slot names and types, and produces the code for both the object creation and editing dialogs.

I find it hard to resist the urge to keep going deeper with macros. There is always more the computer can figure out and more ways of generalizing the code it writes. For example, in the case above if I were to specify types for the slots in the class definitions of the shapes, the macro could look those up and I wouldn't need to specify them myself.

The real satisfaction comes once the macros are written and debugged, and I can just type:

(make-create-and-edit-shape-dialogs sine-curve-shape 
                                    ((y-scale float)
                                     (x-scale float)
                                     (frequency float)
                                     (period float)
                                     (num-points integer)))

and several pages of code are generated behind the scenes, implementing two new dialog boxes for the sine-curve-shape class with no additional effort on my part.

The feeling I have when I use macros is that of telling the computer what I want and having the computer do the work for me. Like having an assistant in the computer. Makes me feel kind of spoiled. And yet it also feels right somehow, as if that is how things are meant to be.

I also wanted to point out this line of code, which makes use of CLOS’s introspection abilities:

(SLOT-DEFINITION-INITFORM (FIND-CLASS-SLOT 'CIRCLE-SHAPE 'DIAMETER))

This code is used in the object creation dialog, and gets the default value of the diameter slot from the class definition of circle-shape.

This illustrates an important point about Common Lisp: its power doesn’t just come from isolated features, but from the way in which the features have been designed to work together. The power of the language is greater than the sum of the powers of its parts.

And this reflects well on the language standard, showing how well thought out it is.

Next Episode

In the mid-90’s, Apple's QuickTime VR was a hot new technology. Around the same time, Myst was the hot CD-ROM game.

So of course I decided to make a CD-ROM computer game based on QuickTime VR. It would combine what we used to call FMV (full motion video) and 3D CG environments with QTVR scenes.

I wrote what I thought (and still think) was an interesting and original science fiction story for the game. The player character boards an apparently abandoned spaceship and has to figure how to bring its systems back to life by traveling between various QTVR nodes representing key locations on board the ship. As he does so, snippets of video intrude on his consciousness, which may or may not be showing him what happened to the crew. The whole thing ends with major revelations, plot twists, and bravura storytelling. Great stuff, if I may toot my own horn.

For the project, which was called “Encounter”, I teamed up with my producer friend John and we got some investment from a local Montreal production company. Enough to produce a demo of the game.

We bought a Power Mac 9500, some 3D modeling and rendering software (FormZ), Macromedia Director and got down to work.

While I spent my days modeling 3D environments based on the (very cool) concept art created for the game, John began putting together a production crew and casting actors in preparation for shooting the video footage we were going to green screen into the CG spaceship scenes.

This would be my first time directing actors. Live ones, not computer generated.

Code & Design

Warning: this post may induce (more) pearl clutching if you care about code efficiency.

I ran the profiler on the sweep-mesh-group depicted in the image above, and the results, after some minor optimizations, are listed here.

The actual scene takes about 2 seconds to update. The rest of the time is profiling overhead (probably including swap overhead and what have you). Spinning beachball action was definitely observed.

The minor optimizations resulted in about a 2x speed up, which shows that the code is (as I knew) far from being optimized. In fact as I suspected there is significant observable overhead from the point and color data structures. At least 20%, and probably more.

I could use declarations for inlining and types, as well as reduce consing. I suspect a lot of unnecessary consing is taking place because of the prevalent use of lists due to the pedagogical roots of the software. Replacing these with arrays could help reduce consing.

Finally, there is the option of implementing points and matrices as C libraries, though that will complicate memory management and result in dealing with FFI (foreign function interface) cruft. I’ll probably refrain from doing that.

In fact, I will probably defer further optimization until (someday) I reorganize the code in a major way, possibly by changing Common Lisp implementations in the process. Stay tuned.

Next Episode

I wanted to be organized, so as I wrote the screenplay for “Two Knights Defense”, I started putting parentheses around the text and before long my story was encoded as Lisp structures. Nested lists, to be precise.

The next obvious step was to write some scripts to process the structures. And by scripts I mean MCL Common Lisp code. The advantage of having a handy REPL, allowing for rapid development. Treating the story as a simple database, I wrote functions which would, for example, extract all the shots for a given location.

And that gave me my shot list for a given day's shoot. Easy peasy. Though not primarily graphics oriented, I’m still going to call this Lisp Graphics System 4 (LGS-4), as it did render out HTML pages.

As I have mentioned, the actual shoots were very smooth and productive, thanks to a great team.

After a day’s shoot, I would grab frames from the camcorder on my Mac, at a resolution of 640x480 pixels. I’d store the images as numbered files in the correct subfolder for each episode, and run the Photoshop watercolor filter on them as a batch action, resizing them down to 320x240 pixels in the process, which was “web sized” back then.

Finally, some more MCL code I wrote would generate the HTML pages of the graphic novel, with each page being a panel (image) with a dialog caption and navigation buttons. And the episode of the graphic novel was then ready to upload to a web server, for public viewing.

Which I never did…

Like most of my entrepreneurial projects, this one failed to take off. And for the life of me I can’t remember why I didn't follow through. I can only suppose that somehow I became convinced that the project could not succeed and put it aside. I have (to my regret) been very good at convincing myself of that. I do know that I had no business plan (as usual), and was hoping something would happen when I posted the content.

It irks me to no end that I don't have more confidence in myself and my ideas.

Design & Code

I noticed that a scene with a large particle system was running slowly, and became curious as to why.

So I downloaded and ran a profiler on the code, and was shocked — shocked, I say!— to find that 80% of the CPU time was being taken up by the random number generation code.

I decided to implement the above code, which is about the simplest, most naïve code imaginable. It is just a lookup table of random values, but seems at a cursory visual examination (of the resulting particle system) to be adequate to the task at hand.

The scene computation time went from 34 seconds down to 6.5 seconds. Not bad for a half-hour’s work.

Imagining numerical experts clutching at their pearls, I can only say in my defense that proceeding quickly along the path of least resistance has been a core tenet of this project from the start. Doing the “correct thing” can wait until we have a reason to do so.

Next Episode

Oddly enough, I do remember that the idea for the web graphic novel came to me while I was cleaning beans at the kitchen table one day. I remember this because I remember telling the story to one of the actors who asked me where I got the idea. Kind of a meta-memory I guess.

Yes, my graphic novel had actors. Since much to my dismay I have never been able to draw, I came up with the following process for the production of the graphic novel.

I would produce and shoot the production like a run-and-gun low-budget (actually, no-budget!) film. Get together actors at given locations and film them “acting” out the scenes. More like a silent movie since I wasn't recording audio. This made production very fast and smooth. For example, we’d go into a restaurant, order a meal, and the two actors would eat and converse as I discreetly got the required coverage with a small Hi-8 camcorder.

We shot all over Montreal, including friends’ houses and offices. Everything was very smooth and well organized, thanks to my friend and producer John Kennedy, whom I had met while at Taarna. John was — and remains — a commercial producer, a gentleman, and a friend, who gave a sense of professionalism to my various hare-brained schemes over the years.

He corralled actors, contacts, and locations for the project. Being new to production back then, I did not truly understand or appreciate how lucky I was to have him on my projects.

On the technical side, I would digitize the Hi-8 footage into my Mac, where the production pipeline was based on trusty MCL, with Common Lisp acting basically as a scripting language would today.

Code & Design

The question of a GUI has been vexing me as of late. Questions, rather, in the plural.

The first question is whether I need or want a GUI. From the start I knew I didn’t want to develop a clone of an existing 3D app, so I don’t want to fall into the time-consuming trap of developing a full GUI that does what every other GUI does.

Why would I want a graphical user interface? How would it help my exploratory 3D development? It could help in two ways: visualization (insights) and interaction (creation).

I have always been interested in visualizing code and data, and am curious in what ways I can do so here. What insights may result. And an interface more conducive to experimentation (compared to writing code) may lead to interesting graphical structures.

If I were to develop a GUI, which toolkit should I use: Cocoa, Qt, Tk, Open GL, web? There are many Common Lisp bindings, but no obvious, complete, and effortless choice presents itself. When I made queries online, one person told me if I wanted a GUI, I should abandon CL.

I kept going around in circles, unable to decide. And then, one morning I did what I have been doing all along on this project: just started writing code from scratch, hoping to get a simple system running well enough for my own needs. The code above shows some of the work, written very basically using the barest minumum of Apple's Cocoa interface. I implement everything on top of the NSViewclass and use no actual UI widgets from Apple.

My goal is to write it quickly, not sweat the details, learn from using it, and then rewrite it with a better understanding, or pick an existing framework as a more durable foundation.

Next Episode

A little flashback…

I wrote my first short story in 8th grade. It was a science fiction story about the crew of a small spacecraft sent to investigate a comet. I even drew a picture of the spacecraft. It had a built-in observatory with “non-refractive” glass.

In high school and at MIT I read voraciously, mostly science fiction paperbacks, and later comics. One of my friends at MIT was a serious comic book collector, and today he runs what is probably Boston’s best comic book store.

Serendipitously, while I was at MIT the Institute’s first course in science fiction writing was offered, taught by Joe Haldeman, whose work had won just about every major science fiction literary award. Over the next few years, I took every class I could with Joe.

To this day, Joe’s classes form some of my strongest memories of MIT. Up there with my stint at the Media Lab. I still have the image in my mind’s eye of the newly-hired Professor Haldeman walking into his first class, a tall stack of books in his arms and a pipe in his mouth.

After a few lectures, we workshopped the students’ writing each week. We would walk over from our classroom to the Muddy Charles, the graduate student pub on campus, get a couple of pitchers of beer, and sit on the floor of the lounge upstairs from the pub. Then we’d go around giving our feedback on the stories of the week. I had no other classes like that. Good times.

The reason I bring up this reminiscence is that I wrote a longish short story in one of Joe's classes, called “Two Knights Defense”, named after the chess opening. The story involved the discovery of a crashed alien spacecraft and several groups who are trying to track down a person who visited the site and may have been affected by something not of this planet.

A decade later, in Montreal, I decided to make a web graphic novel out of the story.

Design & Code

In the spirit of increased generality and abstraction (very much a Lisp thing), I implemented curve-generator-mixin which provides an interface for curves analogous to what point-generator-mixindoes for points.

The function make-sweep-mesh-group uses this interface, both for the profile curve (make-circle-shape in this example) and for the path curves (the p-sys particle system).

In the image and listing shown above, the icosahedron is providing the points for generating the particle system. By setting the flag point-generator-use-face-centers? — why do Common Lisp names invariably tend to get longer as development proceeds ?— we instruct the icosahedron to return its face centers rather than its vertices. Just a fun thing I thought I’d add to the code.

Well, fun in a very geeky way.

Next Episode

Around the time of Metropolis Graphics, I did some contract development for a Montreal company developing a GIS (geographic information system) application. What made the job interesting was that we developed the software on OpenStep, the Intel port of NextStep.

Years ago I had read Brad Cox’s book on Objective-C, and now I had a chance to use it in the field, so to speak.

In some respects, NextStep was more a child of the Xerox Parc philosophy than the Macintosh was. It was architected on top of a Smalltalk-like language, based on messaging between objects. Not to belabor the point, but as Alan Kay has said, C++ was not what he had in mind when he invented the term Object Oriented.

And in his Next pitches, Steve Jobs emphasized the software components arguments that Brad Cox had put forward in his book. It was probably the closest anyone came to bringing that vision to life. I have a feeling that emphasis was lost once Apple purchased Next. If there is a marketplace for software components on OS X, I am unaware of it. And though I did some work in Swift (Apple’s replacement for Objective-C) a few years ago, I don't recall how Smalltalk-like it was.

One other point of interest about the GIS software was that it was based on a dependency graph. These days every 3D system seems to have a node graph system of some kind, allowing users to connect the outputs of operations to the inputs of other operations. Some, such as Houdini, are primarily based on such architecture.

I am still contemplating whether this is something I want to implement in my system. If I was developing a system intended for the market, I definitely would, but since this is exploratory development, I am hesitant to settle for what may seem like the obvious choice.

My view of node graph systems is that they bring some of the power of software development to users who are not programmers. What I would like to discover is a way to enhance the expressive power of programmers using some sort of visual development approach. And to do so while retaining the full power of Common Lisp.

Maybe a bit of a tall order.

Design & Code

The image above is deceptively simple. It depicts extrusions along a particle system growing from the vertices of a grid mesh. What is new here is that the interesting computations take place behind the scenes, in the sweep-mesh-group class.

As can be seen in the code listing, this class inherits from manager-group, and computes its children (uv meshes) as necessary. This avoids the need for a separate animator in the scene to update these meshes. The only animator added to the scene is the particle system. When it updates at each frame, the mechanism in dependency-node-mixin kicks in and calls the compute-procedural-node method of the sweep mesh group.

Not only does this encapsulate the computation inside the class, it only rebuilds the children when necessary.

I have been wondering whether I have gone too far down the rabbit hole: is it better to have visible loosely coupled components (simple animators that operate on objects), or encapsulated classes (with more complex internal — and hidden — behavior)?

Currently leaning towards the latter. I am hoping that it will allow for building layers of abstraction by hiding complexity, one of the tenets of Object Oriented design. This makes me think of the “Worse is Better” paper by Richard Gabriel, which states (much simplified) that is better to bring a simple system to market soon and then evolve it, rather than taking a long time coming up with a “prefect” solution in isolation.

I think part of the purpose of this blog is to not dwell in isolation, as I have done with past projects which never saw the light of day.

Next Episode

Long story short, we failed to get funding for our project and Metropolis Graphics withered on the vine, nothing more than the pipe dream of two idealistic developers.

I could muse at length as to why that was, but basically I had no business sense (and thirty years on there is very little evidence that things have changed in that regard). We spent all our time on the software and then gave a couple of presentations to companies we thought might be interested in the project. And they weren't. Could probably be taught in business school as a classic case of how not to run a startup.

Having said that, I can’t help but think how we could have done things differently. So, gentle reader, please indulge me.

On the tech side, the Mac simply wasn’t a viable platform for serious 3D applications. We could have used Common Lisp on the SGI platform, either AKCL or a commercial offering. The renderer and low-level vector and matrix code would be written in C. Much of that work was done anyway.

Working in a vacuum was another mistake. We should have involved potential users early on. Today, this is reflected in the startup mantra of “release early, release often”. We would have approached CG production houses we had connections to and provided them with the system in exchange for testing and feedback.

A near-term feature focus might have been a useful differentiation tool. Rather than tackle ambitious open-ended “smart object” ideas, we could have focussed on useful things that I had experience in and which were ahead of other commercial systems. Things such as facial animation, hair, fur, and cloth simulation.

Finally, I would have approached some business people early on and asked them on board as advisors, so we would be ready when we needed to raise financing.

One small thing that I have learned since then is that tech without marketing goes nowhere. I used to believe all you needed was a better mousetrap. Naive in the extreme.

As a sad coda to all of this, a few months later Mike passed away peacefully in his sleep. I recently discovered this link which talks about his life.

Design & Code

The image above shows an application of last post’s code. It depicts a branching particle system growing along the surface of a polyhedral model. A cow, to be precise.

Previously, I implemented procedural-mixin to allow “output” slots of a class to depend on “input” slots. I wrote the dependency-node-mixin class shown above to allow the same sort of connection between objects of different classes.

After some consideration, I decided on a scheme using timestamps to indicate when an object has been modified. I assume this may run into problems on a distributed system (where host clocks might not be in sync), but we’re not there yet.

One use I have put this feature to is implementing group classes which update when one of their children is modified. The class manager-groupacts as an abstract superclass for such classes.

On a side note, having uploaded my code to Github, the other day I received my first pull request. A developer from Germany was kind enough to organize my code to use the ASDF system definition facility. I merged his changes into the code and now feel generally more organized.

Next Episode

I still have the MCL code I wrote during the years of Metropolis Graphics. I found a comment dated 4 April 1992 in the matrix math file. Thirty years almost to the day from the writing of my new system (which I have called kons-9 in the Github repository for reasons which are not entirely clear to me).

Metropolis Graphics counts as Lisp Graphics System 3 (LGS-3), following as it did the Symbolics and AKCL systems. I have the source because it was one of the few things in my Dropbox folder when the house fire happened. All my other backups were in a neatly stacked pile of CDs next to my computer.

I have seen comments dated from 1992 to 1994 in the code, so I worked at least that long on the project.

When I develop in Common Lisp, I feel like I have somehow come up short if I have to write all the code myself. The computer should write some of the code for me. That’s what macros are for.

In this case, I wanted the UI for the graphics classes to be automatically generated. MCL had excellent support for the Mac Toolbox (being a first-party Apple product), and I wrote macros which simultaneously defined a class and generated UI panels for the class.

I also remember working on implementing my idea of smart objects. 3D entities with internal workings which understood commands such as “move forward” and would move (e.g. by walking, rolling, jumping, etc.) based on their internal mechanics. Much what I imagined obviously came to pass, in the form of 3D rigging in DCC apps, and behaviors in game authoring systems. Time waits for no one.

While Mike worked on his renderer, I implemented RenderMan RIB (RenderMan Interface Bytestream) output and rendered some short animation clips on Taarna’s high-end desktop Mac using Pixar’s MacRenderMan package. It was a painfully slow process as I recall.

You would think that I would have carefully studied the Metropolis MCL code prior to embarking on my current project, but that's not the case. I have only looked at and used a few files (3D points, matrices, and superquadrics so far), and preferred to design from scratch. Why? I’m not sure. Decades later, there are still emotions attached to the software.

Maybe I will look more at the code at some point in the future. I’ve even idly thought of digging up an old PowerBook and an MCL diskette and seeing if the code can still be run. Though to be honest I most likely will let that remain an idle thought.

Design & Code

I had a thought to make a particle system which would climb a shape like vines up a tree. Or a teapot, as seen above.

This was done in two parts.

One was a subclass of particle I called climbing-particle which does what a normal particle does and then snaps to the nearest point on a point-cloud. It is gratifying to be able to express new behavior with so few lines of code. Somehow gives me the feeling that I'm doing something right. Or maybe this is all essentially trivial and I'm just fooling myself.

The second part was implementing the generate-point-cloud method, which fills the surface of a polyhedron with points at a specified density. This was done using barycentric coordinates on triangulated polygons. The same technique I used back in the day for growing hair and fur on CG models. Everything old is new again.

Next Episode