Wednesday, 10 December 2025

Shamrayev Project: Test Trusses

 After yesterday's progress, I turned the block elements of the structural trusses into actual, detailed trusses. They are detailed, and we're not about details yet, but I really needed to see what delicate structures would look like. They took a couple of hours to lash together; they're not accurate, but are close enough at first look.



Do the rings need to be rebuilt so that the framework gauge matches the straight trusses? Probably. It always looks a lot better when truss frames have a consistent size, but I will investigate. It could be that so long as all the rings match, that's enough.


I'm reasonably happy with the results, but now I see how the masts are screaming to have a working mechanism, so that they can fold in. It will be last year's rigging torture all over again? Hopefully not!

Tuesday, 9 December 2025

Shamrayev Project: Block-out one

 I didn't want to jump into modelling until the ship's overall design was finalised. However, my shonky drafting skills make it harder to make precise ship layouts, so we'll use Blender to quickly iterate form changes...importantly, none of this is going to be a final model. It's just another kind of sketch.

I might print out some layouts, then sketch over them for when I want to produce some more detailed illustrations without modelling fine details.

First Block-out

The core. A first bash at the proportions 200-ish metres long, 10m diameter (narrowest)

After some playing around. Two beams at the back for extra support

I wanted the engineering section to have more mass, so I duplicated the main cylinder and gave it a taper. It has just enough of the Soviet rocket vibe to give me good feelings, and it may be here to stay.

Tidy up the forward beams. Running the front beams further along the hull.

Ball tanks FTW. They've become clichés, but if handled well, they could be nice.



Critique time


So what's good and what's not right?

Good

1) Overall, happy with the proportions. Smaller spin habs, a bit shorter with a bigger diameter. That would be a design concession to reality. For 1g of simulated gravity, you would need these habs to be spinning at mad speeds, resulting in a sickness-inducing Coriolis effect. The compromise is that these habs generate 0.2-0.5g. They are not used in transit, only when "parked" in orbit.

2) The superstructure is already looking a lot more like engineering and less of a modelling riff. The 2018 version was a step in the right direction, but the design now benefits from two supporting aft beams, which look like they could handle more plausible loads, without magical materials. 

3) The detail of the engineering section was a break in the rules. It's a detail, and maybe too soon, but It gives a new Soviet rocket vibe that suddenly has me wanting to add some more historical references. That said, I'll wait until the main Big and Medium elements are tied down before I start making any more references.

Not so...

1) Currently, the lines of the main body are a bit broken by sections all with seemingly different diameters. It could be cleaner. Although this might be nullified as more details are finalised. I could shrink down the gaps and unify some of the sizes to make it look cleaner? I'll try that.

2) The earlier sails were more interesting. The originals didn't bottom out so close to the centre. The 2018 versions have a cool shape. I like some of the elements and will change the shape to test various sizes and configurations.

3) I wonder if I need to build the superstructure first. Currently, the superstructure is solid, but it needs to be trusses and structural elements that will look more spindly. I think it's important not to get locked down yet. I'll keep an open mind and be prepared to shift away from any particular element.


Shamrayev project begins

 I'm not rushing into modelling. I wanted to do some sketching out to make sure that I do a proper rethink of the design. The early sketches have guided me to the following decisions:

  1. The configuration should be structurally sound. The sail masts could be more efficient at bearing load if they're biased toward forward acceleration. This means that the aft beam is angled more steeply and might be larger.

  2. The superstructure mustn't be too chunky. Load-bearing beams that are the wrong proportions (too thick) would weigh too much themselves and be self-defeating.

  3. Modular, as each component of the ship could be detached from the frame, and swapped out with a replacement, which just then gets wired and piped up to the rest of the vessel. And yet unified; all the older designs look mismatched, with some parts looking a bit Sci-Fi, while other parts looking realistic and NASA-like.

  4. Test the design against all criteria at each step of the design process. This means designing with the Big:Medium:Small principle and the 30/70 rule. Maybe get a second or more opinions as the design progresses.

  5. Strictly no greebles. If it's in the design, it fulfils a specific purpose.

  6. Keep to the spirit of the original design. Through the redesign process, let's keep one foot in the old design. Keep the component list and basic arrangement. I like these aspects of the design; it just needs a lot of refinement.

  7. No compromises. If I get tired, I stop and recharge rather than rattle off work to race to the finish line.

