ACBC Commercial

One of the worst thing about a lot of the work I’ve been doing lately is that I can’t share it just yet. But, such is the nature of this kind of thing. Eventually, I will (hopefully) be able to reveal all. In the meantime, here’s something fun that I did for ST:Equinox last week that I’m finally able to show. In fact, I’m sure they’d prefer that I did, since exposure is everything. (because, after all, I draw a huge audience :P )

Note: If (when) the video is offline at any point, it’s because somebody requested changes. So, if you try to watch it and that happens, please check back later. Sorry for the inconvenience, but it’s certainly not my choice.

Busy Day at the Starbase, 2015 Edition

I spent an almost fruitless week dorking around in Blender. My goal was to switch from Lightwave to Blender and from Windows to Linux Mint. Well, that was rendered moot. I tried at first playing around with some tutorials about modeling. Modeling wise, Blender ain’t bad. There are tools I have in LW that I wouldn’t in Blender, but I’d have adapted. Then I dove into Cycles, Blender’s realistic render engine. I can’t express enough how much I love that render engine, for the most part. For people who don’t know, “standard” CGI rendering engines are hampered by unrealistic lighting. In CGI, light travels in one direction and hits an object from that direction. Any face going the other direction isn’t lit. Period. This is in contrast to lighting in the real world. In the real world, if you have an object with a light behind it and other objects in front of it, such as furniture, walls, ceiling, etc, light will bounce off of those objects back at the previous object, lighting the “dark” side. Most CGI software has a solution for calculating this light bouncing. In Blender, it’s part of the Cycles render engine. It calculates the light bouncing to create a more realistically lit object and scene. I imported a few of my Lightwave models into Blender which, for the most part, went well. As long as I triangulated my faces with more than 4 sides in Lightwave and applied the Edge Split modifier after import, most everything looked grand. Cycles has wonderful emission materials. However, I ran into issues with applying textures to my imported models. Again, for people who don’t know, this is how textures are applied. There’s a projection setting that tells the image where to go, how to be oriented and, most importantly, how to be mapped to the object. Most software has various options for this. There are four basic types of mapping: plane, cylinder, sphere and cube. They are what they sound like. Plane puts your map “flat” on a surface, where the others wrap it around in the appropriate shape. Then there’s unwrapping, where the map is put on there based on the object’s geometry. This is the most difficult and problematic method. Cycles, meanwhile, only has unwrapping. There are several options to unwrap the object, but they don’t necessarily work like they do in other software. IE: selecting “cylinder” doesn’t wrap the map around the object in the shape of a cylinder like it should. And, there are pretty much no controls over this stuff like you have in a lot of other programs. And, by the way, that’s not just me talking. I took a screen shot of what I was trying to do and a friend who is very proficient in 3DS Max commented on the lack of control. So, after a few days of spending many hours trying to get one simple map onto a nacelle the way it should work and does work in Lightwave, I got mad and gave up. So, for those people who keep saying I should “give Blender another try,” I did. Until they fix the texture mapping in Cycles, I won’t be using it. For the record, the Blender Internal rendering engine has “normal” texture mapping, but it doesn’t apply to Cycles because the material settings are different.

So, where am I going with all of this? Back to the light bounce thing. As I said, Cycles is wonderful at calculating light bounce. Well, Lightwave is professional software, so it naturally has settings that do this as well. Though, unlike Cycles, it’s an option that can be activated in the standard LW rendering engine, not an entirely separate engine. So, things like texture mapping work exactly the same. It’s called Radiosity, which is a very popular way of simulating light bounce. So, I spent last night messing around with Radiosity in Lightwave. I like it a lot. Truespace also had Radiosity, though I never messed with it and I don’t know why it’s taken me so long to do so in Lightwave.

So, I decided to redo one of my renders with Radiosity enabled. I’m much happier with the results. As you can see, things like the shuttlebay alcove and inboard side of the starboard nacelle on the Scout have a faint light hitting them, which is bouncing off of the hull back at those areas. Areas on the other objects are also lit by the light bouncing, which makes the whole scene look more realistic. Of course, some areas are still very dark, this is due to nothing being there to bounce the rays back. And, for those who are wondering, rendering with Radiosity only took about 5 minutes longer than rendering without, and that was due to the amount of time it took calculating the Radiosity.


If you want to see the old version and do a comparison, here’s a link:
(the link will open in a new tab)

USS Allura, Pt. 08

