Sep 112015
 

This post is part of a meta-series. Click here for a list of all posts in this series.

Photogrammetry has been a major interest of mine for a number of years now, but all of my efforts toward making use of it as an artistic tool have thus far met with failure. None of the open-source, free, or even pay solutions either work or do what I want.1 I have designs on cooking up a program of my own at some point that does it all, but haven’t really set aside the time (hah!) to work something up.

Imagine my delight when I discovered that Blender could do some of what I wanted, natively.

It’s got major restrictions, though: namely, it only solves for a single camera (i.e. one focal length, one sensor size). Mingling images from different cameras, even if the various properies of those images are known2, is a no-go. That put me in a bit of a pickle, because I have a ton of Stormtrooper helmet reference photos, but very few from the same camera and even fewer that present a good “turntable” set. Fortunately, I did have one set, complete with full EXIF data that I could use to set the correct camera properties!

Of course, it was only nine images, with a lot of movement between frames. Blender couldn’t hope to solve that on its own. So, I spent hours and hours every night tracking points across my nine “frames” by hand, trying to find any features that stood out and were easily tracked. Naturally — because it couldn’t possibly be easy! — these points were almost never major “feature” points of the Stormtrooper helmet as one might conceive of them. They were usually blemishes; chipped paint, drips, dings, and so forth.

It took me a while to realize that tracking these “defects” was even worthwhile. My first approach was to try to project the 3D coordinates into the scene so that they coincided with actual features of my existing model. As time went on and I learned more, though, I realized this was folly. I just needed the right “origin” (I used the top of the gray “frown”) and to set the proper scale. I also came to understand, since I wasn’t defining any lines as denoting an X and Y axis3, that the camera solver made use of my initial camera position in 3D space as-is. It wasn’t “solving” that; it was using that as the starting point for the camera’s motion. That meant I had to eyeball that into the right position.

Eventually, though, I got it. A “perfect” solve is anything with a Blender-reported error of <= 0.3, Anything up to about 6 can still be "pretty good." My solve is ~0.9, which I am astonished by after how impossible a task it seemed when I set out.


The little balls are the 3D projections of my tracking points. The reason the photo and the right side (camera left) of the model are so different is explained further down. Image source.

With my camera calibrated, I could finally start modifying my existing model to make it better match the real, screen-used prop! This was the very first time in my entire history 3D modeling that I’ve been able to do that — take a “real life” picture that wasn’t purpose-shot as near-orthographic and use it as a reference plate in 3D space. It took some doing, but this part was much easier than the tracking itself. After all, it’s essentially the same sort of thing I’ve been doing for the better part of two decades. It entailed a great deal of hopping back and forth between “frames” to make sure everything lined up from all nine of my camera angles, but eventually I had the entire left half of the helmet photo-matched.

The screen helmet, though, is asymmetrical. That meant copying my left-side model and tweaking it all over again on the right side to make it match that one. That went a great deal faster, though, and with a quick hop back over to the left to do some final tweaks, I had a bang-on (with a handful of exceptions that could easily be chalked up to lens distortion of the photos themselves) match for the asymmetrical ANH Stunt helmet.

From there, it was a simple matter to “average” the vertices from the left and right sides to create a symmetrical helmet that matched pretty well with both the left and right helmet sides in the photos.


(Click for full-resoltion)

Next step, convert it to paper!

  1. PPT and Voodoo always seem to crash or spit out garbage and Catch123D is super off-putting. The Cloud and cloud computing can be amazing things, but I still want my applications local, man. []
  2. One of the things that’s possible to do in general, given sufficient shared coordinates between images, but unknown camera parameters, is to back-calculate the camera properties. My photogrammetry program, whenever I eventually write it, will do this. []
  3. My image sequence was shot against a single, static background and the helmet itself was turned, so there was no true 3D origin coordinate I could use. []
Feb 202014
 

This post is part of a meta-series. Click here for a list of all posts in this series.

So, tonight’s update has no discernible change (other than the addition of the dorsal phaser strip) from the previous, despite representing two evenings’ worth of intensive work! First, the pretty renders:

And now the technical explanation of WTF. It turns out that Cycles, in order to be faster, has a somewhat imprecise ray-to-triangle intersection algorithm. This manifested on Coro here in the form of the light from the interiors leaking through polygon seams! It wasn’t too bad at high light levels, but in dark renders it looked terrible. On a hunch, I decided to see what would happen if I fully enclosed the room objects, giving them an interior wall1 with inward-facing normals to ray-intersect with the emitted light. Much to my relief, this actually worked like a charm! Of course, it was also a huge pain in the butt to vertex-snap all of the interior walls to the inside edge of the window inset, hence why it’s taken me two evenings to do!

Here’s a before/after image with the exposure cranked way up.

