Looking good. I'm not sure about the divides, though. I was thinking this model had smooth emitters, like the -D does.
Thinking about it in concept, each of those arrays is made up of individual emitters that pass their discharged energy onto the next emitter to create the final beam. I find it somewhat unlikely that Starfleet would build continuous strips for that, rather than socketing pre-fabricated emitters into receptacles in the hull. This is one place where I'm diverging with visual canon for the sake of conceptual verisimilitude.
I know what's causing it too. You used the booleans in Blender. :shiner:
I don't think I've ever encountered a 3D package that did Booleans well.
But, no, it's really the order of operations I took with these, re-stitching the narrower grids in after the fact. The surface normals differ as a result, which throws everything off. Easy and quick to fix (select all window frames, scale in by 0.001%, done) now that I know it's happening everywhere along that band, and easy to avoid in the future since (one hopes) I won't need to re-do the shield grids on every other surface of the ship!
I don't think I've ever encountered a 3D package that did Booleans well.
If you know how to do it, TrueSpace is just fine with booleans. Of course, there's the inevitable cleanup, (on certain things) but I think that's universal. Though, in 40+ years of CGI's existence, (not all of it solid modeled CGI) you'd think they'd have found a better way to cut stuff out of 3D meshes. Though, not all 3D packages like to connect the booleans cut to the edges of the face it's in with vertex lines, which is Blender's specific problem with booleans. All of those lines cause a mess, which causes smoothing errors. Though, I thought they added ngons to Blender a while back.
Been quite busy of late, but finally had a little time to poke at this. Haven't done much besides fix up the windows on the saucer rim, but since I haven't done a full-ship render in a while, this seemed a good opportunity!
Thanks, evil_genius_180! One of my goals with this model is to finish it. I have a rather terrible history of starting 3D projects and never finishing them; I'm not allowing myself to start anything new until this one is done!
Spent about six hours last night putting in the ventral grids (all of which are nice and tidy; helps to know the pitfalls you're going to encounter and how to mitigate them in advance!), windows, and rooms.
There's something funky going on with either the room self-illumination or the window frames that's causing the J and N deck rooms to be darker than they should be. There's also some funky shadowing going on with the windows on the right side of the image, but I think that may just be because I mirrored and inverted my lighting rig to bolster the light for this render. Mirrored lights often do weird things.
The grid doesn't go all the way to the edge? I was thinking it did. Either way, it looks good.
Yes and no. The radial grids do extend all the way to the edge, but they abruptly terminate when the ventral saucer starts sloping up to the edge. Rather than have the abrupt termination, I decided to just start them at the first ring.
Welcome back!
The windows near of the sensor dome, looks bigger (almost twice) than the others. I think they needs to be resized.;)
Other than that, itAâs coming along very nice.
The windows near of the sensor dome, looks bigger (almost twice) than the others. I think they needs to be resized.;)
They look bigger, but they actually aren't! They're the same 1m tall (relative to the deck height) windows as the other windows on the ventral side of the saucer. They look much larger because of the shallower slope of the hull in that area. If you looked at the windows head-on, though, they all have identical profiles.
Last night's progress was a lot of trial and error with Blender's various deformation tools in order to get the shield grids near the neck collar to flow around it, rather than end abruptly. Finally came up with a solution I was happy with using Mesh Deform (essentially using another mesh as a Lattice deformer). I also fiddled with the UVs on the rooms so that the K deck room ceilings (which are what you see through the windows at this angle) aren't so much brighter than the J and N deck room ceilings. There's still a big difference, but it's not quite as bad now. Finally, added the ventral saucer phaser arrays.
Ventral saucer lifeboats now in place. Started working on the "real" version of the sensor assembly, based heavily on the Lakota-style sensor assembly.
Ended up being a very frustrating evening, actually. The initial shapes came together fine, and I decided rather than subsurfing the whole "star" pattern of the sensor assembly, I would do just enough to get the shape geometry and then bevel the edges several times to round it off. This created some less-than-attractive corners, which I deleted and thought, "Okay, I'll just patch this with some curves and be good to go." Come to realize I don't know how to do this in Blender. I'm reasonably sure the functionality exists, but after several hours watching tutorials (Side note: why does everyone post video tutorials these days? Am I the only one who prefers the text-and-picture format?) and banging my head against bSurfaces, various Python scripts, and so on, I ultimately decided to brute-force it and extruded the "base" of each hole, then rescaled each loop based on the cursor anchored to one of the vertices along the edge. And all of this for little detail bits that are barely 15cm across! :rolleyes:
Now we're cooking with gas! The following represent another 10ish hours of work, but I believe also represent the conclusion of detail work on the saucer (except for the secondary shuttlebay doors, which I think I need to plan out before trying to tackle).
First up, a completely new and improved sensor dome, based on that of Lakota. I like the front-back orientation better than the sideways orientation as seen on the refit Ambassador, so that's why it's rotated the way it is. I imagine all of these components are modular and can be swapped-out on a per-mission basis, anyway.
(Just noticed the little render errors in the shield grid here. Probably trivial to fix.)
Second, another full-ship render, this time showcasing the saucer rim RCS thrusters. As with the sensor dome, these are based on Lakota's RCS thrusters rather than those of the Ambassador studio models because the ones on the studio models are little more than colored lines. The Lakota RCS thrusters share lineage with those of the Constitution Refit and look much more like actual RCS thrusters that would emit gas to push a ship around!
Yep, definitely improved by rotating it like that!
Re: the thruster quads, I'd recommend maybe colouring the sides of the saucer rim between top/bottom orange (and possibly even putting some small vertical ports in there), tying it in a bit with the subsequent Galaxy-class design. If I'm not mistaken Probert did the same thing with his finished "concept" design for the 1701-C.
Re: the thruster quads, I'd recommend maybe colouring the sides of the saucer rim between top/bottom orange (and possibly even putting some small vertical ports in there), tying it in a bit with the subsequent Galaxy-class design. If I'm not mistaken Probert did the same thing with his finished "concept" design for the 1701-C.
A single image seemed an easier way to respond than writing everything out.
None of today's work is really render-worthy. I spent a ton of time re-integrating the neck and engineering hull into one piece. Also made a ton of other really small but significant shape tweaks to the engineering hull. Rather than spend two hours rendering out something that won't really look that much different without a side-by-side comparison, I did another annotated screenshot:
That's a damn fine model and I like how your adding detail that wasn't that noticeable much on screen. I also like how your essentially bridging the gap between the Ent-B and D particularly with the RCS thrusters to keep some continuity.
evil_genius_180 (you changed your avatar!), not that I know of. I've been tracking my time on the project using ManicTime. That number doesn't just include actual time in Blender, but also looking at reference images, reading Blender docs, and so on. I have a spreadsheet I'm using to track time for the model, using the time I tag in ManicTime as "Model: Ambassador," so the track is accurate to the second. If you're curious about actual in-Blender time, I can track that number, too (in fact, I probably should do that anyway, just to get a sense of how much time is labor vs. research vs. education). Just let me know!
No updates to post from last night; I froze the subsurfaces for the stardrive and have been cleaning up the geometry. It's going pretty well, all things considered. The shuttlebay "notch" is nice and clean now, as is the housing for the deflector. Just need to finish cleaning up the neck and I can start in on the detailing. I'm probably going to leave the bulk of the stardrive un-optimized.
Two renders, mostly for inspection purposes to make sure there aren't any egregious smoothing errors post-cleanup. Neck area seems to be free of issues.
I might try to massage the polys around the curve where the neck joins the hull, or I might not. I'm not hugely fond of how it's bending toward the centerline, but I do like having a little bit of a ridge as it smooths into the hull.
There are a couple of minor issues on the main body: near the bottom, toward the midline, there's a row of unwelded verts...not even sure how that happened, since I neither separated nor optimized that part of the hull. Easy enough to fix. Also there's what might be a smoothing error about halfway along the arch of the shuttlebay notch. Hard to tell.
Also, totally forgot to turn on the layers with the sensor dome and the room interiors... :thumb:
Thanks, evil_genius_180! In case you're curious, I went through and computed Blender-only time spent on the model, and it works out to about 87%, the other 13% comprising looking at reference, poking around for technique/technical information, and so on.
Had a somewhat busy night last night, so I didn't have as much time to spend modeling as I'd've liked. Did a little more optimization/cleanup and cut in the shuttlebay. The shape of the bay is more like the Ent-C variant than the Yamaguchi variant (which just has an abrupt flat termination with a hemispherical clamshell door rather than the much more common straight-clamshell with flight control deck overlooking it) because, frankly, the Yamaguchi bay just looks rushed to me.
For those curious, the shuttlebay is two decks tall and the hull is about a meter thick at its thinnest point (at the base and apex of the inner arch).
Anyone have any wisdom to share about how Ent-A-style clamshell doors actually open? A video would be awesome...:D
I agree with you, the Yamaguchi bay doors look rushed. I like the Ent-C doors better. It looks like you're doing what a lot of CG modelers do with this ship, mixing parts from both variants to create what looks best to you.
Thanks, evil_genius_180! In case you're curious, I went through and computed Blender-only time spent on the model, and it works out to about 87%, the other 13% comprising looking at reference, poking around for technique/technical information, and so on.
Crap, that sounds like a lot of work (the calculating part.) Of course, that could be because I'm way to lazy to even bother keeping track of my time, let alone doing all of that. :shiner:
Anyone have any wisdom to share about how Ent-A-style clamshell doors actually open? A video would be awesome...:D
Magic? Sorry, I couldn't resist. Your best bet is Star Trek V for video. I know, a lot of people don't like that film, but that's the only time they showed them opening on screen.
I agree with you, the Yamaguchi bay doors look rushed. I like the Ent-C doors better. It looks like you're doing what a lot of CG modelers do with this ship, mixing parts from both variants to create what looks best to you.
For this model, I'm using a bunch of different schematics and reference shots of the studio models (both Enterprise-C and Yamaguchi variants). My inspiration is dwl'sIntrepid-class variant, U.S.S. Horizon, and I plan to take a similar approach to retaining what I like about the design and changing what I don't.
Crap, that sounds like a lot of work (the calculating part.) Of course, that could be because I'm way to lazy to even bother keeping track of my time, let alone doing all of that. :shiner:
It took a little time, but wasn't really a lot of work. ManicTime did all the recording, Excel did the math parts; I just did the data entry.
Magic? Sorry, I couldn't resist. Your best bet is Star Trek V for video. I know, a lot of people don't like that film, but that's the only time they showed them opening on screen.
I did indeed pull out ST5 (see "References" below) to have a look, on your recommendation!
Warning! The post is long-winded and somewhat technical. There’s some actual update stuff at the bottom if you don’t want to read it all.
I came down to my desk this morning to find my computer on, but all peripherals disabled and unresponsive. Rebooting righted everything, and revealed that at some point (well, 3 AM), Windows had installed updates. Knowing that my renders were taking up to two hours, and having kicked it off close to 1 AM, I went to check...and sure enough, no render from last night.
That got me to thinking that there must be ways I can improve my render times through settings tweaks. Cycles shines best on nVidia cards (with up to x15 speed improvements over CPU rendering!), so I don't get the full effect with my AMD card, but surely even with the CPU I must be able to improve some speed without sacrificing quality!
Tiles
I did some Googling and came across an interesting tip. Blender has the option to render images in Tiles, subdividing the total pixels size into smaller buckets. My assumption had been that, since my CPU supports eight threads, that I should size my Tiles such that I ended up with eight. For 1280x720 renders, that worked out to 320x360 (4 horizontal tiles, two vertical).
However, it seems this was an erroneous assumption to make! As it turns out, smaller tiles can render substantially faster than large tiles. I decided to do some benchmarking of my own to prove this out. I turned down my Cycles sampling settings so that the render would go much faster, but look ultra-grainy. I wasn't aiming for clean-looking renders here, just speed benchmarks and the per-tile sampling is the sort of thing that will scale linearly for a given tile size (more on that below!).
Come to find out, my large tiles were actively hurting my render times. I started out trying only square tiles in powers of two, ranging from 8 pixels to 512 pixels. The 512 render took nearly four minutes, while the 32 render took under two! In truth, everything from 64 on down landed in the same ballpark, with 32 coming up as the sweet spot: (using 1280x720 = 921600 pixels) 8121 pixels per second
Next, I decided to try square tiles that didn't have 2^n dimensions. I focused my tests in the range between 16 and 64, since this seemed to have the best results. Ultimately, 32 remained the champion, but the difference in render times for the 64-and-below group is easily within margin of error. All of them were > 8050 pixels/sec (except 8, which was 7915 pixels/sec; might be so many tiles at this size that one starts seeing overhead from that), but none was faster than 32 pixel tiles.
My next experiment was to try non-square tiles. For this test, I took a cue from my original assumption and started with 320x360 and then continued to divide that in half, first horizontally, then vertically, and then both in lockstep. None of these performed quite as well as the square pixel tests, with 40x45 coming the closest. 32 again remained the champion.
Conclusion: Use 32x32 tiles when rendering for maximum performance.
Sampling
The next step was to check out what different sampling settings did, both to the render quality and to the render time. Thus far, most of the renders I’ve posted have used pure progressive sampling with 2000 and more recently 4000 samples. This provides a more physically accurate result, but requires more samples to reduce noise. Cycles has a non-progressive mode that allows tweaking of sampling on a per-type basis, and I used that mode in my tile benchmarks above. Each individual sample is slower to compute than in progressive, but (allegedly) requires fewer samples overall to reduce noise to an acceptable level.
The chief parameter is the number of antialias samples. This is a sort of multiplier on all of the other sample types. As I understand it, AA samples * Diffuse samples = Progressive samples, so presumably to get the same render fidelity as my 4000 sample progressive renders, I’d need some arrangement of AA samples and Diffuse samples that multiplied together to equal 4000.
I started out with a baseline of 1 sample for everything, which resulted in a render time of about 21 seconds. At least half (if not more) of that is scene prep overhead that’s constant for every frame rendered. I then increased the number of AA samples by powers of two up to 64, leaving the other sample rates the same. The interesting calculation comes from taking the time difference between any render and the baseline render, then and dividing it by the same time difference from the previous render. If the samples follow a linear scale, this should always come out as the same as the difference in scale between the two renders’ sampling rate (i.e. if one render is 8 samples and one is 16, we’d expect to see the time increase to be two).
And...it is! Mostly. There’s a fair amount of “noise” in the data with low sample rates because of that aforementioned overhead for each frame, but as the actual render time becomes a larger and larger portion of the per-frame time, so too does the number converge closer and closer to two.
The next question is whether or not the Diffuse bounces play by the same rules. For this test, I started with 8 AA samples, 2 Diffuse samples (since I already had data for 1 Diffuse sample) and increased Diffuse samples by powers of two up until I hit a point of 1024 equivalent progressive samples (e.g. 8x128, 16x64, etc.), and then repeated for the next power of two on AA samples.
I also decided to keep the renders for each batch, to see what effect changing the Diffuse sample count had on the overall image fidelity. The Diffuse sample count did have some impact on image fidelity, but far less than the AA sample count. 8x2 looked like it was somewhere between 8x1 and 16x1 in noise amount, rather than equivalent to 16x1. However, the level of contrast in each pixel was a lot lower in the 8x2 than in the 16x1.
As above, the time differences all converged toward two, the same multiple I used between my sample amounts. So far, so good: sampling amount is a linear quantity; increasing it by a factor of two results in a factor of two increase in render time (ignoring constant overhead). I also decided to save the last image of each batch (the one with effectively 1024 progressive samples) to compare them. Another unsurprising outcome here: more AA samples had a much bigger impact on visual quality than did more Diffuse samples, but the equivalent number of samples took less time with fewer AA samples (i.e. 8x128 took less time to render than 16x64, but it didn’t look as good).
I also tried 8-64 AA passes with 4 diffuse passes and 1-128 passes on the other sample settings. I’m using predominantly diffuse materials, with only a handful of glossy, transmissive, or emissive materials, so I expected these changes to have minimal impact.
Changing Glossy had a very small impact. Per frame differences were power of two but test interval was multiple of four, so it’s definitely not a linear contribution the way Diffuse is. This will probably not be the case for images with a higher glossy component, where it’s more likely to coincide with the way Diffuse scales. For subsequent tests, will set this to the same value as Diffuse (4). Biggest disparity: 16x4x1 = 319.22 seconds, 16x4x64 = 364.5 seconds.
Changing Transmission had inconsistent results. Increasing it definitely had an impact, but it was generally less than linear. It might approach linear the higher it goes, but I’d need to increase the number of samples in my test battery to confirm that. Of note here is that increasing transmission bounces dramatically increases the quality of translucent surfaces like the impulse vents and it only takes a small increase to do it. Will likely keep this number fairly low as a result (with the Transmission*AA number probably 1/4 to 1/2 the Diffuse*AA number).
Changing AO did absolutely nothing! This is not surprising, since I don’t have AO turned on.
Changing Mesh Light has a definite linear impact on performance, just like Diffuse. I’m not entirely sure what it does (the docs very unhelpfully say “the number of mesh light samples to take for each AA sample.” I saved a 64 Mesh Light sample render and and compared it with the 1 Mesh Light sample render...and there was absolutely no visual difference! As in, pixel-for-pixel identical. Clearly, this setting gets to stay at 1!
Conclusions: For a given render, the primary parameters governing image quality and render time are AA Sample count and Diffuse sample count. These numbers multiplied together result in the equivalent number of progressive samples. I was using between 2000 and 4000 progressive samples, with 2000 being almost enough and 4000 probably being overkill, which suggests that settings along the lines of 500 AA samples and 4 Diffuse samples would provide adequate image fidelity.Glossy and Transmission settings do not have a linear impact on render time with the current material setup. It is probably adequate to set Glossy and Diffuse to the same value, and to set Transmission such that Transmission*AA is between 1/4 and 1/2 Diffuse*AA. Mesh Light should remain at 1, as should AO; the former has a linear impact on performance for no visual gain and the latter has no impact whatsoever, since my renders are not using AO.
Bounces
At some point, I also want to investigate the effect of number of light bounces and their impact on performance and render quality. Cycles comes with a few default presets for light bounces, and a common tip is to enable Filter Glossy, which gives glossy surfaces a slight blur to reduce noise, and disable caustics, which are notorious for creating noisy images when present, so all of my rendering thus far has used these two parameters. Cycles also lets you control the minimum and maximum number of light bounces on a global level, and then specifically the maximum bounces for diffuse, glossy, and transmission rays, as well as independent min/max for transparency. So, that merits its own battery of testing at some point.
References
In addition to all of that, I also did a little research by pulling out Star Trek V and looking at the “Emergency Landing Plan B” sequence to see how the Ent-A bay doors are intended to open. Based on the larger bay miniature they made for the sequence, each of the doors slides over the next outermost layer, starting from the center line. This means that they aren’t a smooth, continuous surface with individual grooves for the plates (as implied by the closed doors on the full-ship models). I think I will experiment with making doors with this in mind and see how they look. If it ends up looking too goofy, there’s always either the JJprise method, or positing some sort of tracked mechanism that allows the individual door plates to slide forward and back along a given track.
Modeling
Finally, the extent of actual modeling work I did last night was to add two support struts attaching the collar and the inset at the back of the neck. My render experiments above aside, it’s not really render-worthy, so here’s an OpenGL screenshot and a wire overlay screenshot.
Flanking neck inset created and additional vanes (impulse reactor radiators, perhaps?) added to the aft-facing inset to the neck.
Unfortunately, I am thinking about retooling the neck/stardrive again. I can almost certainly do a better job of making the neck/spine join flow together and I think, evil_genius_180, that you make a good point. My polygon density overall is just too high right now. I've yet to develop a good sense for the correct level of geometry to give to something; I always err high because I want the model to stand up to just about any conceivable render distance.
Side note, this render took just under three hours. I pulled my AA samples down to 1600, but cranked up my Diffuse samples to 6 (equivalent to 9600 Progressive samples, compared to 4000 from previous renders). I also screwed around with the Bounce settings and am not sure exactly what impact that had on the render time. Still, 9600 samples at 2:50 is about 56 samples/minute, compared to 4000 samples at ~2:00 for 33 samples/minute. Definite improvement!
3 hours for that? Sheesh. What kind of hardware are you rendering on?
An i7-930. It ain't a hardware issue, though. Well, not a CPU issue, anyway. Cycles is intended to run on the GPU, but currently AMD drivers don't have the right kind of OpenCL support to perform the CUDA calculations nVidia cards do. I have an AMD card. On the GPU, Cycles renders are 15+ times faster (so, this render would've taken a mere 11 minutes!). On CPUs (which is where Cycles "falls back" to when AMD cards are in play), Cycles is substantially slower than other render engines. I've played around with using Blender Internal to render instead of Cycles, but at this point I just know more about lighting and rendering in Cycles.
Fortunately, it dawned on me last night (wish I'd thought about this sooner...) that my wife's GPU is an nVidia board. Since our cards are comparable for gaming purposes, which is largely what she uses her machine for, she's agreed to swap cards with me until it becomes financially reasonable for me to replace my AMD card with a relatively new nVidia card. Hopefully, future renders will not take three hours.
Posts
I don't think I've ever encountered a 3D package that did Booleans well.
But, no, it's really the order of operations I took with these, re-stitching the narrower grids in after the fact. The surface normals differ as a result, which throws everything off. Easy and quick to fix (select all window frames, scale in by 0.001%, done) now that I know it's happening everywhere along that band, and easy to avoid in the future since (one hopes) I won't need to re-do the shield grids on every other surface of the ship!
Books: [ Ashes of Alour-Tan | Embers of Alour-Tan ] | Blender Tutorials | Blog
If you know how to do it, TrueSpace is just fine with booleans. Of course, there's the inevitable cleanup, (on certain things) but I think that's universal. Though, in 40+ years of CGI's existence, (not all of it solid modeled CGI) you'd think they'd have found a better way to cut stuff out of 3D meshes. Though, not all 3D packages like to connect the booleans cut to the edges of the face it's in with vertex lines, which is Blender's specific problem with booleans. All of those lines cause a mess, which causes smoothing errors. Though, I thought they added ngons to Blender a while back.
Books: [ Ashes of Alour-Tan | Embers of Alour-Tan ] | Blender Tutorials | Blog
Spent about six hours last night putting in the ventral grids (all of which are nice and tidy; helps to know the pitfalls you're going to encounter and how to mitigate them in advance!), windows, and rooms.
There's something funky going on with either the room self-illumination or the window frames that's causing the J and N deck rooms to be darker than they should be. There's also some funky shadowing going on with the windows on the right side of the image, but I think that may just be because I mirrored and inverted my lighting rig to bolster the light for this render. Mirrored lights often do weird things.
Books: [ Ashes of Alour-Tan | Embers of Alour-Tan ] | Blender Tutorials | Blog
Books: [ Ashes of Alour-Tan | Embers of Alour-Tan ] | Blender Tutorials | Blog
The windows near of the sensor dome, looks bigger (almost twice) than the others. I think they needs to be resized.;)
Other than that, itAâs coming along very nice.
Last night's progress was a lot of trial and error with Blender's various deformation tools in order to get the shield grids near the neck collar to flow around it, rather than end abruptly. Finally came up with a solution I was happy with using Mesh Deform (essentially using another mesh as a Lattice deformer). I also fiddled with the UVs on the rooms so that the K deck room ceilings (which are what you see through the windows at this angle) aren't so much brighter than the J and N deck room ceilings. There's still a big difference, but it's not quite as bad now. Finally, added the ventral saucer phaser arrays.
Books: [ Ashes of Alour-Tan | Embers of Alour-Tan ] | Blender Tutorials | Blog
Ended up being a very frustrating evening, actually. The initial shapes came together fine, and I decided rather than subsurfing the whole "star" pattern of the sensor assembly, I would do just enough to get the shape geometry and then bevel the edges several times to round it off. This created some less-than-attractive corners, which I deleted and thought, "Okay, I'll just patch this with some curves and be good to go." Come to realize I don't know how to do this in Blender. I'm reasonably sure the functionality exists, but after several hours watching tutorials (Side note: why does everyone post video tutorials these days? Am I the only one who prefers the text-and-picture format?) and banging my head against bSurfaces, various Python scripts, and so on, I ultimately decided to brute-force it and extruded the "base" of each hole, then rescaled each loop based on the cursor anchored to one of the vertices along the edge. And all of this for little detail bits that are barely 15cm across! :rolleyes:
Books: [ Ashes of Alour-Tan | Embers of Alour-Tan ] | Blender Tutorials | Blog
First up, a completely new and improved sensor dome, based on that of Lakota. I like the front-back orientation better than the sideways orientation as seen on the refit Ambassador, so that's why it's rotated the way it is. I imagine all of these components are modular and can be swapped-out on a per-mission basis, anyway.
(Just noticed the little render errors in the shield grid here. Probably trivial to fix.)
Second, another full-ship render, this time showcasing the saucer rim RCS thrusters. As with the sensor dome, these are based on Lakota's RCS thrusters rather than those of the Ambassador studio models because the ones on the studio models are little more than colored lines. The Lakota RCS thrusters share lineage with those of the Constitution Refit and look much more like actual RCS thrusters that would emit gas to push a ship around!
Also visible: running lights!
Books: [ Ashes of Alour-Tan | Embers of Alour-Tan ] | Blender Tutorials | Blog
Re: the thruster quads, I'd recommend maybe colouring the sides of the saucer rim between top/bottom orange (and possibly even putting some small vertical ports in there), tying it in a bit with the subsequent Galaxy-class design. If I'm not mistaken Probert did the same thing with his finished "concept" design for the 1701-C.
A single image seemed an easier way to respond than writing everything out.
None of today's work is really render-worthy. I spent a ton of time re-integrating the neck and engineering hull into one piece. Also made a ton of other really small but significant shape tweaks to the engineering hull. Rather than spend two hours rendering out something that won't really look that much different without a side-by-side comparison, I did another annotated screenshot:
Over 170 hours working on this model so far.
Books: [ Ashes of Alour-Tan | Embers of Alour-Tan ] | Blender Tutorials | Blog
Does Blender have a log with stats like that or are you keeping track yourself?
evil_genius_180 (you changed your avatar!), not that I know of. I've been tracking my time on the project using ManicTime. That number doesn't just include actual time in Blender, but also looking at reference images, reading Blender docs, and so on. I have a spreadsheet I'm using to track time for the model, using the time I tag in ManicTime as "Model: Ambassador," so the track is accurate to the second. If you're curious about actual in-Blender time, I can track that number, too (in fact, I probably should do that anyway, just to get a sense of how much time is labor vs. research vs. education). Just let me know!
No updates to post from last night; I froze the subsurfaces for the stardrive and have been cleaning up the geometry. It's going pretty well, all things considered. The shuttlebay "notch" is nice and clean now, as is the housing for the deflector. Just need to finish cleaning up the neck and I can start in on the detailing. I'm probably going to leave the bulk of the stardrive un-optimized.
Books: [ Ashes of Alour-Tan | Embers of Alour-Tan ] | Blender Tutorials | Blog
Two renders, mostly for inspection purposes to make sure there aren't any egregious smoothing errors post-cleanup. Neck area seems to be free of issues.
I might try to massage the polys around the curve where the neck joins the hull, or I might not. I'm not hugely fond of how it's bending toward the centerline, but I do like having a little bit of a ridge as it smooths into the hull.
There are a couple of minor issues on the main body: near the bottom, toward the midline, there's a row of unwelded verts...not even sure how that happened, since I neither separated nor optimized that part of the hull. Easy enough to fix. Also there's what might be a smoothing error about halfway along the arch of the shuttlebay notch. Hard to tell.
Also, totally forgot to turn on the layers with the sensor dome and the room interiors... :thumb:
Books: [ Ashes of Alour-Tan | Embers of Alour-Tan ] | Blender Tutorials | Blog
Had a somewhat busy night last night, so I didn't have as much time to spend modeling as I'd've liked. Did a little more optimization/cleanup and cut in the shuttlebay. The shape of the bay is more like the Ent-C variant than the Yamaguchi variant (which just has an abrupt flat termination with a hemispherical clamshell door rather than the much more common straight-clamshell with flight control deck overlooking it) because, frankly, the Yamaguchi bay just looks rushed to me.
For those curious, the shuttlebay is two decks tall and the hull is about a meter thick at its thinnest point (at the base and apex of the inner arch).
Anyone have any wisdom to share about how Ent-A-style clamshell doors actually open? A video would be awesome...:D
Books: [ Ashes of Alour-Tan | Embers of Alour-Tan ] | Blender Tutorials | Blog
Crap, that sounds like a lot of work (the calculating part.)
Magic?
Yep! Way back in good ol' post #1: It took a little time, but wasn't really a lot of work. ManicTime did all the recording, Excel did the math parts; I just did the data entry.
I did indeed pull out ST5 (see "References" below) to have a look, on your recommendation!
Warning! The post is long-winded and somewhat technical. There’s some actual update stuff at the bottom if you don’t want to read it all.
I came down to my desk this morning to find my computer on, but all peripherals disabled and unresponsive. Rebooting righted everything, and revealed that at some point (well, 3 AM), Windows had installed updates. Knowing that my renders were taking up to two hours, and having kicked it off close to 1 AM, I went to check...and sure enough, no render from last night.
That got me to thinking that there must be ways I can improve my render times through settings tweaks. Cycles shines best on nVidia cards (with up to x15 speed improvements over CPU rendering!), so I don't get the full effect with my AMD card, but surely even with the CPU I must be able to improve some speed without sacrificing quality!
Tiles
I did some Googling and came across an interesting tip. Blender has the option to render images in Tiles, subdividing the total pixels size into smaller buckets. My assumption had been that, since my CPU supports eight threads, that I should size my Tiles such that I ended up with eight. For 1280x720 renders, that worked out to 320x360 (4 horizontal tiles, two vertical).
However, it seems this was an erroneous assumption to make! As it turns out, smaller tiles can render substantially faster than large tiles. I decided to do some benchmarking of my own to prove this out. I turned down my Cycles sampling settings so that the render would go much faster, but look ultra-grainy. I wasn't aiming for clean-looking renders here, just speed benchmarks and the per-tile sampling is the sort of thing that will scale linearly for a given tile size (more on that below!).
Come to find out, my large tiles were actively hurting my render times. I started out trying only square tiles in powers of two, ranging from 8 pixels to 512 pixels. The 512 render took nearly four minutes, while the 32 render took under two! In truth, everything from 64 on down landed in the same ballpark, with 32 coming up as the sweet spot: (using 1280x720 = 921600 pixels) 8121 pixels per second
Next, I decided to try square tiles that didn't have 2^n dimensions. I focused my tests in the range between 16 and 64, since this seemed to have the best results. Ultimately, 32 remained the champion, but the difference in render times for the 64-and-below group is easily within margin of error. All of them were > 8050 pixels/sec (except 8, which was 7915 pixels/sec; might be so many tiles at this size that one starts seeing overhead from that), but none was faster than 32 pixel tiles.
My next experiment was to try non-square tiles. For this test, I took a cue from my original assumption and started with 320x360 and then continued to divide that in half, first horizontally, then vertically, and then both in lockstep. None of these performed quite as well as the square pixel tests, with 40x45 coming the closest. 32 again remained the champion.
Conclusion: Use 32x32 tiles when rendering for maximum performance.
Sampling
The next step was to check out what different sampling settings did, both to the render quality and to the render time. Thus far, most of the renders I’ve posted have used pure progressive sampling with 2000 and more recently 4000 samples. This provides a more physically accurate result, but requires more samples to reduce noise. Cycles has a non-progressive mode that allows tweaking of sampling on a per-type basis, and I used that mode in my tile benchmarks above. Each individual sample is slower to compute than in progressive, but (allegedly) requires fewer samples overall to reduce noise to an acceptable level.
The chief parameter is the number of antialias samples. This is a sort of multiplier on all of the other sample types. As I understand it, AA samples * Diffuse samples = Progressive samples, so presumably to get the same render fidelity as my 4000 sample progressive renders, I’d need some arrangement of AA samples and Diffuse samples that multiplied together to equal 4000.
I started out with a baseline of 1 sample for everything, which resulted in a render time of about 21 seconds. At least half (if not more) of that is scene prep overhead that’s constant for every frame rendered. I then increased the number of AA samples by powers of two up to 64, leaving the other sample rates the same. The interesting calculation comes from taking the time difference between any render and the baseline render, then and dividing it by the same time difference from the previous render. If the samples follow a linear scale, this should always come out as the same as the difference in scale between the two renders’ sampling rate (i.e. if one render is 8 samples and one is 16, we’d expect to see the time increase to be two).
And...it is! Mostly. There’s a fair amount of “noise” in the data with low sample rates because of that aforementioned overhead for each frame, but as the actual render time becomes a larger and larger portion of the per-frame time, so too does the number converge closer and closer to two.
The next question is whether or not the Diffuse bounces play by the same rules. For this test, I started with 8 AA samples, 2 Diffuse samples (since I already had data for 1 Diffuse sample) and increased Diffuse samples by powers of two up until I hit a point of 1024 equivalent progressive samples (e.g. 8x128, 16x64, etc.), and then repeated for the next power of two on AA samples.
I also decided to keep the renders for each batch, to see what effect changing the Diffuse sample count had on the overall image fidelity. The Diffuse sample count did have some impact on image fidelity, but far less than the AA sample count. 8x2 looked like it was somewhere between 8x1 and 16x1 in noise amount, rather than equivalent to 16x1. However, the level of contrast in each pixel was a lot lower in the 8x2 than in the 16x1.
As above, the time differences all converged toward two, the same multiple I used between my sample amounts. So far, so good: sampling amount is a linear quantity; increasing it by a factor of two results in a factor of two increase in render time (ignoring constant overhead). I also decided to save the last image of each batch (the one with effectively 1024 progressive samples) to compare them. Another unsurprising outcome here: more AA samples had a much bigger impact on visual quality than did more Diffuse samples, but the equivalent number of samples took less time with fewer AA samples (i.e. 8x128 took less time to render than 16x64, but it didn’t look as good).
I also tried 8-64 AA passes with 4 diffuse passes and 1-128 passes on the other sample settings. I’m using predominantly diffuse materials, with only a handful of glossy, transmissive, or emissive materials, so I expected these changes to have minimal impact.
Changing Glossy had a very small impact. Per frame differences were power of two but test interval was multiple of four, so it’s definitely not a linear contribution the way Diffuse is. This will probably not be the case for images with a higher glossy component, where it’s more likely to coincide with the way Diffuse scales. For subsequent tests, will set this to the same value as Diffuse (4). Biggest disparity: 16x4x1 = 319.22 seconds, 16x4x64 = 364.5 seconds.
Changing Transmission had inconsistent results. Increasing it definitely had an impact, but it was generally less than linear. It might approach linear the higher it goes, but I’d need to increase the number of samples in my test battery to confirm that. Of note here is that increasing transmission bounces dramatically increases the quality of translucent surfaces like the impulse vents and it only takes a small increase to do it. Will likely keep this number fairly low as a result (with the Transmission*AA number probably 1/4 to 1/2 the Diffuse*AA number).
Changing AO did absolutely nothing! This is not surprising, since I don’t have AO turned on.
Changing Mesh Light has a definite linear impact on performance, just like Diffuse. I’m not entirely sure what it does (the docs very unhelpfully say “the number of mesh light samples to take for each AA sample.” I saved a 64 Mesh Light sample render and and compared it with the 1 Mesh Light sample render...and there was absolutely no visual difference! As in, pixel-for-pixel identical. Clearly, this setting gets to stay at 1!
Conclusions: For a given render, the primary parameters governing image quality and render time are AA Sample count and Diffuse sample count. These numbers multiplied together result in the equivalent number of progressive samples. I was using between 2000 and 4000 progressive samples, with 2000 being almost enough and 4000 probably being overkill, which suggests that settings along the lines of 500 AA samples and 4 Diffuse samples would provide adequate image fidelity.Glossy and Transmission settings do not have a linear impact on render time with the current material setup. It is probably adequate to set Glossy and Diffuse to the same value, and to set Transmission such that Transmission*AA is between 1/4 and 1/2 Diffuse*AA. Mesh Light should remain at 1, as should AO; the former has a linear impact on performance for no visual gain and the latter has no impact whatsoever, since my renders are not using AO.
Bounces
At some point, I also want to investigate the effect of number of light bounces and their impact on performance and render quality. Cycles comes with a few default presets for light bounces, and a common tip is to enable Filter Glossy, which gives glossy surfaces a slight blur to reduce noise, and disable caustics, which are notorious for creating noisy images when present, so all of my rendering thus far has used these two parameters. Cycles also lets you control the minimum and maximum number of light bounces on a global level, and then specifically the maximum bounces for diffuse, glossy, and transmission rays, as well as independent min/max for transparency. So, that merits its own battery of testing at some point.
References
In addition to all of that, I also did a little research by pulling out Star Trek V and looking at the “Emergency Landing Plan B” sequence to see how the Ent-A bay doors are intended to open. Based on the larger bay miniature they made for the sequence, each of the doors slides over the next outermost layer, starting from the center line. This means that they aren’t a smooth, continuous surface with individual grooves for the plates (as implied by the closed doors on the full-ship models). I think I will experiment with making doors with this in mind and see how they look. If it ends up looking too goofy, there’s always either the JJprise method, or positing some sort of tracked mechanism that allows the individual door plates to slide forward and back along a given track.
If you're interested, here's an animated GIF of the sequence from ST5. It's a bout 700 K.
Modeling
Finally, the extent of actual modeling work I did last night was to add two support struts attaching the collar and the inset at the back of the neck. My render experiments above aside, it’s not really render-worthy, so here’s an OpenGL screenshot and a wire overlay screenshot.
Books: [ Ashes of Alour-Tan | Embers of Alour-Tan ] | Blender Tutorials | Blog
Like I'm going to remember back that far.
Flanking neck inset created and additional vanes (impulse reactor radiators, perhaps?) added to the aft-facing inset to the neck.
Unfortunately, I am thinking about retooling the neck/stardrive again. I can almost certainly do a better job of making the neck/spine join flow together and I think, evil_genius_180, that you make a good point. My polygon density overall is just too high right now. I've yet to develop a good sense for the correct level of geometry to give to something; I always err high because I want the model to stand up to just about any conceivable render distance.
Side note, this render took just under three hours. I pulled my AA samples down to 1600, but cranked up my Diffuse samples to 6 (equivalent to 9600 Progressive samples, compared to 4000 from previous renders). I also screwed around with the Bounce settings and am not sure exactly what impact that had on the render time. Still, 9600 samples at 2:50 is about 56 samples/minute, compared to 4000 samples at ~2:00 for 33 samples/minute. Definite improvement!
Books: [ Ashes of Alour-Tan | Embers of Alour-Tan ] | Blender Tutorials | Blog
3 hours for that? Sheesh. What kind of hardware are you rendering on?
Fortunately, it dawned on me last night (wish I'd thought about this sooner...) that my wife's GPU is an nVidia board. Since our cards are comparable for gaming purposes, which is largely what she uses her machine for, she's agreed to swap cards with me until it becomes financially reasonable for me to replace my AMD card with a relatively new nVidia card. Hopefully, future renders will not take three hours.
Books: [ Ashes of Alour-Tan | Embers of Alour-Tan ] | Blender Tutorials | Blog
That last render I posted, which took 2 hours 50 minutes on my CPU took...
less than six minutes!!!
Only thing I changed was tile size (larger = better on GPU, smaller = better on CPU). Every other setting is exactly the same.
Books: [ Ashes of Alour-Tan | Embers of Alour-Tan ] | Blender Tutorials | Blog