No Studs Here! (In Search Of Studless Models - Part 5)

Personally, I think the appeal of studless models is that, generally, they just look nicer, and more "polished", so they appear as if they have been finished with a "human touch".  Hence giving a computer the ability to create studless models might begin to blur the boundaries between computer generated models and human created models. 

As the brick matrix was now being randomly created (as opposed to selecting an LDraw part and calculating the brick matrix) it was now much easier to swap out bricks for similar bricks - so swapping a 1x1 standard brick for a 1x1 cylinder brick or  a 1x2 standard brick for a 1x2 grill brick or 1x2 with embossed bricks became much simpler.  Sloping roof tiles were set to only be added at the top of the models (because of the issues with the height of sloping roof tiles noted previously) 

Having managed to track (most of) the available studs in a build I could begin to apply colours to the model to make it more visually pleasing.  I also wanted to include some transparency as that can make the renders look more interesting, especially with the photoreal renderers that are becoming increasingly available.  Distributing the colours over the height of the the design meant adjusting for the max height of the model.  For shorter models (under 5 units high) I coded to add more blue, which helps to break up the green floor of the other models

What! A Stud? (In Search Of Studless Models - Part 4)

Isolating the available studs in a model requires that you analyse the whole column of bricks above any given stud - by analysing each layer in the column of your build matrix it's possible to isolate where the studs should be available - however my current code is not flawless - in the model below there are a couple of studs that are not identified (one above the base layer and one above the 1x2 wall texture brick).

Imaginary Bricks! (In Search Of Studless Models - Part 3)

I'd returned to just using 1x1 tiles to try to isolate stud availability.  I had been using my brickalo code to generate the models that I would then try to add tiles to, however my brickalo code was an unmanagable mess (of my own making) so I decided to rewrite my code to better support the isolation of studs within a model.

Initially my new code focused purely on the placement of tiles on "imaginary" studs of imaginary bricks!  I coded a mechanism of creating a numpy matrix that could represent the bricks and plates added to a model (without actually bothering to add the brick to the LDraw model).  However it quickly became apparent that having made a functional matrix that could track imaginary bricks and plates - I may as well use it to add real bricks to the LDraw model.  It's worth noting that this approach was very different to the code I'd used for brickalo.  

With brickalo, the code selected a random LDraw part (from a list of parts) and then drilled down into the part to work out what the dimensions (1x2,2x2,2x4 plate or brick etc) of the LDraw part were which then allows the code to calculated the part matrix which is then added to the larger build matrix.  With my new code, that I was using for tile placement, the part matrix is randomly generated, and the corresponding part selected according to the dimensions and size of the randomly generated part matrix.   As it turns out, this new approach would allow for the selection of  many more variations of similar parts.

Not All Tiles are Equal (In Search Of Studless Models - Part 2)

Initially I looked at trying to use 1x1 sloping roof tiles to place on each available stud but the problem with these parts is that they are not 1 plate width high, so not only do you need to identify available studs but you also need to know the gap distance between the stud and any parts above the stud.  In the little animation below it looks like I got lucky, but if you look carefully, there is an intersection in the model!

Another couple of intersections are more obvious in the model below.

In fact I've yet to solve this problem, so for now sloping roof tiles could only be used on the top of a model!

In Search Of Studless Models (Part 1)

Studs are, of course, the real magic of Lego, but isolating a specific stud on a specific piece of Lego within LDraw's construction system can be a challenge.  On a standard brick, in a given location you can calculate the stud location, but what if you are randomly placing random bricks and random plates into a model, how can you track the location of available studs within your model?

Tracking stud availability within a random model build would turn out to be a lot trickier than I imagined.   

I started by reviewing the layers of the brick matrix that I use to track the placement of bricks and plates during the model build

Previously I'd only really focused on a single matrix layer during the build process to track the addition of new bricks as they were added to the model build (so I always focused on the top most layer in the matrix).  What I would need to do now was track all the layers for each brick added to the model build and then compare each layer to try to isolate where a stud might be available, by eliminating studs as more bricks were added to the model.

Blender 2.8 and LDraw Renders