Let this be a lesson to any Blender folks out there who plan to put rooms behind their windows!

  1. instead of making them more like open TV sets []
Feb 172014
 

This post is part of a meta-series. Click here for a list of all posts in this series.

Decided I didn’t like the existing module connector spars, so I deleted the old ones and rebuilt them. The new ones remain flush with the module hull until one “room” prior to the edge of the module. The outer edge now lines up with the proper thickness of a deck, too, and the dorsal and ventral flat surfaces also correctly coincide with decks.

Then I made phasers. 😀

The inset area has a different material than the rest of the phaser structure, so I can fool about with the shader and make it “light up” as it prepares to fire.

More module detailing

 Posted by at 20:03  No Responses »
Feb 162014
 

This post is part of a meta-series. Click here for a list of all posts in this series.

Someone asked about the modules having modules. There are actually two levels of modularity at play here. The idea is that you’d have a number of prefab module wedges that sit around ready to be picked up by a starship as-needed. They’re fully self-contained, so basically they could just sit floating in space near a starbase and a ship could swing by, dock with one, and head out on its mission.

Some modules are going to be dramatically different than others, necessitating a completely different interior structure than other modules. But not all of them! Some modules may not need any large structural changes, but only smaller mission-specific components swapped out. Perhaps you want four module types to all contain living quarters. That’s where the sub-modules come in. They’re designed to be pulled out and plugged in by a starbase (or other drydock facility) to create the prefabs the ships ultimately use.

From a modeling POV, it also lets me change the superficial components of each module without too much hassle. 😉

Spent most of a day on this, other than a break to watch the US vs. Russia Olympic hockey game.


There are some mesh errors around the top of the deck 8 windows (the outer-most ones) that I still need to deal with.


Windows and paneling (and “shield grid reinforcements”) on the ventral module surface. That blank flat area between the Deck 10 windows and the sort of square-bracket-shaped paneling will be home to the ventral phasers and banks of escape pods.

Feb 152014
 

This post is part of a meta-series. Click here for a list of all posts in this series.

Everything’s now frozen and optimized! That means it’s time to start cutting! My first stop was the large Spectre fighter catapult bay. I decided to make this an open-air bay rather than two separate conduits to give maintenance crews easier access to a craft on one side or the other, allow for common feeds (fuel, munitions, etc.) to be housed in the midline and service both catapults, etc. The (eventual) doors will be “garage door”-style segmented doors, like those on the main shuttlebay of the Galaxy class.


Here’s a quick viewport render of the frozen bridge module, too.


Inspired by Martocticvs, I spent some time fooling about with lighting and tone mapping with my Ambassador as a guinea pig to figure out the workflow for that. The results are pretty cool! I then continued working on the Spectre bay interior. The exterior spine needed more interior representation, and the bay was cavernous enough that it felt like it needed more structural support, so I continued the spine’s structure into the bay as a sort of aqueduct-like shape. This still allows crews to easily flit from one fighter to the other, but makes the ship a bit more sturdy.

All of this is still light by one external point light and one emissive “fill” plane, with a very small amount of the AO pass added in. The rest of the illumination is due to the tone mapping, which I am just so excited about. I’m actually going to ditch everything but the single point light, which I’m going to convert into a “sun” (think “infinite” or “distant” light) light. With tone mapping, that should be all that it needs and it should make the resulting images much richer.


Started adding detail to the modular wedges, in the form of Deck 3’s windows!

The windows and rooms are a bit more complex than on my Ambassador. There, the windows were just cut-outs in the hull, with full-emissive UV-mapped texture boxes behind them. This time around, the windows have two polygon layers of actual “glass” that includes a slightly glossy surface. The rooms are still UV mapped boxes, but the shader is more complex: the “top” of the box is full emissive, but the rest of the room is a mixture of diffuse with emissive hotspots. In other words, the rooms are not just providing light, they’re also being lit this time. Should make for somewhat more realistic looking interiors…not that you’ll usually see anything this close-up anyway. :p

I also did away with my old lighting rig and have gone to a single “sun” lamp model now, with all of the fill light provided by indirect bounce and tone mapping.


This took way longer than it had any right to!

These panels will end up being dark, dark gray once they’re textured, with some light gray trim.


Of course, had I filleted the corners first, then extruded and beveled, I would’ve saved myself a lot of trouble! The next three panels took a total of only fifteen minutes.

Pushed through to finish out the various panel blocks for the modules and put the windows into the deck 6 sub-modules.

Here’s an OpenGL shot of what the modules look like without their sub-modules plugged in:

Feb 132014
 

This post is part of a meta-series. Click here for a list of all posts in this series.

I can’t leave well enough alone! 😀

