I have not been idle while the forums were down and indeed have done a great deal of experimenting and research in the interim.
Wall of Text Incoming!
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 (link is to a Maya article, but the same principles apply to Cycles). 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! :eek: 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. :argh:
End Wall of Text
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 passes (most noticeable around the warp grille, the impulse engines, and the lights on the sensor dome) 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 material (evident beneath the impulse engine and on the horizontal neck "stripes") 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 (it's not actually the same one as the rest of the engineering hull). On an unrelated and somewhat superfluous note, I should probably back the strength on the fill light off.
The remaining to-do list, in approximate order:
Nacelle textures and decals
Escape pod mapping and textures
Lower shuttlebay interior textures and materials
Upper shuttlebay interior textures and materials
Conference room interior textures and materials
Special arboretum mapping and texture
Special forward lounge mapping and texture
General room texture and re-mapping (as needed)
Material/shader tweaking pass (esp. phasers, the glowy bits on the warp nacelles, and the generic "dark hull" texture)
Pearlescent hull material experimentation
I think that's it, unless I've left out something obvious. I wonder if I can get all that done before the end of the year...
"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."
That caught my attention. Can you direct me to a tutorial or elaborate a little on this.
That caught my attention. Can you direct me to a tutorial or elaborate a little on this.
Certainly, but it's a bit technical.
Blender's node network has a Texture Coordinate node with a bunch of different outputs. Among those outputs are Generated and Normal. Generated represents a bounding box wrapped around the entire mesh and mapped accordingly. Normal refers to the normal vector of the face in question. Blender also has a Mapping node, which allows for manipulation of an incoming vector by translation, rotation, scale, and repetition limit (min, max). When applied to UV(W)s, the XYZ translate directly. 0.5m on X is equivalent to 0.5 U in UV space, for instance. However, the 0,0,0 coordinate in UVW space isn't always intuitive, especially when dealing with Generated or Normal coordinates. I suggest trying these nodes out on a Cube first, just to get a sense of them.
Since I have these decals that don't necessarily conform to the UV mapping of the rest of the texture, I want to use Generated coordinates to position them where they're supposed to go. In this case, the registry on the side of the pylons serves as a great example, but basically any text or iconography on the ship is applied the same way. So, if I take my Texture Coordinate node and plug the Generated output into a Mapping node and then the output of that into the Vector input of the Image Texture node, I can dictate its position on the object by manipulating the Mapping node's settings. Usually, I want to clamp it to Min 0 and Max 1 so I only have a single instance of the texture, rather than lots of repeating instances. Then it's a matter of tweaking the position, rotation, and scale values to position it all correctly.
However, if I do this for one "side" of the pylons, it projects through on all four faces (port outer, port inner, starboard outer, starboard inner). That's no good, especially when I want the very orientation of the decal to be reversed on the starboard side as compared to the port (i.e. the "NCC" is toward the forward edge of the pylon on the port side, but the aft edge of the pylon on the starboard side). I also only wanted it on the outward-facing side of the pylon, not the interior-facing side.
In order to accomplish this, I need to grab the Generated and Normal vector information from the Texture Coordinate node. Each of those outputs is actually a three-vector, containing XYZ or UVW. I can split out these vectors using a Separate RGB node and extract just one of them. In this case, I wanted the Generated vector that corresponded to one half of the mesh (+X or -X) or the Normal vector that corresponded to "facing outward." By running these through different Math nodes (Multiply by -1 to get the -X, Add with a 0 and "Clamp" turned on to get only the left or right side) and also Multiplying them together, I end up generating a "mask" that only projects the decal onto the very specific set of polygons that meet the criteria I want. I then multiply this mask by the Alpha channel of the PNG that contains the decal itself to get the "final" alpha channel that mixes with the main Image Texture of the hull map.
It's incredibly convoluted when first putting it together, but once you get a sense for what needs to go where, it actually becomes easier and faster. For the engineering hull, I actually made a group node that handles all of the work of deciding which computed mask to supply for the lateral banners on either side of the hull. I couldn't quite re-use that for the pylons, since I also needed to account for normals in this case as well as which half of the model I was on, but the principles are exactly the same.
If that's not clear enough, I can try to go into more detail or write-up a more thorough tutorial. Let me know!
A wonderful explanation. I may be back with questions. The idea is revelation. While I've used blender, I'm far more experienced with Max. In Max you can likewise project textures so I hope to adapt the technique. It's a great idea and new to me. Thanks.
Wouldn't the escape pods on the upper aft engine section, near the nacelle pylons smash right into the nacelles?
From that angle, it certainly seems like it, but have a look at the ortho from the rear:
Plenty of clearance.
All the escape pods are now textured and uniquely numbered. Their numbers are drawn from a big 18x22 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...
To Do:
Lower shuttlebay interior textures and materials
Upper shuttlebay interior textures and materials
Conference room interior textures and materials
Special arboretum mapping and texture
Special forward lounge mapping and texture
General room texture and re-mapping (as needed)
Material/shader tweaking pass (esp. phasers, the glowy bits on the warp nacelles, and the generic "dark hull" texture)
I'd doubt nacelle seperation would be a standard part of the abandon ship routine. Normally you're likely going to destruct the ship when yoiu abandon it to keep your miltech out of foreign hands, and separating the nacelles would make it harder to completely blow up the whole ship.
One question I have it on the escape pod designation: Would't they have an alpha numeric code to make them easy to identify and know the location of in an emeregency? Something that designiated the deck and section they were on to make it easier to find your pod in an emergency?
One question I have it on the escape pod designation: Would't they have an alpha numeric code to make them easy to identify and know the location of in an emeregency? Something that designiated the deck and section they were on to make it easier to find your pod in an emergency?
From Voyager, we know that the numbering on even adjacent pods on the same deck can be wildly different.
So, my guess is that the actual pod number is completely arbitrary. If you eject one escape pod for some reason and then get a replacement at a starbase, it'll have a new number, not the same number. The internal designation for the pod surely refers to its location and deck, as you describe, but the external number on the pod probably has nothing to do with that internal number. It seems more like a registry number or something along those lines.
McC, you said you were using Blender? Would you mind posting a screen cap of your node editor so I can see your set up for the glow effect? That is unless it's your trade secret.
McC, you said you were using Blender? Would you mind posting a screen cap of your node editor so I can see your set up for the glow effect? That is unless it's your trade secret.
Glady! I don't much care for trade secrets. If I can help someone out at all by sharing what little I know, I am more than happy to!
Assuming you're just curious about the Compositor-derived glow (as opposed to the Material network for the nacelles/bussards/engines/etc.), here it is:
If you're curious about any of the Material shaders, don't hesitate to ask!
I'm going to keep looking this over for ideas on texturing the hephaestus, except given her unique status as a "ghost ship" created by a renegade she had no escape pod's, asides from the upper command module being able to separate.
From what I can see, I definitely like your lighting and materials.
I agree. The lighting looks great. I haven't played around much with interior lighting, so mine usually doesn't look very good!
I wonder what it would look like if you gave the exterior textures the same gloss that the shuttlebay floor has, but a little less intense. I just really like the way it looks.
I wonder what it would look like if you gave the exterior textures the same gloss that the shuttlebay floor has, but a little less intense. I just really like the way it looks.
It's actually using the exact same node setup, the only difference being the sharpness of the reflection. It works in the shuttlebay because of the overhead lights giving something to reflect, but outside the ship it wouldn't be (isn't?) as notable.
And now the full-res!
Upper:
Lower:
To Do:
Conference room interior textures and materials
Special arboretum mapping and texture
Special forward lounge mapping and texture
General room texture and re-mapping (as needed)
Material/shader tweaking pass (esp. phasers, the glowy bits on the warp nacelles, and the generic "dark hull" texture)
You're really destroying my will to live by being so good I'm pathetic in comparison.
Seriously I must get back to my ship, I have some more details to ad then I may go to texturing, which I've vever done before, are you ding and trek based tutoirials on that in cycles?
Seriously I must get back to my ship, I have some more details to ad then I may go to texturing, which I've vever done before, are you ding and trek based tutoirials on that in cycles?
I certainly could, sure. UV unwrapping is generally an exercise in patience, but I could write up a tutorial explaining some of the general techniques I used here. Texturing is really just a question of making things in Photoshop that match your UVs. But there are a handful of things about how I made the hull textures that I could scribble down. Honestly, though, 90% of what I did is the exact same as what tobiasrichter does, as he explained here. The only difference, really, is that I didn't bake out an AO pass first (and I kind of wish I had, to be honest!).
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.
To Do:
Special arboretum mapping and texture
General room texture and re-mapping (as needed)
Material/shader tweaking pass (esp. phasers, the glowy bits on the warp nacelles, and the generic "dark hull" texture)
One thind I need to do soon is scale. I'm pegging the hephaestus at exactly 2,000' long. (Yes, I'm metrically impaired.) and as sucn I'm going to need to scale some things.
I'm not having many windows on her because one of the points of windows was to give a sense of scale, and windows weaken an armored hull to boot. The rebooted BSG had very few windows and looked great.
I think I will make an interior to the warp nacelles to show the coils. I need to see how to make an array of bars across the windows on the nacells too.
BTW, no have photoshop or gimp, can you do texturing in inkscape?
I'm not having many windows on her because one of the points of windows was to give a sense of scale, and windows weaken an armored hull to boot. The rebooted BSG had very few windows and looked great.
The rebooted (and original) BSG could get away with it because it had a heavily greebled surface to compensate for the lack of windows. Copious surface detail can also connote scale. Trek ships, Federation ships in particular, are notably devoid of heavily-greebled surfaces.
I think I will make an interior to the warp nacelles to show the coils.
It's not really necessary. I did it on a lark and ended up sinking more time into it than was remotely worth the effort.
I need to see how to make an array of bars across the windows on the nacells too.
The grille? On mine, it started as a flat surface that wrapped the nacelle, then got sliced along its length at regular intervals. Every other slice was then extruded out and given a glowing surface. The remainder was given a dull metal surface.
BTW, no have photoshop or gimp, can you do texturing in inkscape?
Probably? I don't know anything about Inkscape, I'm afraid. Really, you could texture in MS Paint, with enough patience. Photoshop has certain tools that make things easier, and I imagine GIMP does too. GIMP is also completely free, so there's no reason not to have it.
On my ship I plan to show the nacelles with the coils visibly flashing as she moves at warp. So the windows on the nacelles would glow blue when they were energized but not running, and when she went to warp you'd see the windows flash in sequence as the warp coild energized and discharged. The higher the speed the faster the sequencial flashing would be.
Aso the windows on the boost engine would not be flashing unless she was travelling at over warp 7 and needed the boost engine. That's why I might do an engine inteorri, at least showing the coils behind the windows.
BTW, legally I don't know if you could make a tutorial about this and sell it, but man if you changed it to a generic SF ship and redid it as a tutorial you could sell it on amazon and I'd buy it.
Posts
Thanks, evil_genius_180!
I have not been idle while the forums were down and indeed have done a great deal of experimenting and research in the interim.
Wall of Text Incoming!
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 (link is to a Maya article, but the same principles apply to Cycles). 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! :eek: 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. :argh:
End Wall of Text
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 passes (most noticeable around the warp grille, the impulse engines, and the lights on the sensor dome) 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:
Books: [ Ashes of Alour-Tan | Embers of Alour-Tan ] | Blender Tutorials | Blog
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 (it's not actually the same one as the rest of the engineering hull). On an unrelated and somewhat superfluous note, I should probably back the strength on the fill light off.
The remaining to-do list, in approximate order:
I think that's it, unless I've left out something obvious. I wonder if I can get all that done before the end of the year...
Books: [ Ashes of Alour-Tan | Embers of Alour-Tan ] | Blender Tutorials | Blog
That caught my attention. Can you direct me to a tutorial or elaborate a little on this.
Blender's node network has a Texture Coordinate node with a bunch of different outputs. Among those outputs are Generated and Normal. Generated represents a bounding box wrapped around the entire mesh and mapped accordingly. Normal refers to the normal vector of the face in question. Blender also has a Mapping node, which allows for manipulation of an incoming vector by translation, rotation, scale, and repetition limit (min, max). When applied to UV(W)s, the XYZ translate directly. 0.5m on X is equivalent to 0.5 U in UV space, for instance. However, the 0,0,0 coordinate in UVW space isn't always intuitive, especially when dealing with Generated or Normal coordinates. I suggest trying these nodes out on a Cube first, just to get a sense of them.
Since I have these decals that don't necessarily conform to the UV mapping of the rest of the texture, I want to use Generated coordinates to position them where they're supposed to go. In this case, the registry on the side of the pylons serves as a great example, but basically any text or iconography on the ship is applied the same way. So, if I take my Texture Coordinate node and plug the Generated output into a Mapping node and then the output of that into the Vector input of the Image Texture node, I can dictate its position on the object by manipulating the Mapping node's settings. Usually, I want to clamp it to Min 0 and Max 1 so I only have a single instance of the texture, rather than lots of repeating instances. Then it's a matter of tweaking the position, rotation, and scale values to position it all correctly.
However, if I do this for one "side" of the pylons, it projects through on all four faces (port outer, port inner, starboard outer, starboard inner). That's no good, especially when I want the very orientation of the decal to be reversed on the starboard side as compared to the port (i.e. the "NCC" is toward the forward edge of the pylon on the port side, but the aft edge of the pylon on the starboard side). I also only wanted it on the outward-facing side of the pylon, not the interior-facing side.
In order to accomplish this, I need to grab the Generated and Normal vector information from the Texture Coordinate node. Each of those outputs is actually a three-vector, containing XYZ or UVW. I can split out these vectors using a Separate RGB node and extract just one of them. In this case, I wanted the Generated vector that corresponded to one half of the mesh (+X or -X) or the Normal vector that corresponded to "facing outward." By running these through different Math nodes (Multiply by -1 to get the -X, Add with a 0 and "Clamp" turned on to get only the left or right side) and also Multiplying them together, I end up generating a "mask" that only projects the decal onto the very specific set of polygons that meet the criteria I want. I then multiply this mask by the Alpha channel of the PNG that contains the decal itself to get the "final" alpha channel that mixes with the main Image Texture of the hull map.
Here's what that node setup looks like for the pylons, labeled.
It's incredibly convoluted when first putting it together, but once you get a sense for what needs to go where, it actually becomes easier and faster. For the engineering hull, I actually made a group node that handles all of the work of deciding which computed mask to supply for the lateral banners on either side of the hull. I couldn't quite re-use that for the pylons, since I also needed to account for normals in this case as well as which half of the model I was on, but the principles are exactly the same.
If that's not clear enough, I can try to go into more detail or write-up a more thorough tutorial. Let me know!
Books: [ Ashes of Alour-Tan | Embers of Alour-Tan ] | Blender Tutorials | Blog
I...don't really have anything to say about these.
To Do:
Books: [ Ashes of Alour-Tan | Embers of Alour-Tan ] | Blender Tutorials | Blog
See attachement which ones I mean...
From that angle, it certainly seems like it, but have a look at the ortho from the rear:
Plenty of clearance.
All the escape pods are now textured and uniquely numbered. Their numbers are drawn from a big 18x22 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...
To Do:
Books: [ Ashes of Alour-Tan | Embers of Alour-Tan ] | Blender Tutorials | Blog
This isn't the only Trek ship to have this issue. Take a look at escape pod locations on the Nebula class, especially the saucer underside.
http://www.ex-astris-scientia.org/scans/christies/nebula-christies5.jpg
One question I have it on the escape pod designation: Would't they have an alpha numeric code to make them easy to identify and know the location of in an emeregency? Something that designiated the deck and section they were on to make it easier to find your pod in an emergency?
The Galaxy model also had non-sequential escape pods, and even repeated numbers!
So, my guess is that the actual pod number is completely arbitrary. If you eject one escape pod for some reason and then get a replacement at a starbase, it'll have a new number, not the same number. The internal designation for the pod surely refers to its location and deck, as you describe, but the external number on the pod probably has nothing to do with that internal number. It seems more like a registry number or something along those lines.
Books: [ Ashes of Alour-Tan | Embers of Alour-Tan ] | Blender Tutorials | Blog
Assuming you're just curious about the Compositor-derived glow (as opposed to the Material network for the nacelles/bussards/engines/etc.), here it is:
If you're curious about any of the Material shaders, don't hesitate to ask!
Books: [ Ashes of Alour-Tan | Embers of Alour-Tan ] | Blender Tutorials | Blog
Books: [ Ashes of Alour-Tan | Embers of Alour-Tan ] | Blender Tutorials | Blog
From what I can see, I definitely like your lighting and materials.
I agree. The lighting looks great. I haven't played around much with interior lighting, so mine usually doesn't look very good!
I wonder what it would look like if you gave the exterior textures the same gloss that the shuttlebay floor has, but a little less intense. I just really like the way it looks.
It's actually using the exact same node setup, the only difference being the sharpness of the reflection. It works in the shuttlebay because of the overhead lights giving something to reflect, but outside the ship it wouldn't be (isn't?) as notable.
And now the full-res!
Upper:
Lower:
To Do:
- Conference room interior textures and materials
- Special arboretum mapping and texture
- Special forward lounge mapping and texture
- General room texture and re-mapping (as needed)
- Material/shader tweaking pass (esp. phasers, the glowy bits on the warp nacelles, and the generic "dark hull" texture)
- Pearlescent hull material experimentation
Might I actually finish it this weekend?Books: [ Ashes of Alour-Tan | Embers of Alour-Tan ] | Blender Tutorials | Blog
Seriously I must get back to my ship, I have some more details to ad then I may go to texturing, which I've vever done before, are you ding and trek based tutoirials on that in cycles?
I certainly could, sure. UV unwrapping is generally an exercise in patience, but I could write up a tutorial explaining some of the general techniques I used here. Texturing is really just a question of making things in Photoshop that match your UVs.
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.
To Do:
Almost there!
Books: [ Ashes of Alour-Tan | Embers of Alour-Tan ] | Blender Tutorials | Blog
I'm not having many windows on her because one of the points of windows was to give a sense of scale, and windows weaken an armored hull to boot. The rebooted BSG had very few windows and looked great.
I think I will make an interior to the warp nacelles to show the coils. I need to see how to make an array of bars across the windows on the nacells too.
BTW, no have photoshop or gimp, can you do texturing in inkscape?
The rebooted (and original) BSG could get away with it because it had a heavily greebled surface to compensate for the lack of windows. Copious surface detail can also connote scale. Trek ships, Federation ships in particular, are notably devoid of heavily-greebled surfaces.
It's not really necessary.
The grille? On mine, it started as a flat surface that wrapped the nacelle, then got sliced along its length at regular intervals. Every other slice was then extruded out and given a glowing surface. The remainder was given a dull metal surface.
Probably? I don't know anything about Inkscape, I'm afraid. Really, you could texture in MS Paint, with enough patience.
In other news...
I'm calling it done!
I could continue to noodle with it forever, but I hit all of the remaining bullet points on my to-do list and I think it's time to move on.
Books: [ Ashes of Alour-Tan | Embers of Alour-Tan ] | Blender Tutorials | Blog
Excellent finishings.
Aso the windows on the boost engine would not be flashing unless she was travelling at over warp 7 and needed the boost engine. That's why I might do an engine inteorri, at least showing the coils behind the windows.
BTW, legally I don't know if you could make a tutorial about this and sell it, but man if you changed it to a generic SF ship and redid it as a tutorial you could sell it on amazon and I'd buy it.
I already bought this one: http://www.amazon.com/Build-Your-Own-Rocket-Bike-ebook/dp/B0093OVE5E/ref=sr_1_1?ie=UTF8&qid=1389173265&sr=8-1&keywords=blender+rocket+bike
If yours wasn't too high I'd buy it too.