LegoToR - a new rendering tool for LDD files

[M2m]

I have been working on this for quite a while but I think now it is ready for a more wide release (even though surely it will have tons of bugs - feedback welcome)

LegoToR (Lego To RenderMan) takes a ldd file as input at creates Pixar RenderMan output files - which you can ultimately render with RenderMan (there is a free version available from Pixar).

LegoToR is using Python and is developed and used on macOS, even so it should work on Windows and Linux (with some modifications) as well.

Get it here:

https://github.com/sttng/LegoToR/releases/latest

LegoToR is a command-line tool with a couple of command-line switches  (more below). The simple way to  start is:

./LegoToR.py MyLegoLDDFile.lxf -v -cam 0

This will use LDD's camera (cam 0).

Full details of all switches:

Detailed  usage: LegoToR.py [-h] [-s [SRATE]] [-p [PIXELVAR]] [-fo [FOV]] [-fs [FSTOP]]
                  [-wd [WIDTH]] [-ht [HEIGHT]] [-sa [SEARCHARCHIVE]]
                  [-st [SEARCHTEXTURE]] [-cam [CAMERA]] [-d] [-v] [-u] [-o]
                  [-t] [-w] [-n] [-z] [-b] [-fl] [-np] [-nn] [-nl]
                  infile

mandatory arguments:
  infile                required input LXF file

optional arguments:
  -h, --help            show this help message and exit
  -s [SRATE], --srate [SRATE]
                        modify shading rate. Default 10
  -p [PIXELVAR], --pixelvar [PIXELVAR]
                        modify the pixel variance. Default 0.1
  -fo [FOV], --fov [FOV]
                        projection fov. Default 25.0
  -fs [FSTOP], --fstop [FSTOP]
                        fStop. Default 9.99999968e+37 (unlimited)
  -wd [WIDTH], --width [WIDTH]
                        width of image. Default 1280
  -ht [HEIGHT], --height [HEIGHT]
                        height of image. Default 720
  -sa [SEARCHARCHIVE], --searcharchive [SEARCHARCHIVE]
                        searchpath archive. Default current working dir
  -st [SEARCHTEXTURE], --searchtexture [SEARCHTEXTURE]
                        searchpath texture. Default current working dir
  -cam [CAMERA], --camera [CAMERA]
                        set active camera. Default is -1 for Cam--1 'Minus 1'
  -d, --default         use PxrPathTracer
  -v, --vcm             use PxrVCM
  -u, --unified         use PxrUnified. Enable also in rendermn.ini to work!
  -o, --occlusion       use Occlusion
  -t, --direct          use PxrDirect
  -w, --wire            use PxrVisualizer with wireframe shaded
  -n, --normals         use PxrVisualizer with wireframe and Normals
  -z, --wst             use PxrVisualizer with wireframe and ST
  -b, --bxdf            use PxrVisualizer with wireframe and bxdf
  -fl, --flat           use PxrVisualizer with wireframe flat
  -np, --noplane        disable ground plane. Useful for space ships!
  -nn, --nonormals      disable writing of normals, as some normals in LDD may have problems
  -nl, --nologo         disable logo on studs

Also you need to set the RenderMan RMANTREE variable.

in macOS for example like this:

export RMANTREE=/Applications/Pixar/RenderManProServer-23.1/

Some example renders:

In addition there is tool called LegoToRHD included.

LegoToRHD is a LDD to Universal Scene Descriptor (USD) converter. LegoToRHD takes a LDD lfx file as input and converts it into a set of USD compliant files. The USD file format is used by Apple's ARKit and in a multitude of other professional applications from Pixar, Autodesk, etc.

LegoToRHD only support these switches (even so the help command says its more - this is a bug):

Detailed  usage: LegoToR.py [-h] [-np] [-nn] [-nl]
                  infile

mandatory arguments:
  infile                required input LXF file

optional arguments:
  -h, --help            show this help message and exit
  -np, --noplane        disable ground plane. Useful for space ships!
  -nn, --nonormals      disable writing of normals, as some normals in LDD may have problems
  -nl, --nologo         disable logo on studs

Here an exported file in Pixars usdview tool (usdview is not part of the package):