Revised the lighting so that all scene light is coming from a single unidirectional sun lamp1 and the ship itself. Then futzed around with the compositing network a ton in order to try to smooth out the remaining “fireflies” in each of the direct and indirect channel passes. Added some more bloom and glare stuff. Tone mapped the whole render. Compare with the second render in the original post.

  1. “Distant” or “infinite” light in other programs []
Feb 112014
 

This post is part of a meta-series. Click here for a list of all posts in this series.

There isn’t really any visual progress here, but the modules and modular connectors are all UVed, frozen, and optimized now.


The following was in response to a forum comment.

Damn I wish I could do this….

You can!

Look, I have been doing 3D modeling of some form or another for 16 years (started in 1998 with trueSpace3). It’s been my primary hobby ever since I picked it up. I went to art school, with an animation (i.e. 3D) concentration for five years, part of which was spent interning at a game company as part of its art department. I then went on to work in the game industry full-time for six years (before getting out because the working conditions of the game industry are stupid and it was sapping my energy for the hobby aspect of 3D work).

My point in saying all of this is that what I “can do” is purely and entirely a product of time invested (and I’m a firm believer that all skill is acquired; “innate talent” is an excuse) and learning from people around me during that time.

And, honestly? I don’t even think I’m all that good. I look at the work someone like tobiasrichter does and feel equal parts dismay and awe. He is so fast and his final product is so good that it just boggles my mind. But from what I can tell, he has much the same story as I do—plus 10 years or so. Every time I remind myself of that, I feel a little bit better.

That’s the beauty of forums like SFM or F3D (and I heartily recommend becoming an active, contributing member of as many 3D communities as you can stomach!)—they provide a great realm not only to show your own stuff and get directed feedback, but also to see what other people are doing and ask questions about how they do it and to teach others what you know. The greatest test for whether or not you know something comes when you try to teach it to someone else. 😀

Whenever you see something that amazes you, fight the part of you that says, “Damn, I wish I could do this” and embrace the part that asks, “How did they do that and how can I learn to do it too?” That is the only real secret and that is how you get better.

Remember Egoyan‘s rules:

Never waste your time comparing yourself to anyone else.
There are hundreds of other people who will provide this service free of charge.

Don’t get depressed about not being where you want to be.
This nagging feeling of anxiety is actually called ambition. Ambition is your friend.

Nothing will ever turn out the way you want it to.
It may be better. It may be worse. It will never be exactly what you imagined.

::gets off soapbox::


Here’s a quick video showing how face snapping works. No sound or narration1, but hopefully it gets the basic point across!


Here’s a 45-minute video showing the actual multi-resolution subsurf process for the nacelle.

Definitely watch in 720p, fullscreen for maximum clarity. It’s way too easy to lose some of the detail without it, and because it doesn’t have the hotkeys displayed, clarity’s even more important.

Really need to look into OSD for hotkeys…

  1. Or screen notation showing hotkeys! 🙁 … I should really figure out a solution for this, at least []
Feb 082014
 

This post is part of a meta-series. Click here for a list of all posts in this series.

This isn’t really a 3D update, but I’ve been plinking away at doing a paintover to plan out where details/surfacing/etc. are going to go. I’ve been heavily referencing the Sovereign class, with a dash of Intrepid thrown in here and there. I don’t intend to fully paint over the whole image; rather, just enough to get a plan in place before I start throwing geometry around. That’s why only one module is painted over, one half of the ship, etc.

The windows are actually geometry that’s been face-snapped onto the saucer and extruded slightly. The windows are all 0.75m across.1 Since the decks are 2.45m from floor to ceiling (Coro is deliberately meant to feel more cramped than most Starfleet ships), I made the windows 1.35m tall, raising 1m off the floor and giving a 10cm clearance between the top arch of the window and the ceiling.

The inner-most windows shown (Deck E) are actually portholes when viewed edge-on; 0.75m circles. It’s only the extreme slope of the deck that makes them look so elongated. If you were standing inside the ship facing out one of those windows from where the “top” starts, you’d have 5 meters between you and the bottom of the window, which is awfully huge for a porthole. The Deck F windows (next row out) are the same vertical height as the Deck G (outermost) windows, yet they stick into a room almost as far as the Deck E portholes do. The Deck G windows, for contrast, only stick in about 1.8m — much more reasonable. So, I may ditch the E and F windows entirely.

The non-module windows have a different arrangement pattern than the modules do. The modules all share the same pattern.

I threw some annotations on the modular components to indicate intended functionality and relationships. The main phaser array interlocks emitters between the modular segments and the module spars, creating a single continuous strip regardless of the ship’s mission configuration.


Here’s where I left the paintover and decided to come back to modeling:

And here’s the current state of the model! The main hull is frozen and optimized here, though the modules, nacelles, and bridge (not pictured) are still unfrozen. I actually frozen the main hull at two detail levels (2 subdivisions and 3 subdivisions), then chopped certain pieces out of the 3-sub mesh and welded it into the 2-sub mesh in order to deal with some segmentation issues. Worked out surprisingly well and isn’t a trick I’ve tried before.