Early design notes and sketches

Mood board 1

I looked through some designs, new and old. The 2010 Leonov remains a favourite, although I'm aiming at something that looks more spindly and structural. The starship from Avatar is a brilliant example of this - I love how organic the core truss looks. There's the movie and concept version of the ship from Project: Hail Mary. Really cool work by Ivan Weightman, who started out as a concept modeller on Gravity, which is a perfect fit for the film. The personal piece by Maciej Rebisz is way closer to the book's version. I love Maciej's work, and he primarily works with Blender. On the subject of Blender users, Rasmus Poulson (AKA Technouveau) remains a huge inspiration. His work is more on the Sci-Fi side, with his Star Wars-inspired designs being some of the best -- better than some of the official ships. One ship he designed that took my breath away:


This is an incredible "have your cake and eat it" design that combines the fun and creativity of a Sci-Fi combat carrier with plenty of plausible engineering. The yellow superstructure gives a sense of something real, not a bunch of hollow 3D model parts. Although I'm not super keen on how the structure connects to the main ship, that visual mess is, in the end, a feature, not a bug, as it breaks away from the ship designs that are too sleek and regular...dull, dull, dull.  

Takeaways for the Shamrayev:

  • A balance between the cool overall shapes and a sense of visual mess. 
  • Maybe the crew hab module needs to be a smaller part of the overall design?
  • Maciej Rabisz Mars Cycler has fold-away masts. These look very cool. Something to think about? Some element of folding away might make sense. Possibly for high acceleration (2G+ spurts)?




Sunday, 7 December 2025

Crashes and render failures

 I've been unable to render any Geoscatter-based scenes that use TrueSKY 3. I get the following error all the time:

what is an ERROR Illegal address in CUDA queue copy_from_device (integrator_intersect_shadow integrator_queued_shadow_paths_array)
The AI search tells us is

"a technical error message primarily encountered during GPU rendering in Blender's Cycles render engine. It indicates that the graphics card encountered an invalid memory address while transferring data back from the GPU to the system memory (or within GPU memory), which usually points to a bug in the rendering calculations or an unstable system.

The (integrator_intersect_shadow integrator_queued_shadow_paths_array) portion of the message specifies the exact function within the Cycles source code where the error occurred, often related to ray tracing and shadow path calculations."



Potential Causes and Solutions

The error can stem from scene-specific issues, software configuration, or hardware instability. Common fixes include:

Scene Issues (Ray Calculations):
Limit ray travel: The error often happens if a ray of light "travels to infinity" outside the scene boundaries, causing numerical instability or invalid memory indexing.

A common workaround is to place the entire scene inside a large bounding box (like a cube) to contain all light paths.

Check complex shaders/geometry: Specific elements, such as volumes, complex materials (like Principled BSDF with Adaptive Subdivision), or the Vector Displacement node causing NaN (Not a Number) values, can trigger this crash.

Simplify the scene: The issue might be related to running out of GPU memory (VRAM), which can manifest as an "illegal address" error rather than a clear "out of memory" message.

Try reducing texture resolutions or simplifying geometry.

Software and Driver Configuration:Update/Reinstall Drivers:

Ensure you have the latest stable NVIDIA Studio Drivers installed. A clean installation of the drivers after completely uninstalling the old ones can resolve issues caused by corrupted installs or Windows updates.

Use OptiX instead of CUDA: In Blender's preferences (Edit > Preferences > System > Cycles Render Devices), try selecting OptiX instead of CUDA (or vice versa) if your GPU supports it. Using both simultaneously can cause conflicts.

