<kbd id='0c3ec458b0'></kbd><address id='0c3ec458b0'><style id='0c3ec458b0'></style></address><button id='0c3ec458b0'></button>

          Anamorphic FunJanuary 2nd, 2020
          Patrick Stein

          I want to make some bookshelf dioramas like these ones by Monde. I also want to make some that take more liberties with the limited space available. So, I am thinking about using forced perspective to create extra depth. I’m also thinking of some designs that could use right-angled mirrors to snake height into depth.

          I also want to create extra width (and height) though. Not just depth. How can I do that? I can use anamorphic illusions to make things appear to stretch beyond the edges of the box. And, I can force the viewer to only view it from the illusory angle and enhance the illusion of space if I make the diorama viewable through a peephole.

          So, I started experimenting yesterday with anamorphic projection onto the inside of a narrow box for viewing through a peephole.

          I used the cl-svg to create grids like this that look flat when viewed (from the correct distance) through the peephole linked above.

          Then, I used cl-jpeg to create images that when printed and folded into the interior of a diorama look as if the image extends beyond the sides of the diorama.

          If you print this as 72dpi and then fold on the white lines, it will look like a flat, square image with the letters AB on it when you look down into it.

          Then, I combined the two.

          If you print this as 72dpi and then fold on the white lines, it will look like a flat, square image with the letters AB on it when you look down into it through a 200-degree peephole.

          Here is the full source code (peephole.lisp) used to generate the grid and the anamorphic images.

          DIY Camera Obscura for the EclipseJuly 9th, 2017
          Patrick Stein

          I am excited about the solar eclipse this August that will be visible across the continental U.S. I am also keen in still having retinas when it’s over. So, I ordered some solar-rated sunglasses and decided to build a solar projector.

          I brushed off my familiarity with the relevant lens equations, ordered some big-aperature lenses, and put the TC Maker laser cutter to good use.

          Photo of the whole solar projector

          The solar projector on a railing, propped up by books, catching the sun.

          Materials

          Determining the Lens Focal Lengths

          I bought Fresnel lenses sold as page magnifiers and glass lenses that were sold to match particular TV models. I had no real information about their focal lengths. So, I took two different steps to come up with approximate focal lengths. The first thing that I did was set up a small lamp in my bedroom at night. I then positioned the light and a white backdrop at the distance that I needed them to be so that when the image of the light was in focus, the lens was half way between the light and the backdrop.

          Then, I used the equation: 1/D_o + 1/D_i = 1/f to calculate the focal length. Here D_o is the distance from the lens to the object and D_i is the distance from the lens to the image. Since I made those both equal here, then the focal length is half the distance from the lens to the backdrop.

          I determined that the focal length of my Fresnel lens was about 300mm and that the focal length of my glass lens was about 90mm.

          Later, I verified these numbers by taking taking the lenses outside. I placed them to focus the sun on the sidewalk. Be very careful in this step. Concentrating the sun with a lens is a great way to start a fire. That’s why I did this on the sidewalk. I verified that when the lens was at the calculated focal length, the sidewalk started to smoke.

          Preparing the Telescope

          So, my brushing up on my lens equations and some common sense made me think that to project the sun, I wanted there to be about 390mm between my two lenses. I still wanted to verify this before really committing. So, I cut up a cardboard box so that I could put a Fresnel lens in one end and a glass lens in the other.

          Cardboard prototype of telescope

          This worked out well enough and I had experimental verification of how far I wanted from the Fresnel lens and the glass lens.

          Blurry photo of sunset projected on my dishwasher

          So, then I started sketching out plans for the actual projector.

          Photo of sketchbook drawings of rough plans

          I decided that I wanted a 90-degree bend in the light path. With the bend, I can point the objective lens up toward the sun and have the projection screen set up any distance off to the side rather than having to set it up between the projector and the ground.

          Once that was done, I put together plans to cut out a real box using a laser cutter.

          In my first attempt, I had apparently gotten one of the pieces of my drawing misaligned. It was together enough though to do some initial experimentation. In the initial experimentation, it was really obvious that I needed to add a viewfinder.

          The Viewfinder

          After manually attempting to point the camera at the moon and other dim objects, I decided that I needed a viewfinder of some sort. I decided that I needed a viewfinder where you could either look through it at a dim object or line things up based on shadows from the sun. I was about to just go with a cross-hairs type pattern when I thought, now would be a very nice time to pretty it up. I searched around a bit for sun icons and stumbled upon this gorgeous eclipse icon.

          solar eclipse icon

          I made the front viewfinder with both the sun and the moon cut out. I made the rear viewfinder with the moon cut out and the sun just engraved. This is supposed to be a reminder that you shouldn’t be trying to line up the sun by looking through the viewfinder. You can use the viewfinder to line up the moon and you can use the shadow of the front viewfinder on the rear viewfinder to line up the sun.

          Photo of the sun shining through the viewfinder, almost aligned

          Final Plans

          Here are the sun-projector sun-projector plans. The red lines are to be cut through. The blue lines are to be cut through if you want to build a straight-through projector. The green lines are to be cut through if you want to build the projector with a bend as I did. The yellow lines are only to be etched. Note: the entire dimensions depend on your lenses having a light path in the neighborhood of mine….. something between 300mm and 400mm. If you don’t have lenses in that range, you probably have to design your own.

          Photo of projector on my railing, propped up on books

          Here is an image of the sun. The projected image of the sun is 100mm in diameter. You can’t tell too much in the picture, but in real life you can see two shadow images of the sun because I am using a $5 rear-reflecting mirror instead of $85 front-reflecting mirror. Meh.

          Photo of sun projected onto foam-core board

          Next Steps

          Next, I am planning to try to make a base in which to sit the projector to make it easier to point it at the desired spot in the sky.

          Fog of Light – Starting to Add Star-FieldsMay 28th, 2017
          Patrick Stein

          I have finally written my first OpenGL code using GLSL. Whew. That took way too long to get all working correctly.I promise, soon, I will upload some sample code so that others may not have to stumble as long as I did.

          For the star-field, I generate a few thousand 2-D points.Each point has its own radius, its own opacity, and its own color.

          I put these all into an OpenGL array buffer.Then, the vertex shader copies data out of my struct to set the color and the point size.Then, the fragment shader turns the color into two, overlapping radial gradients (one that is half the radius of the other) by modulating the color’s opacity.

          screenshot of sample starfield

          Next up will be nebulae, then planets/asteroids in the local system.

          Fog of Light – Getting UnderwayMay 15th, 2017
          Patrick Stein

          Dauntless (The Lost Fleet, Book 1) was the first science-fiction book I read that tried to deal with space combat with the real-world constraint that light only travels so fast. It takes light eight minutes to get from the Sun to Earth. It takes light more than a second to get from the Earth to the Moon.Depending on where they are in their orbits, it takes between three minutes and twenty-two minutes to get light from Mars to Earth.

          Imagine that you’re a star-ship.You and your companions have just warped into a new star system.You see a flotilla of enemy ships about 45 light-minutes away.That means, you’ve got 45 minutes before that flotilla can possibly even know that you’re in their star system.How much can you get done in that time?Once they can see you, how much can you mislead them on your target if they’re going to be operating on data about where you were heading more than half an hour ago?

          For years, I have been batting around this concept, hammering it into a game. I have finally gotten started on it.

          Armed with some functions like these, I am constructing values which change at points in space-time and querying the value visible from other points in space-time.

          (defgeneric get-nearest-value (space-time-value space-time-point)
            ...
            (:documentation "Find the observable value of a quantity
          SPACE-TIME-VALUE when observed from a given location
          SPACE-TIME-POINT. This method finds the most-recent
          value V0 (at location P0) for this data when viewed from
          the given location. This method returns (VALUES V0 P0).
          This method makes no effort to interpolate the results."
          ))

          Here are my first, visually-demonstrable results:

          Hopefully, there will be plenty more coming in the near future.

          The Metaphor Soup Blender TrainMarch 10th, 2017
          Patrick Stein

          I had two days of SAFe training this week.SAFe stands for Scaled Agile Framework.Its goal is to take Agile software practices and use them in a big program, big product, big system scenario.

          The training itself went well.It was 10,000 times better than the training that I had 25 years ago on the Carnegie Mellon Capability Maturity Model.The instructor knew his stuff and wasn’t afraid to weigh in on the good/bad of how SAFe has been rolled out in our program.

          But, I gotta say, the Capability Maturity Model took five vague concepts and enshrined them into a mythical religion.SAFe, on the other hand, took a whole slew of disparate imagery and jammed them all together in some of the most crowded, grindingly-bad metaphoric combinations I can imagine.

          Starting with Agile

          As it starts with Agile, SAFe is already on shaky metaphoric ground. In Agile practice, one breaks up the work into User Stories. If a particular story is super-broad and long, then it is called an Epic.So far, so good, eh?But, stories are fairly static and we’re trying to be Agile.So, we take a group of stories and put them together into the work we’re going to do for the next two weeks and we call it, an Anthology?, an Issue?, a Serial?, no… we call it a Sprint.Because there is nothing like running with a good book to boost productivity.

          And, I should mention that some User Stories are more complicated than others.So, each User Story has a number of Points assigned to it, usually through Planning Poker. We use a gambling metaphor to come to a team consensus on the number of Points each Story is worth.

          Are you following me?Good.

          Okay, so, in Agile, too, we want to break down the barriers between those who design and those who code and those who test. How does our team do this?We Scrum.Scrum is term from the sport of Rugby.A scrum, in Rugby, is a big crowd of players from both teams, fighting over the ball in a mob, trying
          to push it down the field to their team’s advantage.In Agile, we are all on the same team, so I’m not sure why we’re fighting over the ball.And, I’m not sure how this is helping us Sprint our User Stories.But, that’s what we do.

          Really though, for some reason, we use the word Scrum to mean a quick daily meeting to update everyone on what we’re working on and raise anything that is blocking us.Cuz, that’s nothing like a Rugby scrum.And, we use the term Swarm to refer to those times when our whole team is focused on a singular goal to push it through, or when other teams dive in to help our team with a singular goal.

          So, in order to finish our User Stories in a Sprint, we Scrum every day and occasionally Swarm.

          And, like every good Sprint, the next Sprint starts immediately after the last one ends.

          The last thing you do in a Sprint is demo what you accomplished in the Sprint.You know, like in a foot race, where you finish the race and then show everyone how you just finished the race.And, then, you have a Readout of what you’ve done.And, you start the next sprint with a Readout of what you’re going to do the next Sprint.Because, it wasn’t scientific enough to have just finished your Stories in your Sprint, you need an old piece of galvanized steel equipment to spit out a small paper tape with the total on it.

          All Aboard

          So, how do you take something organized around Sprints full of Stories by a Scrum team who can Swarm and make it scale to something big?

          Well, you start by adding trains.You add multiple, ARTs (Agile Release Trains).These trains each have multiple Scrum teams Scrumming and Swarming on Stories.

          But, now, we need some stuff in between Epics and User Stories.Are we going to stick with writing metaphors?Of course not.We’re going to make Epics broken up into multiple Capabilities and Capabilities broken up into multiple Features and those Features get broken up into User Stories.

          Oh, we need to know where the Agile Release Trains are heading, right?So, we will have a Roadmap and a Vision which will be the Guardrails for our train. And, the train, itself, will be following a Value Stream with Milestones.So, your train doesn’t run on train tracks.It runs on a stream.It does this so it can Pivot if needed.But, it is okay, because there are guardrails and a roadmap.

          The train provides Transparency.Your train full of scrums on a stream with a roadmap is transparent.

          There is, of course, also a Product Manager or Product Owner who steers the train.We also have Release Train Engineers. They don’t get to steer though.They only get to drive the train straight along the stream.

          Are We Flying Yet?

          So, in Software Development, there are tons of small decisions that we make each day that, together, form the Architecture of our application.Most big projects have dedicated Software Architects who are responsible for keeping the Architecture coherent.

          You may rightly be thinking that this whole bevy of Scrum Teams piled on our Agile Release Trains with their heads focused on the User Stories in their own Sprints might not be the best thing for the overall Architecture.But, that’s okay, because running along the Value Stream there is also an Architectural Runway.I’m not 100% sure if this is so that our product can fly (or land?) or so that our product can sell its new line of shoes in Milan.But, we’ve got a Runway.

          The Crooked House

          At some point, someone decided that SAFe needed Lean. So, they added it in, too.In fact, they have what is called the SAFe House of Lean.Now, I am quite glad that my house house does not lean.

          The foundation of the SAFe House of Lean is Leadership. The roof is Value.The pillars are: Respect for people and culture, Flow, Innovation, and Relentless Improvement.We’ve now built a house out of abstract concepts. I’m not sure where it sits compared to our Stream or our Runway or our Train or our Sprint, but it makes for a hell of a User Story.

          RSS Feeds

          • All Posts
          • All Comments
          • Announcements
          • Math
          • Lisp
          • Reviews

          Categories

          Tags

          algebraalternativesartworkbad mathc++cl-fftcl-growlClean Architecturecode designcode kataCSSdebuggingdomain-specific languagesebooksfluid designgame designgeomageometryiphoneiphone appiphone appsjavascriptlispliterate programmingmacrosneheobjective copengloptimizationperlpolynomialspreviewquicklisprtschemespell-itTC Lisptrack-bestubuntuunetuserialuser interface toolkitsvectovmwarewoolly
          l