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 []
Jan 042014

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

All the escape pods are now textured and uniquely numbered. Their numbers are drawn from a big 18×22 grid of digits of pi and then randomly shuffled through some arcane mapping to show a (probably) unique triplet of digits based on the pod’s object identifier.

Moving on to the shuttlebays…



Might I actually finish it this weekend? 😮

Conference room textures are done!

I’m not worrying about them too much, since it’s mainly meant to be see from a distance and provide a sense of internal space rather than be a digital set or anything.

Almost there! 😀

Dec 292013

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

I have seen a lot of talk about how much faster and more efficient Cycles branched path integrator is compared to its normal progressive integrator, since sample count for each type of ray (diffuse, glossy, transmission, etc.) can be controlled directly. Ostensibly, this allows you to get rid of noise with fewer overall samples and each “subsample” is faster to compute.1 Well, try as I might, I could never make the branched path integrator’s output match that of the regular integrator. The regular integrator always seemed to produce faster, cleaner results.

But in poking around for information, I did realize a huge mistake I had been inadvertently making all along! 😮 You see, each material has a pair of settings down at the bottom: Multiple Importance Sample and Transparent Shadows. MIS, as I (erroneously!) understood it, increased the precision of the sampling of a surface when it was emitting a large amount of light — when an object was functioning as a light source, essentially. All of my glowing materials have this enabled, including the rooms, glow panels, and so on. Transparent Shadows is, as you might expect, a switch that enables or disables the casting of partially-transparent shadows through a transparent material. Only three or four of my materials are transparent, and none of them need to worry about casting special shadows, yet nearly all of my materials had this turned on!

So, first I set about disabling Transparent Shadows everywhere, knowing that this would speed my render times up a little bit. But I also did some further reading on MIS…and came to realize that it’s meant for dominant light sources, to improve sample convergence! Dominant light sources. Not every single room inside the ship, every single lit-up panel, and so on.

I set about turning MIS off on almost everything and holy bejesus did that make a difference! Whereas I could barely get a low enough noise level out of a 4000-sample render before, I could now do it in a mere 1500 samples!

But I wasn’t done yet.

In playing around with the branched path integrator, I’d gotten a little more familiar with rendering individual passes out (e.g. indirect diffuse bounce, direct diffuse, diffuse color, etc.) and I’d read a great deal about Blender’s vaunted Compositor, but never used it. I decided to give it a spin, with the goal of gently blurring the indirect bounce layers to further reduce noise. Aaaaaand then I got carried away. 😀

Original “vanilla” composite with just indirect noise reduction

Enhanced composite

Really, this only features two additional filters from the Compositor: a Glow applied to a mix of the Emissive and Transmission passes2 and a bit of Lens Distortion to help amp-up the idea that this is a photo someone took, rather than a render someone made. I’m quite pleased with the results, but certainly open to feedback on them as well!

Used some goofy shader tricks to add decals to the hull with bounding-box-generated UV coordinates and make them appear only on one “side” of the mesh based on its normals, rather than projecting straight through. I need to circle back and take care of the neck “collar” and all the various dark bits and that should about do it for this part, unless anyone sees anything that still needs work.

Then it’s onto the pylons!

A couple of random musings:

  • That “dark” hull material3 really needs to get a proper texture pass. Sticks out like a sore thumb at this point.
  • The difference between the textured engineering hull and the untextured pylons is staggering and probably one of the biggest weaknesses in this render. More motivation to keep on texturing!
  • From some angles in particular, the windows vs. gridlines look really goofy. If I ever get up the gumption to revisit this model down the road, ripping the stardrive apart to redo that layout in a more sensible way (rather than adhering to the studio model as much as I did…which even then was a rather wide departure in some cases) is high on my list of priorities.
  • I love that the port nacelle casts a shadow on the engineering hull from this angle. It’s a dumb, obvious thing but it makes me smile.

Pylons proved to be pretty easy to both UV and texture, including the decals! Maybe I’m just getting used to the workflow. 😀