Disable Open Shading Language (OSL): Turning off OSL in the Render settings has been a fix for some users experiencing this specific error.Hardware and System Stability:

Check GPU Overclocking: Any GPU overclocking (e.g., via MSI Afterburner, Dragon Centre) can make the render process unstable. Disable overclocks and run your GPU at stock speeds.

Monitor GPU usage/memory: Avoid running other GPU-intensive applications (like games or browser tabs) while rendering, as this can cause resource conflicts or run you out of memory.


There have been Python crashes too, and warnings about Maximum Number of Closures Exceeded"

The warning "WARNING Maximum number of closures exceeded: 96 > 64" in Blender's Cycles render engine indicates that a material in your scene is too complex to be compiled by the rendering kernel (usually the GPU). The number 64 is a hard-coded internal limit on the number of shader "closures" (functions or components) that a single material can use simultaneously. Your scene is attempting to use 96.

This is a common limitation when using highly complex or nested shader node groups, especially with the Principled BSDF shader or when using Open Shading Language (OSL).

Shamrayev rebuild

 

Shamrayev Rebuild

As I mentioned yesterday, I am planning to build a new model of the ship that I created for my design degree. The U.S.N.S. Igor Shamrayev is a fast courier intended for a fictional film project. It's a hard science fiction design, so not Star Wars or Star Trek, something with plausible propulsion technologies and no artificial gravity.  

Lets revisit the ship, the builds, and go on a whistle-stop tour of my 3D modelling history.

Design Inception


1991-92

The first model was designed and built in 1991 for my 1992 degree show. The whole project was about five weeks and involved learning to use Microstation. The university had seats for 3DS, but this was pre-Max and pre-running on Windows. It looked crude by comparison, although it was probably a better tool for this job. Microstation is a precise, engineering-focused 3D CAD application - perfect for product design. Still, its strengths simply wouldn't come into play when designing a low-detail object that is about 200m long. I do remember one of my colleagues on the course saying he liked the design but thought the crew habitat looked like a bottle of washing-up liquid. That was intended as a modeller-making Easter egg, given how all the Star Wars ships had bits from Airfix tank and battleship models on them. Cool, but not good design!

trueSpace-era

After finally getting a PC of my own, I rejoined the 3D modelling club after getting a copy of TrueSpace 1 on the cover of a magazine. Remember those, fellow old person? I was so excited by the prospect that I soon used a windfall of about £300 to pick up a copy of the newly released TrueSpace 2.0

TrueSpace was unlike any other 3D software. It was strongly UI driven, when most tools felt like CAD. Building models was fun, though it had limitations; it took years for them to impact most users. I was very sad to learn that trueSpace creator, Caligari, had shut its doors. A casualty of the Microsoft acquisition as it grasped for a 3D builder of its own.

Built in trueSpace 5/6, probably in 1998-9

The trueSpace version was only a little more detailed than the original, but we're talking  Windows 97-era with 16MB of system memory and 4MB of VRAM. 

Max Power

A few years later (2000s), I found myself helping to create a potential TV project (The Master Squadron). I was a 3DS Max user! I had a seat for version 4, although I never really learned how to use it properly.



I liked some of the design changes. Those sails look more structural and plausible, but could be so much more realistic-looking. The crew's hab is a double-hull that counter-spins, although the ship's propulsion system can accelerate continuously at up to nearly 1g. Hence, the crew enjoy simulated gravity through high acceleration. You don't need spin habs, you need a big ladder running the length of the ship because it's like a 200 m-high tower with the engines at the bottom and the command module at the top.

I'm not sure how I feel about this, now. Space vehicles in my Orbital Elements game use (near) continuous acceleration to simulate gravity. Having a small spin habitat might be helpful when the ship is coasting or in orbit.

3DS Max was a powerhouse, and I was, the whole time, tinkering in the evenings and sometimes at weekends. I wasn't driven, and I could go months without touching it.

Blender (first-bash)