Well, today started with a bit of a setback. I was making my shuttle bay doors when I came to the conclusion that there wasn’t much space above them for them to roll up. Likewise, there wasn’t enough room to put in doors that slid side to side. So, I had to redo the opening. I looked at some shuttle sizes and a shuttlepod is roughly 1.8 meters tall, whereas the huge Type 7 shuttle from TNG is only 3.8 meters tall. So, I didn’t need a nearly 6 meter opening, especially since this ship probably carries type 6 or type 8 shuttles, (depending on which I feel like building) both of which are only around 2.7 meters tall. So, I made the opening smaller, giving it more room from the top of the door opening to the bottom of the cowl, like Voyager has. Of course, since this was all booleaned into place and smoothed into the hull, I had to redo the whole thing. But, that wasn’t that big of a deal. I prefer doing a little extra work if it adds at least some level of believability to my design. (I don’t care what the dictionary says, believability should be a word ;) )

Then I added the saucer docking ports. I had to inset them into the hull pretty far to get them to work, but that’s not a big deal for docking with something like a starbase (see: the TNG episode “11001001”) or the upper or lower pylons on DS9. However, the ship may dock with something else, so the idea is that the big cubic section that the airlock is set into can actually extend outward, to allow better alignment. No, it’s not rigged to do so, I’m just saying that’s how it would work if rigged to do so. ;) And, for those keeping track, the docking port is the same design I’m using on my destroyer, for continuity sake.

And, most important of all updates, I moved the bridge forward 2 meters. :P





USS Allura, Pt. 07

I decided to work on this ship some more today. I apparently went insane, because I decided to model all of the little vanes that glow blue in the nacelles as individual tubes. This creates the look I want for that part of the nacelle, which is basically a Galaxy/Intrepid class look. Of course, that meant I needed an “interior” for the nacelle, which was a bit of a pill to build, but I did it. Then I made the frame for the shuttlebay door.





Dominion War Destroyer, Pt. 07

It took a while to come up with a navigational deflector design that I like. Ctrl+Z and Delete were used a lot during the process. ;) One thing I don’t like are what I call “lazy” deflectors, where somebody just adds a texture with some glow. For ships from the ’90s, such as the CGI ships in First Contact and Deep Space Nine, I get why they did that. They were rendering on ancient computers with no processing power and they needed to save memory usage where they could. However, in this day and age, there’s no good reason to not add some real detail to bits like a nav deflector. I finally settled on a dish that juts out a bit as a nod to the original ship. Behind it, I wanted something more than just a glow. I noticed that Voyager has vanes in front with the glowing bit behind that, so I decided to go with something like that. The vanes were a royal pain to do, but I figured them out. Eventually, I’ll do a gradient (probably a texture) so that the center glows brightly and it fades out towards the sides, like the one on Voyager does.



Dominion War Destroyer, Pt. 06

I started on the weapons with the dorsal saucer phaser arrays. Being a destroyer, this ship is going to be well armed. The cut-out section in the front is going to be a weapons cluster, with torpedo launchers and pulse phasers. There will also be rear torpedo launchers and type 10 phasers all over the place. I also added the escape pods. I based mine on the pods from the Vesta class, designed by Mark Rademaker. The Vesta class has pods similar to the ones from the Sovereign class (and, due to photos of the Ent-E being used to texture them, the Steamrunner and Akira classes) but they’re slightly different. Instead of being inset in grooves, they’re protruding slightly. Also, the scale on the ones on those other ships is questionable, where Mark has designed his to a specific size, which is how I like to do things too. He illustrated on Scifi-Meshes recently that the pods can hold 10 people. There are 30 pods on my ship, giving it a 300 person evacuation limit. (not counting shuttles) I don’t figure the ship has a crew anywhere near that size, but it is a combat ship and may be called upon to beam up people from a planet or from a ship that’s in distress. Then, if it’s destroyed, those people need to get off the ship somehow. ;)





Dominion War Destroyer, Pt. 05

I fixed the error in the grid lines. If you don’t know what the error was, that’s fine. However, suffice to say, there was an error and now there’s not. It involved some surgical removal and cutting and pasting, but it’s all better now. ;) I also added port/starboard docking ports to the saucer. I have them a bit farther forward than I normally would because the impulse engines are going to go on the back edges of the saucer and I don’t want the ports there due to the impulse internal components. I also added some RCS thrusters, which it’s OK to have near the impulse engines. (it all has to do with movement ;) ) And, lastly I added some windows. I may do a few more, but this is probably going to be most of them. I know, some people think a destroyer shouldn’t have windows because they’re weak spots, but most Federation ships have them. Besides, I looked up real destroyers on Wikipedia and some have portholes, some don’t.




Dominion War Destroyer, Pt. 04

More stuff, mostly a bunch of grid lines and some other details that are built into the hull. Except the bridge, that is. That’s a separate part, but I tried to make it look like it’s not. I was thinking while I was doing them that it’s ironic that I went to so much trouble to make a seamless, smooth hull only to cover it in lines that look like panel separations. ;)