The landing area near the base of the shuttlebay will extend all the way in; I just haven’t gotten around to that particular texture yet.4 On an unrelated and somewhat superfluous note, I should probably back the strength on the fill light off.

I…don’t really have anything to say about these. 🙂

  1. Link is to a Maya article, but the same principles apply to Cycles []
  2. Most noticeable around the warp grille, the impulse engines, and the lights on the sensor dome []
  3. Evident beneath the impulse engine and on the horizontal neck “stripes” []
  4. It’s not actually the same one as the rest of the engineering hull []
Dec 182013

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

I have started to texture the neck and stardrive section.

I can already see that some of the paneling textures are going to need to be a little better tailored near the seams in the various UV islands, but c’est la vie. I’m also thinking about backing off the saturation of the various colors. I know I said before that I liked the strong paint scheme, but something about it just isn’t sitting quite right. Maybe a drastic step isn’t called for, but I can’t quite place why it bothers me.

I’m also absurdly unhappy with the lighting setup I have right now. I should probably sit down and just play with lighting for an entire afternoon or something, but lighting’s probably something I’ve struggled with longer than even texturing. I’ve never concocted a lighting rig for a model that I was really happy with. Anyone have any good resources along those lines they might point me toward? Preferably something that either deals with “real” space lighting or matching the Trek look.1

The reason the previous render(s) look so awful ended up —as it always does—being my own forgetfulness! You see, all of the textures feed through a fairly elaborate custom shader Group Node that does fun channel mixing and shadery stuff. The Group Node has settings exposed, resembling the traditional diffuse/specular/bump controls that pretty much everyone’s familiar with, to control the strength of the individual textures. I, uh, had totally forgotten that the defaults I originally set for these aren’t really ideal.

This is the exact same render, same camera angle, same exact textures, no changes whatsoever to the model. The only difference is a new lighting rig2 and corrected settings on my shader parameters.3

Open the previous one and this one side-by-side for ultimate effect

That said, there’s still a decent amount of sample noise in this render, despite cranking the samples up to ~3000, so I may try over-lighting it4 and then futzing with the exposure as a post effect.

Substantially happier with it than I was before, though!

I spent far too much time on this for the amount of physical space it actually occupies on the model, but… airlock door!

All the detailing on that door is textured. It’s just a flat triangle fan.

On the downside, I had to crank the sample count up to 40005 to get rid of all the sampling noise. May be time to experiment with Cycles settings again and figure out the real cause of the noise. I think it’s to do with low light levels, which I should be controlling in post rather than in the first-pass render itself, but I haven’t proven that out yet.

  1. I really dig what tobian has going on in his Endless Pluto Station thread, lighting-wise. []
  2. Very, very low environment sky gradient light; very, very low “soft box” light; slightly-less-low upward-facing, camera-vector fill light; bright key light at roughly 90° angle to the camera []
  3. Diffuse roughness, glossy map strength, glossy map roughness, and bump strength []
  4. Sample noise tends to happen worse when the light levels are low and the object is large and complex, as it is here []
  5. Translating to a render time of ~1.5 hours []
Oct 282013

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

The RCS thrusters on the saucer now have red warning(?) markers around them now and I fleshed out the textures on the saucer rim1.

I also added2 some darkening at the foot of the A-B-C superstructure to help it sit on the saucer better. While I think it achieves the effect, I also think it’s a little too strong right now. I’ll back it off some in the future.

Finally got around to texturing the transporter pads. There are 35 horizontal dark bands for each pad, which matches the ones on the dorsal saucer of the Galaxy class and seemed like a good benchmark to use. Every transporter pad on the ship is now textured and UVed3. I also solidified the darkened line around C-deck. It looked too much like a mesh error. While the new solid band doesn’t match any of the existing colors in the set of color swatches I’ve been trying to stick to, it’s at least in the same family and achieves the desired effect of seating C-deck.

Also did some tweaking to the saucer rim around the RCS thruster. Fixed several of the errors I called out in the previous image and futzed around with the placement of the mapped grooves. I’m still not 100% happy with them, but I’m not sure they’ll get much better without reworking the UVs so that the entire area has more resolution. As I do not relish that idea, I’m content.