This was built in 2018, some 10 years after the 3DS version. It's a lot more detailed overall because we're now running Blender. Ha! That said, having done a good job of bringing the command section into a more "SCI-FI" futuristic style, the rest of the ship wasn't all that different and, really, quite crude. This time I plan to go back to the formula and do a lot more reinterpretation, reimagining and a whole lot more detail.

I had intended to do a big animation fly-past, like the one I created for my degree show. Alas, the design looked shockingly bad when I tried to light it. My space lighting was rubbish, and, in fact, after downloading the file and testing in Blender 5.0, I see I made the classic mistake of not building the ship to scale, so the lighting would not behave correctly. Notice that I put an angel statue on the command centre's roof to show that the ship is about half to a quarter scale. 

These days, I have more time and patience. I can really go to town on the details. *Rubs hands in glee*                                                  

Monsterland

 

Monsterland

Since the release of Blender 5.0, I've been obsessing over how its improvements should unlock the power to do much bigger renders, or at least do them more reliably and efficiently.

So I gave it a smoke test. A smoke test is when you run something harder and faster until smoke starts to come out. If testing for smoke is the aim, I succeeded:


Your device ran into a problem. System automatically restarted.


Oh boy, it's dark in this resource-hungry terrain generation rabbit hole...  But interesting!



I created a 32km x 32km terrain in World Creator, which I exported as four 1GB EXR height map tiles. 

To bring this monster into Blender, TrueTerrain 5 is a great solution because it lets you import tiles and place them on a single terrain. World Creator as a Blender Bridge, which is good for some things but not nearly as powerful or flexible as True-VFX's terrain powerhouse!

1) Opening the True-Terrain tab, I created new terrain, setting the size to 32,000m. You'll definitely need camera culling enabled on this mission, but not yet. You need to get the tiles aligned, which is easier when you can see the whole thing. 

2) Load your first EXR tile into True Terrain, making the terrain your full size, but then adjusting the displacement map so that it's (in my case) a quarter of the terrain's overall size (16,000m). I also exaggerated the displacement so I could more easily check I had the tiles loaded in the right places. At the 32km scale, even great mountains aren't much more than bumps!

3) Load in each of the times, adjusting its size and using the transform tools. Use the File settings to adjust the tile size, then place each tile in the appropriate location by assigning offsets in the Location fields. For example, the first terrain was set to 8000 m on the X-axis and -8000 m on the Y-axis. You might see a seam where the tiles meet in the viewport, but I think this is a resampling artefact, as it comes and goes with changes to the terrain resolution. 

Check that your tiles are correctly aligned. Then, if you exaggerated the terrain's Height multiplier, now is the time to correct it.

4) Adjust the terrain's resolution to meet your needs and match your system's capabilities. Definitely use camera culling if you can; it can allow you to render more detailed terrains, since anything not in the camera view or padding isn't sent to the renderer.

In the last few years, Blender has seen some incredible leaps in performance, culminating in Blender 5's increased frame buffer that enables support for huge meshes, free normals and some really nice optomisations, such as with Adapative Subdivision, with the new "Object Space" option that allows a single high-detail mesh to be instanced many times with minimal memory usage, as the subdivision is calculated once per object, independent of the camera's view. This drastically reduces the memory footprint for scenes with many repeated complex objects, like environmental assets.

Stop holding Blender in portrait mode! ;-)

Home truths


Throwing more vertices onto a screen doesn't make better art or bigger, more engaging terrain renders. It's a capability worth measuring so you know how far you might go when needed. I made some heavy volume adjustments while testing and got my entire system to auto-reset. This is likely not a deficiency; it's just asking Blender and your computer system to do something that is the rendering equivalent of jumping off a cliff. You can forget doing elaborate animations or terrain-wide scattering, unless you add some optimisation steps. 





Friday, 5 December 2025

Trees - Asset Catalog

 Yesterday, I struggled to find the specific tree types I needed for the biome I'm designing. There's little point in having a vast library of assets if you don't know what you have or where to look for it. So here's the first instalment of a pictorial asset catalogue.