You can use USD files to convert them into AR files to be used on iphones with Xcode and Apple's usd tools (maybe I make a seperate post about how to do later).

Limitations / Known problems

• LegoToRs transparent materials are not as good as I like them, but I didn't have the time to tweak them yet
• LegoToRHDs will output textures with transparent Alpha. This is a shotcoming of the usd file format as far as  I know.

 

 

 

 

Edited March 7, 2020 by M2m

[supertruper1988]

Any reason to go thru all this for the outdated and unsupported LEGO Digital Designer vs an open format like LDraw or the supported Studio?

[M2m]

15 minutes ago, supertruper1988 said:

Any reason to go thru all this for the outdated and unsupported LEGO Digital Designer vs an open format like LDraw or the supported Studio?

It’s open source. So if you prefer any of these formats feel free to create a fork or add pull requests to add that functions. 

[M2m]

Just a quick comparison of renders in bluerender, busufl and LegoToR

bluerender - rendertime: 1min 25sec

busufl - rendertime: 4min 10sec

Stud.io / Eyesight - rendertime: 17min 26sec

LegoToR - rendertime: 07min 56sec

Even so LegoToR takes longer its the only one that renders flex parts and the grand-pa's hair (dual mold) correctly. Personally I like the trans-parts of busufl quite alot.

This is the test scene I used: https://github.com/sttng/LDD/raw/master/test01.lxf

Edited April 4, 2020 by M2m

[Dilvish]

How do you configure the camera and lighting? Does it require a separate tool? (Not familiar with LDD.)

Edited March 9, 2020 by Dilvish

[M2m]

Using the parameter -cam 0 will select the camera of LDD. Without it it will chose a standard, built-in camera which is approx 35deg above the ground and 45deg rotated.

For lighting it will use a sphere light (PxrDomeLight) based on the HDRI image that comes as part of the package. But so far it can’t be configured with switches. You can edit the rib file (yourFile_Scene.rib) in a text editor to modify the light and other settings. It’s cumbersome however, I agree. 

Edited March 9, 2020 by M2m

[Dilvish]

So, RIB files are the scene files utilized by Renderman? Are they plain text or binary? Is there a RIB syntax reference?

Edited March 17, 2020 by Dilvish

[M2m]

Yes rib files are the scene files utilized by renderman. 
I generate plain text rib (and usd files) - even though a binary version of the format also exists. Documentation is available from Pixar for both rib and usd file formats. 

[M2m]

Another render:

[M2m]

Made  a 4k render  (and added Han and Chewie to the cockpit )

Edited April 3, 2020 by M2m

[M2m]

On 3/7/2020 at 10:40 AM, supertruper1988 said:

Any reason to go thru all this for the outdated and unsupported LEGO Digital Designer vs an open format like LDraw or the supported Studio?

Ok. Ok. I looked into Stud.io and in fact just started to make some modifications to support .io files. Will take a couple of weeks given that this is a hobby project.

[M2m]

Improved the lighting setup and adjusted Metallic materials:

https://github.com/sttng/LegoToR/releases/tag/v0.5.0.4

 

[M2m]

Fixed washed out colors with color linearization and transparent geometries:

https://github.com/sttng/LegoToR/releases/tag/v0.5.0.5

I also played around with custom decals.

[SylvainLS]

Arr, it’s shapin’ up matey! 

[Calabar]

It seems that the washed colour fix had a side effect, the minifigure got older!

[M2m]

I made quite some updates since my last post:

• transparent material improvements.
• changed handling of material = 0 in a part. Now for 0 the 1st material (the base material of a part) will be chosen and not the previous material of the subpart before.
• Added reading of correct focus distance from lxf file camera, allowing for correct depth-of-field rendering.
• DB folder support for custom bricks in addition to db.lif support

Get it here:

https://github.com/sttng/LegoToR/releases/tag/v0.5.1.1

 

[supertruper1988]

Looking really great! Especially the transparent colors. 

Might I suggest 2 things:

1.) the top surfaces are very washed out and bright, for example, the second image of the Blacktron car is not black on the tops of the front slopes. 

2.) it seems that the whole image is "dull" but I am not sure if that is a problem with the HDRI used or the render light handling. 

[M2m]

On 8/1/2020 at 12:04 AM, supertruper1988 said:

Looking really great! Especially the transparent colors. 

Might I suggest 2 things:

1.) the top surfaces are very washed out and bright, for example, the second image of the Blacktron car is not black on the tops of the front slopes. 

2.) it seems that the whole image is "dull" but I am not sure if that is a problem with the HDRI used or the render light handling. 

Yeah I agree. I am not entirely happy with the colors. Could be a HDRI issue, could be a color linearization issue, maybe both. Anyway thanks for the kind feedback. And I am looking to improve it.

[M2m]

Another update to support the colors added in the latest LDD mod. Get it here:

https://github.com/sttng/LegoToR/releases/tag/v0.5.1.2

Bonus:

A R-Type spaceship I build in LDD and rendered:

[M2m]

I made some modifications and LegoToR possibly works on Windows now.

https://github.com/sttng/LegoToR/releases/tag/v0.5.2.1

Edited October 11, 2020 by M2m

[M2m]

For those of you who are running LDD on Linux (are there some ?), I added some preliminary Linux support. You can convert your lxf files now to obj or usda files on Linux as well.

I hardcoded the location of the db.lif file based on my setup as I am not really familiar with Linux/Wine. Let me know in case of problems.

https://github.com/sttng/LegoToR/releases/tag/v0.5.3.5

 

Edited October 13, 2020 by M2m

[SylvainLS]

1 hour ago, M2m said:

For those of you who are running LDD on Linux (are there some ?)

Sure there are!

 

1 hour ago, M2m said:

I hardcoded the location of the db.lif file based on my setup as I am not really familiar with Linux/Wine. Let me know in case of problems.

The default path seems okay to me.  You could also use a command argument or an environment variable.  WINE_PREFIX comes to mind (to replace “.wine”; not always set) but you could also simply use a variable for the whole path: if not set, use your default.  It would allow to set/use different dbs without the cumbersomeness of passing a command argument.  (Usage: “DB_PATH=bla ./LegoToR …” instead of “./LegoToR --db_path=blah …”)

Note, the Readme says “/LegoToR,” either you need a dot before the slash or you need to remove the slash and have LegoToR in the PATH.

[M2m]

1 hour ago, SylvainLS said:

Sure there are!

 

The default path seems okay to me.  You could also use a command argument or an environment variable.  WINE_PREFIX comes to mind (to replace “.wine”; not always set) but you could also simply use a variable for the whole path: if not set, use your default.  It would allow to set/use different dbs without the cumbersomeness of passing a command argument.  (Usage: “DB_PATH=bla ./LegoToR …” instead of “./LegoToR --db_path=blah …”)

Note, the Readme says “/LegoToR,” either you need a dot before the slash or you need to remove the slash and have LegoToR in the PATH.

Using environment variables seems a great idea. Would you rather think its better to capture the whole path to the db.lif file like /a/b/c/db.lif or rather only to the folde where db.lif - or its extracted counterpart - the db folder resides (so in the former example /a/b/c) ?

Meanwhile it was much more painful to get Linux running on external usbdrive then I expected :( Thanks for UEFI and Touchpad stupidity (the latter working only on every 2nd or so reboot)

Edited October 13, 2020 by M2m

[SylvainLS]

38 minutes ago, M2m said:

Using environment variables seems a great idea. Would you rather think its better to capture the whole path to the db.lif file like /a/b/c/db.lif or rather only to the folde where db.lif - or its extracted counterpart - the db folder resides (so in the former example /a/b/c) ?

Well, it could be both: if /a/b/c/d is a file, you know to try and read it as a LIF, if it’s a directory, you try and read it as an expanded LIF, or you try to find a directory “db”, or a file “db.lif” in it 

 

[M2m]

2 hours ago, SylvainLS said:

Well, it could be both: if /a/b/c/d is a file, you know to try and read it as a LIF, if it’s a directory, you try and read it as an expanded LIF, or you try to find a directory “db”, or a file “db.lif” in it 

 

Ok I might do that. 
Do you even use RenderMan on Linux ? 
Ultimately I gave up trying to get RenderMan working on my Ubuntu, because:

1) RenderMan uses Redhat style packages (ok I converted these to deb with Alien)

2) I couldn’t get WiFi working so I couldn’t get my license from Pixar