I wasn’t happy with the resolution on the red RCS thruster markings, so I added some geometry around them to really enforce the definition of those red lines. Didn’t require any changes to the texture, but required a bit of vertex pulling in the UV to get it to sit where I’d already painted in the red.

I also threw on a little registry stamp behind the upper shuttlebay, similar to the one on the Galaxy. It’s not present on any of the Ambassador studio models, but the studio models are pretty light on registry markings in general.

Still need to carve out an actual surface detail area for the dorsal saucer registry light and then I need to swing down to the bottom of the saucer now and do the ventral registry. At that point, excluding the lifeboats and shuttlebay…the exterior saucer texturing might be done? Maybe?

All right, I’m declaring primary texturing on the saucer done!


Ultra-closeup of the new registry lamp, close enough that the texture resolution breaks down horribly. :p

The escape pods and interiors4 still need work, and I want to revisit the phaser shader5, but UVing and texture painting are in a place that I’m happy with. I still need to fiddle with the overall hull shader to incorporate that iridescent effect, but that’s more of a final polish effect.

Fun note: the lights illuminating the registry are still unphysical in their placement and the ventral registry light is even unphysical in its falloff! The curve of the hull just isn’t conducive to lighting them in the way they’re “supposed” to be lit. It was a toss-up between providing non-traditional, but physically plausible light sources or sticking with the traditional visual configuration and breaking the physicality of it.

  1. Previously, it had only the color bands and no spec/bump detail []
  2. Manually, since no easy solution for “baking” the data in presented itself []
  3. Huzzah! []
  4. And everything relating to the shuttlebay []
  5. Which looks weird and very dark from a distance []
Oct 162013

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

The stuff above the upper shuttlebay has textures now!

Disregard that random crap near the shuttlebay doors; none of that has been UVed or textured yet. I’m going to take care of all the interior texturing once the exteriors are done.

Debating whether to finish off the top of the saucer (transporter pads, escape pods and decals, phasers, and insignia markings) or if I should move on to the sensor array on the bottom of the saucer and then hit the other smaller pieces that are shared between dorsal and ventral in a single pass. Doesn’t really matter, I guess.

I’m up to ~365 hours on this project, 307 of which have been in Blender.

Sensor dome has all of its primary texturing on it now. I think this is the last “main” saucer texture (interiors aside).

I have mixed feelings about this render, but it’s progress all the same, so here it is.

Tonight was a big experiment. I wanted to see if I could get decal text onto the ship without having to do a second UV pass or any sort of goofy “cut out a section of polygons and map just it with the registry” process. In addition to standard UV coordinates, Blender also supports “Generated” coordinates, which just use the bounding box of the mesh as a single polygonal span. You can then futz with the generated coordinates by using a vector mapping, or you can just treat the bounding box as your texture’s dimension and map 1:1.

That’s what I did here. The up side is that it makes positioning text really easy1, but the downside is that even a 4K texture2 looks pixelated, because the actual texture real estate in use is tiny. However, now that I know that Cycles was doing some goofy caching stuff, I should be able to make the vector mapping play with the generated coordinates a little more nicely, which will let me devote a giant texture to just the registry text.

The registry light isn’t very effective with all of the extra scene light, which also looks really blah. There’s something distinctly different about the underside lighting and the topside lighting, despite the key light for both being the exact same. I’m going to have to investigate why the light quality feels so different. Additionally, I’m thinking about carving in a little light panel to be a physical source for the registry lighting. It bugs me that it seems to come from no where right now.

I also created a shader for the phaser arrays that I’m pretty happy with, mixing Blender’s Glass and Velvet shaders to create this neat sort of soft “pseudo crystal” material.

And, yes, the lifeboat hatches are ugly. I know. I just wanted to put some of the hull texture on them to break up the monotony. My ultimate plan, which I’m going to save until the very end because it’s easy-but-tedious, is to work up a single hatch with a nice texture all its own and then instance-clone all the other hatches off of it. What you see now are all clones of the original master, but I “froze” them into specific groupings for easier positioning. I’ll keep these around for now and use them for position reference when I introduce the instance clones.