Trees

Bagapie Assets

The first asset library that I purchased. Oh how this became a crutch. It's still a fab collection because it's got such a wide range of trees and other assets.



Thursday, 4 December 2025

Service Road: Biome design


I've been itching to learn more about biome design. At some point, I'll be putting together a test scene for the Production version of the service road -- even if I'm not officially assigned that work, I want to test my ability to polish the previs up to production quality.


Biomes are about creating natural scatter systems that reflect reality. The right plants growing together in realistic patterns. When I start creating half-decent scatters, I'll then learn how to animate them.

Environment notes

The service road is located in a Mediterranean-like location modelled on the biomes found on the Greek islands. Not a wild leap from the setting of the Game Arma 3, which was used to create the film's storyboard.



The following plant life is common to the biome.

Trees

  • Olive trees (Olea europaea)
  • Cypress trees (Cupressus sempervirens)
  • Plane (Plantus)
  • Pines (Pinus halepensis, Pinus brutia, Pinus nigra, Pinus pinea, Pinus silvestris, Pinus heldricheii, and Pinus peuce)
Also, deciduous trees, such as 
  • Beach 
  • Chestnut 
  • Oaks
  • Fruit trees (various)
The forests mostly have fir, pine, and bush trees. These trees are commonly found in the northern part of the country and in high altitudes in Sterea and Peloponnese. Forests at lower altitudes mostly have poplars, plane trees, oaks, and cypress. At the foot of the trees, various bushes and flowers grow.

Bushes
  • Oleander (Nerium oleander)
  • Pomegranate (Punica granatum)
  • Bouginavillea 
  • Cistus incanus and slvi folius
  • Erica manipui flora
  • Pistacia
  • Buxus sempervirens
  • Juniperus
  • Arbutus unedo and andrachne
Small plants and flowers
  • Common Poppy 
  • Wild irises
  • Cyclamen
  • Anemones
  • Sea thistles 
  • Caper bushes
  • Daffodils and Daisies

First test



Big Gripe Tree

So you need to search for particular tree types in your extensive collection of nature assets. No problem, just use the search field. Actually, a big problem. There's no naming convention, so different packs name their trees differently. An even worse situation is that lots of packs don't live in the asset library. True-Vault, Arborea, Grasswald, et al. So I need to do about five searches using both Latin and common names.  So in the next post, I'm going to record my current tree catalogue. Be prepared for a LOT of trees.









Pretty shocking!

 

Yesterday, just before I headed to work, I received an email from Superhive informing me that my account had been restricted, and that I needed to verify my identity. I was in a rush and wanted to resolve the issue before leaving. So I checked the email was legit—it was. It came through Superhive. 



However, my spider sense was tingling. The language in the email wasn't quite right. The link formatting was inconsistent with everything else they'd ever sent me. I didn't even read the security warning, which is telling you this is not a legitimate email.

I clicked on the link...and.. oh gawd. 


That URL is a fire alarm. The dressing isn't terrible. The support chat window is reassuring but also not quite right.

So the email looks to have been sent through Superhive from a compromised seller's account and is dressed up to look like it came directly from Superhive. I messaged support through the website's main link, and received a reply very quickly that told me this is a scam and that prompt action has been taken to prevent the rogue account from sending any more messages. Not great but not terrible. Some kind of text scanning on the seller's emails might be in order, as they'd quickly identify suspect URLs. That linked page is under the top-level domain intended for clothes and fashion vendors?!


Terrains

Because I am addicted to the sculpting steps. I really need to use some of the scatter tools and MOVE ON.

New cliff assets. I spent so much money in the sale.

Sculpted steps. About 5 biome masks made this one crashy (in World Creator)

Details: nice. Too washed out.

Wednesday, 3 December 2025