The hull texture on there is just something I slapped together to test for UV distortion2 and probably won’t end up as a final texture in any way.

  1. Some crude measurements of Sovereign windows indicated a width somewhere between 1.9 and 3.8 feet, leaning more toward the former []
  2. Of which some does appear along the center axis, which I’ll need to clean up []
Jan 212014
 

This post is part of a meta-series. Click here for a list of all posts in this series.

Finished merging the saucer and stardrive into one continuous mesh this evening.


Still have some cleanup work to do before the subsurf is smooth enough, but it was far less of a bear than I expected it to be. I love how hunchbacked the ship ended up looking with the catapult platform drawn way far out into the stardrive. Before, the slope from what used to be the impulse deck was very gradual and kind of boring. Now? Coro is out to give someone a beatdown. 😀



Jan 132014
 

This post is part of a meta-series. Click here for a list of all posts in this series.

This one’s going to require some backstory. 😀 But please do read it, as it will answer what are sure to be inevitable questions.

In 1991, the Star Trek: The Next Generation Technical Manual came out, as a codified version of the show’s technical bible intended for public consumption. At the very end of the book, the authors (Rick Sternbach and Michael Okuda) included a set of four drawings for the potential future direction starships might take, ranging from familiar to bizarre. One of those designs has a pretty clear lineage in becoming the Sovereign class.1 Another of those designs, though, had an interesting arrangement of modular segments comprising its saucer, along with wide warp nacelle pylons meant to allow the warp nacelle position to change mid-flight.2

An artist you might have heard of, Mark Kingsnorth, made a rough model of this ship in the late 1990s that gained some notoriety. It came to the attention of a fellow that goes by the handle “Jester”, who asked for Mark’s permission to use images of the model on a Star Trek IRC-based role-playing game website. The name of that game was U.S.S. Coronado…and I was one of the players.

Mark’s interpretation didn’t quite fit with what Jester wanted out of the ship. Jester called it the Katana-class, a frigate-sized ship centered around two major technologies: the launching of small, one-man fighter craft and the use of quantum slipstream drive.3 A neophyte CG artist myself at the time (1999), I offered to take a crack at providing Jester with an “in-house” version of the model that we could use to make any sort of shots he wanted. I knocked together a—by current standards—crude model in trueSpace, and away we went!

Later, in 2003, another player (and close friend of mine) on Coronado would build a new set of 2D orthographic blueprints, riffing on Sternbach’s original design and incorporating the various design elements that Jester had always intended for the game, namely the “slipstream” deflector as seen on Dauntless in “Hope and Fear” and catapult-style hangar bays for the ship’s Spectre class fighters. Having improved in skill significantly since the first trueSpace model, and now working in LightWave, I used these blueprints to make a new model of the ship.

The game ended in 2004, after 7 full years. Jester chose to end it then, since it mirrored the seven seasons enjoyed by TNG, DS9, and VOY. As a gift to both Jester and a wedding gift for the blueprint maker, I had a 36×24″ poster of the ship’s ortho renders and a few action shots, accompanied by specifications and signatures from many of the players, printed out for each of them, as well as myself. My copy currently hangs in my living room.

This year marks the 10th anniversary of Coro’s last game, which took place at the end of August. For the finale’s decennial, I wanted to create a new model that goes back to the sources that first inspired Jester — Sternbach’s original design and Dauntless from “Hope and Fear” — and more intelligently incorporate design elements that would speak to the Katana class’s lineage — namely, those seen on the Sovereign class.

(Side note: Mark Kingsnorth went on to revisit his original take on Sternbach’s design, which has gained quite a bit of notoriety as the Insignia class.)

Coronado model timeline

So far, I have been focusing on locking down a completely new approach to the aft saucer, taking a lot of cues from the Sovereign lines on the dorsal surface and trying to more closely match the Dauntless lines on the ventral surface. I’ve been doing a lot of quick, rough renders and mock-ups, then painting over them with my Wacom tablet in Photoshop to explore different lines and arrangements. I’m using the player-made blueprints as a starting point for scaling, but not treating them as sacrosanct the way I did for the 2003 model. The following images show the evolution of the model from Jan 9 through to today.

Saucer design exploration, focusing on the flight deck and impulse area

Stardrive design exploration, emphasizing the Dauntless-esque shape.

My goal is to have the model render-complete by the end of August, 2014, which coincides with the 10th Anniversary of Coro’s last sim.

  1. Albeit with a widened saucer, rather than the elongated one that Sovereign ended up with []
  2. An idea that would eventually manifest with Voyager’s variable warp nacelles []
  3. Originally featured in the Voyager episode “Hope and Fear” []