If I can figure out a good way to do it, each lifeboat hatch will be individually numbered, too! :p Maybe. If that proves to be really annoying, I’ll probably just give it the ship registry.

Anyway, that’s a lot of text to explain away my moderate embarrassment about this render.

First, the main registry is now its own 4K texture, the largest individual continuous span of texture pixels on the entire model3. This has improved its clarity dramatically, to the point where I don’t feel quite so embarassed showing a close-up render of it. 😉 The other small but tedious addition comes in the form of the red “warning brackets” around each of the dorsal phaser strips.

One thing the second render really highlights4 is the need for some additional “fake” AO around the base of the A-B-C superstructure. The transition between the saucer and C deck is really jarring right now, glaringly digital even accounting for the poor lighting plaguing the top of the saucer. Adding a little mutual darkening to this area should help. If I had the patience to figure out Blender’s AO baking (which Cycles doesn’t support, so I’d have to kick out of Cycles, figure my way around Blender Internal, bake out the maps, then switch back — yuck!), I might just do a proper AO pass and include that as part of all of the textures, but I do not have said patience! There’s an AO node in the Cycles shader engine that I might poke at to see what it does, or I might just bite the bullet and paint it in by hand.

For those curious, I calculated that I’ve now spent over 0.145% of my life working on this project. That’s not the computation spanning “when I started” to “now,” that’s actual hours worked compared to actual hours lived. The “when I started” to “now” percentage is around 4%. A labor of love indeed.

  1. Though there was a lot of trial and error while I wrapped my head around exactly what Blender was doing behind the scenes…and what Cycles’ viewport render was caching, making me think things weren’t working when they were! Fortunately, my wife decided to watch over my shoulder for a bit and asked “Well, are you sure it’s reloading? Derp, it wasn’t! []
  2. which this is! []
  3. each saucer “quadrant” is also effectively 4K, with each eighth occupying a 2048 strip []
  4. other than desperately needing to texture the transporter emitters []
Oct 052013

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

Finally an update! Although a somewhat unglamorous one. Been doing a ton of experimentation, cleanup, and method optimization to try to make this process less painful in the future by enduring the pain now. Stuff I’ve learned while doing Defender has also given me some ideas for improving how I approach certain problems, too.

One of the things I’ve been focusing on is trying to get my Aztecs to have a consistent scale. I looked over the Excelsior saucer and gauged that its Aztecs were each about 7m “tall” (if you think of each repeated element as a single “Aztec”), so I decided to match this scale. Some annotations in the image about this.

The other thing I’ve been futzing with, aside from correcting my over-zealous material reassignment (which wiped all the shield grid material assignments; figuring out how to quickly and efficiently select the “right” polygons for this has been a major timesink, but I’ve got it down to a science now!) is material unification. I’ve been wrapping my head around Blender’s Node Grouping system, which is really cool. Took some getting used to, but I have all the materials setup now so they have three texture inputs going to a single Node Group that does all the fancy schmancy stuff like balancing specular reflections, incorporating the iridescence (which I’ve actually disabled for now, with the intent to revisit it once I get the hand-painted stuff nailed down more), and so on. The best part is that I can tweak this Node Group and affect all of the materials in one operation now, while keeping their texture sources independent. Fun stuff!

All of the saucer materials now have correctly sized Aztecs…sort of. The sizing is correct on the texture, assuming the UVs are laid out correctly. They’re…probably not. But I couldn’t help but do some quick renders, since it looks like actual progress for once.

The orange/blue/red on the top of the saucer just highlights different UV shells. It won’t be part of the final texture.

I temporarily dropped the smaller panels for these renders, since I need to regenerate them with my new Aztec scale calculations, which is why it doesn’t look quite as interesting as before. Also retooled my light rig (again) to show them off a bit better. Still, pretty happy with the general direction this is going in, especially since it means there’s light at the end of the saucer UV tunnel! I’m optimistic that the other parts of the ship won’t be nearly as hard to UV.