Final hours of the Superhive Black Friday Sale... Spend Moah?!

 So I did pick up MatPlus, the layer-based material system that gives Blender a built-in Substance Painter-like functionality. Expensive! But it looks like it's from a reputable and dedicated provider.  I installed it, and found out that it doesn't yet support Blender 5. Erm, no worries. I installed it with Blender 4.5. Still not working. I tested and toyed with it until I was pretty sure this was probably me having missed a prerequisite or an installation step.

I raised the issue on their Discord, providing all the information they might need—and a few hours later, they gave me a workaround (leave the project root directory blank) and promised a fix would be in the next release. Pretty good experience.

The tool looks really good, but I will watch a few tutorials first. I also need to get my UV unwrapping a lot better, which is a sign that my modelling is a bit slapdash.

A better UV unwrap tool may be required. Strokes chin and looks at UVFlow's sale price...


Work for the rest of the week:

  • Updates to the next previs service road
  • More learning: MatPlus test before I forget I have it and never learn to use it. 
  • Practice with TrueSky 3. Some space scenes?


A bigger project for the near future

 While at work yesterday, I thought about the first 3D spaceship that I built. It was part of my undergraduate degree course, using Microstation. That's about 33 years ago?! It would be cool to do a rebuild in Blender 5? I actually did a reasonable rebuild a few years ago (2018?! yikes that long ago), but I had no idea how to light and stage it, so all the renders looked bad.

2018 build


What I would do differently. EVERYTHING.

Firstly, I did my old and bad trick of building everything to its fine-detailed final quality without doing a proper Big:Medium:Small blockout. 

There are some nice detail elements, but the forward section looks more Sci-Fi compared to the central part of the ship, which looks like hard science fiction. I would really sweat the engineering details. The superstructure frame doesn't look structural, like an actual load-bearing system. 

I'd build to a much tighter and finer level of detail, using what I learned from the more recent ship projects:

Bayern build. 2300AD game ship: not my design

Bayern used the Big:Medium:Small approach, and I think it was to scale.

Orbital Elements warship. Needed a bit more work, but I would change a lot now.

So the Ukrainian Space Navy Courier, Igor Shamrayev, is coming soon.

Monday, 1 December 2025

Blender School: Making assets using Polycam scans

 Polycam is a super-convenient phone-based photogrammetry application that I used to create simple models for use in Blender. See their Blender help page.

More Polycam tutorials.

I have some reasonable captures and want to make the most of them, maybe even start sharing them. Before I do, I want to ensure that I'm setting them up properly. So here's today's revision: 

The Best Workflow for Polycam Captures

1. Set up the model to be the best it can be. Consider in-app tools such as remeshing. Do any cropping or cleanup on the capture.

2. Export using the Glb format (GL Transmission Format Library). It works well and stores the texture information in the Blender file, so you don't need to hunt it down. Consider unpacking the stuff if you make changes, though.

3.  Import into Blender

4. Review the object's mesh quality. Make sure you have statistics enabled.

a) Are there artefacts or errors in the mesh? There could be capture errors that leave elements of the model misformed or missing. You can use additive modelling in Blender to boolean your own parts.

b) Are there holes in the mesh? Try using the Gridfill tool to repair the hole. 

When you do repairs, don't forget to unwrap the new faces and match them to the existing UV map.

UV Unwrapping Methods

  • Smart UV Project: Automatic unwrapping for complex shapes
  • Unwrap: Standard unwrapping based on seamsCube/Cylinder/Sphere 
  • Projection: For primitive-like shapes
  • Project from View: Projects from the current camera angle

UV Editing Tips

  • Use the UV Editor workspace for detailed adjustments
  • Pin important UV vertices to prevent distortion
  • Check for texture stretching in the viewport
  • Test render frequently to verify appearance


For the absolute best results with a model that requires extraordinarily high quality, consider retopologising with Retopoflow. It's a lot of work, but you can turn a complex capture that would be extremely hard to create by hand into a model fit for any purpose.



Orbital Elements: Medium Rig #2

Where's the Blender work? This is a Blender blog! That's coming; it's good I recognise it's too soon to start building becau...