The latest version of Blender - v2.8 (https://www.blender.org/download/releases/2-80/)  is making rendering Lego ldr files a lot easier - you just need to add the LDraw importer to import the models (https://github.com/TobyLobster/ImportLDraw).  These were rendered on pretty much the default settings.

The main thing to watch out for is the "Add Environment" setting when importing the LDraw file into Blender.  Adding an environment adds a floor (to cast shadows on to) and a background image (as an exr file).  However Blender does not seem to read the exr file correctly - which creates the "pink hue" effect when rendering with missing textures in Blender - as this is a background texture - everything gets the pink hue

The quickest way to fix this is to simple remove the backround.exr file before you render.  Under the Rendering tab, choose the world icon on the right hand side, and remove "background.exr" from the colour setting. 

Your model should now render without the pink hue!

Building Duplo Walls

My friend in China had a problem with his Duplo build, when building walls with Duplo my code would create models that were not particularly strong, the repeated patterns of bricks would cause "fault lines" to appear in the model.  Whilst there is some ability to deal with this in the code (using a brick discard function for repeated layers), it did not help to solve this particular "fault line" issue.   Consequently I added a function to randomly discard some of the bricks in each layer, to break up the repeating pattern.  Whilst this may not be ideal for the majority of model builds (as smaller bricks tend to decrease the strength of the overall model), in this particular instance it does increase the strength of Duplo walls.

Optimising Lego ldraw Duplo Models

What I also needed to do was to optimise the Duplo model to remove repeated 1x1 bricks (as I'd done previously with the Lego models) - the code looks for the definition of 1x1 bricks using the value assigned to the layer matrix; where this value is derived from the dictionary of brick parts - for the Lego conversion this value was 914 - for Duplo - which uses less brick shapes it was 909 - consequently it was relatively easy to fix, allowing for the removal of repeating 1x1 bricks.  Here's Yoshi in Duplo glory!  If anyone is interested with working with Duplo models let me know.

Creating LDraw Duplo Models

I got an email from someone in China asking if I could make my 3D model to ldr file conversion work for Duplo bricks - he'd already had a go and included some .dat file for 1x1 and 1x2 Duplo bricks but I needed to tweak the code a bit to make it work - with Duplo, the models are less likely to be physically possible to build (at least with the bricks he initially wanted to use - 1x1,1x2,2x2,2x4) but the code tweaks were less complex than I expected.  A couple of examples of Duplo models built using my revised script below:

Creating More Sculptures - Build Like An Egyptian!

Following a presentation on Lego sculpture I wanted to look at creating some Lego sculptures using some of the models that you can download for free from various online model libraries.  These included TurboSquid, SketchFab, Sketchup's 3D Warehouse and CGTrader.  I went with a bit of an Egyptian theme and downloaded the following models from the various websites

I converted them into Lego models using the process I've outlined here and using the instructions and code on GitHub.  I then rendered the animations in Studio 2.0 (which took a few hours) but I was fairly happy with the results.

Creating Lego Sculptures - Those boots were made for building!

I wanted to see how flexible my scripts were for building Lego models from a 3D model that I downloaded from the internet.  Ideally I wanted to see if I could convert a 3D model that had been created from a 3D scan, so I selected a file on SketchFab and ran it through my 3D polygon > Coloured voxel > Ldr file pipeline that I've documented here and that's available on github

The final result was rendered in BrickLink's Studio

Unreal Lego

I've been looking at importing LDR files into Unreal Engine 4.  I haven't used Unreal Engine since version 3 so I was pleasantly surprised by how easy it is to import assets into Unreal Engine in the latest version.  In the past you had to use esoteric .psk files and the like - now you can simply import .fbx files.

The main problem I had was getting the colours in.  Blender does not seem to include the colours when it exports an .fbx file and I couldn't work out how to bake the colours in using Blender - in the end I had to resort to using Maya to export the FBX file.

Instructing A Dolphin

I recently offerred to build an set of instructions for a Lego Dolphin that a London AFOL friend had made - the model was faily straightforwards and I'd originally built the initial model in LDCAD.  Previously I've used LPub3D to create instructions but this time I thought I would use Studio 2.0.  Studio is improving all the time and the instruction tools looked pretty good so I thought I would give it a go.  

The Step Editor and page design tools are very intuitive, allowing for straightforwards drag and drop and I was able to create a 50 step instruction set fairly easily to build the dolphin model.  As a first attempt I was fairly pleased with the output, which was easy to export a PDF file.   The only caveat is if you are using flexible parts - whilst Studio is beginning to support flexible parts but not all them currently so for some flexible parts (like PF cables that I used in my Robot Car here) you might still have to use LPub3D.

OpenSDRAW - Feel The Power!

I've started to look at OpenSDRAW - Its fairly complicated but seems very powerful, allowing you to manipulate libraries of parts and create animations (without having to get stuck into something like Blender).  I rendered a couple of the example animations...

Currently, I don't really know how it all works in detail - but I like what it can do!

Flexible Parts in Stud.io (but rubber bands remain elusive!)

The latest version of Stud.io supports 13 flexible parts (including string with stud on ends) but sadly rubber bands aren't available yet, which is a shame as they were an important component in my "Professor Branestawm's Invention For Peeling Potatoes" MOC.

The latest version does though fix the problem I had with "missing bricks" when I used the Stud.io photoreal renderer on models that had been created by my ColouredVoxel2LDR script.  You can see there are quite a few "holes" in the model on the left, but the model on the right has all the bricks present.

www.brickalo.com gets spammed!

It looks like my www.brickalo.com website has been found by some sort of SPAM robot.  I've kept an eye on the backend system which does not appear to have been compromised - any email addresses entered in to Brickalo are not used and the system does not send out any emails (there is no email server installed on the backend).  So it does appear that robots are now playing with Lego!

In the image above, probably 75% of the Rainbow Lego Towers have been built by some kind of spam robot!     

ColouredVoxel2LDR Code on GitHub - Coloured Voxels Part 6

So I've posted my code and instructions to allow you to create LDraw .ldr files from textured 3D models on GitHub

https://github.com/pennyforge/ColouredVoxels2LDR

This includes a fix to remove (by merging into larger bricks) the spurious 1x1 bricks that could appear on the models (check out Yoshi's nose in the previous post for an example of this problem).

Hope you enjoy it - Let me know how you get on!

Video Game Giants - Coloured Voxels Part 5

Although the conversion of Yoshi to a Lego Model works really well, what I'd realised previously is that there is a problem with the way my code scans the voxel slice as there is a tendency for the code to create lines of 1x1 bricks, when they could clearly be converted into a larger brick shape.  The problem is caused by the fact that my code scans the voxel slice horizontally then vertically on each consecutive layer (as this adds strength to the resulting model), however with coloured voxels it's possible for lines of coloured voxels on the edge of the model - the skin if you like - to be interpreted as a single 1x1 brick on one slice and as a larger brick on a subsequent slice - you can see this quite clearly on Yoshi's nose in the image below.

I wanted to try to remove this 1x1 brick anomaly from the models as it is likely to effect the strength of the model (you can see a column of 1x1 bricks on the left of Yoshi's nose) and it looks unnatural in the build, no one would really use a row of 1x1 bricks when larger bricks are available.  Consequently I was going to need to do a second pass on each voxel layer to try to remove these lines of 1x1 bricks.

Yoshi In Lego - Coloured Voxels Part 4

Here's Yoshi in Lego!  The original in Blender is top left, the voxel file in Goxel top right and the final Lego model rendered in Stud.io underneath.  I've now accessed the colour data from the vox file and I've written a comparison function to compare the RGB voxel data to the closet Lego colour (using the colour data from LDConfig.ldr), so the conversion of voxel colours to Lego colours is now automatic.

Goxel to LDR - Coloured Voxels Part 3

I've carried working on optimising coloured voxel models into ldr files - I'm making progress.  In the image, on the left is the voxel file from Goxel (that I made on my iphone BTW!).  The optimised ldr (that I create by processing the resulting .vox file) is top right and the file rendered image in Stud.io bottom right - for some reason Stud.io has decided to delete some of the bricks from the render (all the bricks appear correctly in the stud.io interface but when I click render some bricks are not rendered!) - I'll worry about that later!  However the script does now convert the individual 1x1 bricks into larger bricks and does the 90 degree rotation on alternate layers to add strength.

There are still a few problems -

1) I can't currently read the colours!  Weird I know but I get a colour from the .vox file (and that colour is consistent where it appears) but I can't currently read the RGB values - I manually fix the colours with a find replace - hopefully I'll get the RGB values shortly - then I need to do a compare between the voxel RGB and Lego RGB and find the closest match.

2) Due to the way my script scans the .vox model there is a tendency for it leave a number of 1x1 bricks on each layer pass - this didn't occur with single colour models as the 1x1 bricks would be merged with their nearest neighbour.  However with coloured voxels this is not always the case - I should be a be able to fix this with a second pass to clean up any remaining 1x1 bricks which have the same colour neighbour.

3) There is some kind of mirroring/reflection going on when I process the .vox file

Big Models = Big Colour - Coloured Voxels Part 2

Although I'm only creating 1x1 ldr models I thought I would see how big my current script could go.  So I loaded one of the Magica Voxel demo files into my script and let it run.  It took over an hour to process on my workstation but in the end it did create an ldr of the original voxel model - this ldr file contains over 220,000 bricks!  Not very practical but it does mean that I should be able to process some quite large models.

A World of Colour - Coloured Voxels Part 1

I've returned to converting voxel models to ldr files, but this time my hope is to be able to convert coloured 3D models to a .ldr file with coloured bricks.  Binvox does not seem to support coloured models so I needed to research other voxel modelers with colour support.  Consequently I discovered Magica Voxel and Goxel - both support coloured voxel models and both are free to use.  Both have useful toolsets for creating and rendering voxels models but Goxel has better import/export options than Magica Voxel and there is also a iOS goxel app (but you have to pay for that).   Magica Voxel created and use their own .vox format (which supports coloured voxels) and Goxel can import and export .vox files

Goxel also supports it's own internal scripting language which opens up considerable possibilities for procedural builds and designs.

As part of my research I also discovered py-vox-io (which like binvoxpy) would take the heavy lifting out of having to decode Magica Voxel's .vox file format as py-vox-io allows python to read and write .vox files.  Unfortunately py-vox-io only runs under Python 3 so I would need to switch from Python 2.7 to Python 3.  To be honest I needed an excuse to switch to Python 3, which has become increasingly established so I decided to jump in with this project.  I also decided to switch my IDE to Microsoft's Visual Studio Code.  My previous IDE was a lash up of Notepad++ with some plug-ins so I could call python directly - it worked for me but it wasn't exactly "standard"!

Changing to Python 3 and switching my IDE means that I've had to go back an rewrite some of my binvox code that I created previously to build .ldr files from binvox files and I also needed to add support for reading the colour information in the .vox file format.  Currently although I can access details about the differences in colour between each voxel linking together the Lego colour palette and the .vox file palette is quite complex and at the moment I need to manually assign the correct Lego colours in the LDR file.

So the image above shows the original .vox model in Magica Voxel, the initial LDR output (before processing the colours) and the final LDR file with the colours manually remapped (using a find/replace function) to Lego colours

   

Stud.io v2.0 and Eyesight Photo Real Renderer

I've had a quick look at the "Photo Real" renderer that Stud.io v2.0 uses - its called Eyesight and there are some reports that it's based on Blender's "Cycles" renderer but I can't be certain of that.

Eyesight seems to be a command line renderer so you throw commands at it and it renders something.  Here's the command that Stud.io creates when you click the render button

"C:\Program Files\Studio 2.0\PhotoRealisticRenderer\win\64\eyesight.exe" --daewindingorder clockwise --autoexit --device-occupation 5 --device CPU --logpath C:\pathToMyFile\logFile.log --width 640 --height 480 --samples 256 --ground --ground-red 0.8 --ground-green 0.8 --ground-blue 0.8 --defaultlight --preset BUILD_RL --defaultlight-rotz 29.58608 --light-intensity 1 --daefile C:\pathToMyFile\myFile.dae --output C:\pathToMyFile\myFile.png

Stud.io wrties the .dae file to this location (or you can just use export>dae from the file menu)

C:\Users\[yourUsername]\AppData\Local\Temp\Studio

The .dae file that Stud.io creates for Eyesight to render is a txt file based on Collada's .dae XML file format (so you can just edit it with a text editor) - this gives you access to all the "internal" render parameters.  Stud.io also lets you add scratches to the render which is unusal - I've over-cooked the scratches on this model to make it obvious! 



The scratches are configured in the .dae XML file and use some preset textures that are stored here...

C:\Program Files\Studio 2.0\PhotoRealisticRenderer\win\64\textures

So you could in theory make you own scratches - plus there is also a Lens dirt texture in there but I can't see how to apply that in Stud.io.

Typing

"C:\Program Files\Studio 2.0\PhotoRealisticRenderer\win\64\eyesight.exe" --help

will give you Eyesignt's command line help



There are some interesting options there - particularly the "animation" ones.

Creating Lego Instructions From The Command Line

As Brickalo (www.brickalo.com) now allows a computer to create multiple ldr files I wondered if it was possible to also create LEGO instructions, as PDF files,automatically from the command line.  Whilst the computer doesn't need any instructions they are still useful for us humans when physically building Lego models! After a bit of poking around I discovered it was possible to use the command line with the latest version of LPub3D v2.3.3

You can use the following command

"C:\Program Files\LPub3D\LPub3D.exe" -pe -o -f "C:\path\myFile.ldr"

Which will output a pdf file in the same folder as the ldr file (and with the same name - just with .pdf on the end) - The full list of command line options for LPub3D is here..

https://github.com/trevorsandy/lpub3d/issues/12