I spent a bunch of hours this evening tweaking the UVs so that all of the Aztecs are the same “height” along the surface they span. They were close before, but not quite. I also used this as an opportunity to clean up UV distortion around the windows and RCS notches. To illustrate exactly what changed, here are before and after renders of the dorsal and ventral surfaces of the saucer with the contrast amped way up. It’ll probably be easiest to see the difference if you open each render in a new tab and then flit between them. (Note: the position of the color bands shifted as a result of this too, which I still need to go back and correct for.)

Before / After

Hopefully, the majority of the saucer UV work is now done(!) and I can start doing some texture work on it in earnest!

Starting actually look something like a Federation starship now! All the colored bands are now in their correct positions, the Aztecs all wrap correctly now, and I’ve added some multi-colored paneling to both the diffuse and spec maps.

I need to tone the spec map down/futz with the balance of it a bit still. It seems a little strong at the moment. I also still need to make a bump map and incorporate a bit more grit and grime and surface structurey bits into all three maps. Still, I suspect the saucer UVs will end up having been the hardest of all of the components, so…yay!

Toned back the spec map to a level I’m happy with. UVed the dorsal saucer superstructure (A-C decks), with the exception of some of the greeble bits (escape pods, transporter pads, and the equipment over the shuttlebay). Started texturing the lateral edges of B and C decks.

Kind of amazing how much difference just a little panel variance makes. Realistically, I should probably correct the skew that shows up as B and C deck stretch toward the back, but I’m not sure that I will. I suspect it will end up being a lot more of a pain than will be visually worth it. I’m also thinking about toning down the shades of blue. The darkest blue, in particular, feels really dark. On the flip side, I kind of like how striking it is, so…who knows? 🙂

Contrary to my statement that I probably wouldn’t correct the skew, of course I did. I can’t leave well enough alone! Also went ahead and finalized the material that goes in the shield grid troughs. It’s a pretty generic dark metal, but I think it works pretty well. Of most obvious note in this update, however, are the textures for the bridge.

I’m thinking about toning back on the intensity of the colored panels. The idea is to introduce subtle variation, but at this range the variation isn’t subtle at all. I also still need to make bump maps for, well, everything. I’m holding off on that for now, though, and focusing instead on diffuse and spec maps while I hammer all the UVs into place.

Next up is probably that stuff above the shuttlebay. I also need to do something about those escape pods…

Sep 012013

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

Farting around with reflectivity in the aztec and also adding in iridescence to the shader. If you look really closely, you can see the aztec pattern start to show a greenish tinge around the edges of the “bulb.” It’s an effect that’ll be much more pronounced in motion than in any still.

(I turned off the other saucer materials for this render to highlight the area that actually has anything done on it.)

Texturing the saucer

 Posted by at 23:59  No Responses »
Aug 202013

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

Well, it ain’t much, but here’s the product of about 15 hours of UV and texture work thus far. The map is just a simple color map with absolutely no detail to it whatsoever yet, nor any specular or normal/bump applied. Just trying to get the layout working. The narrow dark blue band is the end of the map, which is why the hull beyond it (where the phasers and sensor dome are) is just the normal blank off-white color.

Total project time so far is 338 hours now (about 293 of that in Blender).

UVed the flattish, top-most part of the upper saucer tonight in far, far less time than the bottom flat section took. Used a different selection technique this time, which I cooked up at the very tail end of the bottom flat section UVs, and am delighted that it reproduced so well. Once I’d done that, I decided to start doing a little texture work to see how the Aztec pattern might look, along with a bit more detail to the hull panels themselves.

This is still just a single color map, no spec or bump work. I suspect I’ll tone down the panel visibility a bit and I think I need to tweak some of the vertical positioning of the various “rings” in UV space to get a more uniform distribution, but I like how it’s coming together so far. Next, before doing more UV stuff, I might play around with the hull shader a bit to see if I can’t start making the pearlescent effect I have in mind work.