Working on a Blender (collada) export, need some help

[Roland Melkert]

Hello all.

Orion pointed my to the Collada format in this thread:
https://forums.ldraw.org/thread-23915-po...l#pid36135

Couple of hours later I had a very basic highly experimental export for it in LDCad opening many exiting possibilities for using LDraw content inside blender.

But my lack of Blender experience is a bit of slowdown.

I would really appropriate some help in setting up some basic materials to use on the LDraw meshes/objects.

Can anyone share some pointers on this ?

A basic LEGO like plastic and rubber would be a great starter.

[Orion Pobursky]

Maybe get in contact with the Mecabricks folks? They already have a working export and I'd love to see a closer collaboration between us and them.

[Roland Melkert]

Maybe get in contact with the Mecabricks folks? They already have a working export and I'd love to see a closer collaboration between us and them.

Might be an idea, but they use a custom written blender plugin,

I really prefer to generate a single/some stand alone file(s) just like with the pov-ray export.


The one big problem I'm running into at the moment is that Blender doesn't really import the materials defined in the collada file, it seem to only use the given names.

So you'll have to edit all (unique) materials after an import by hand.

I'm looking into the possibility to link to the blender material library instead.

You could also solve this with a small plugin/macro which replaces the materials after import, but like I said I rather have it all standalone

[Roland Melkert]

Some progress
   

But I had to 'color' it manually inside blender.

For this you select a random brick of color x and edit its material, it will then change all bricks using that same color.

I'm also not sure how to handle the recursive nature of LDraw, how would one organize 'collections' etc inside Blender to get the model submodel feel of things?

It now generates this:
   

Again some pointers from experienced blender users would be highly appreciated.

[Roland Melkert]

Some more progress, this is how it now renders 'out-of-the-box':
   

Turned out the missing material was due to a typo in some ID tag

It now only seem to ignore the alpha channel in the diffuse value.

Also something weird is going on with the material binding as it sometimes attaches to the mesh while it should always be attached to the node object.
   

Anyone has a clue on why that could happen, all the refs are defined in a loop and thus exactly the same except for some names and matrices and there is nothing special/different about the parts referenced ether.

[Trevor Sandy]

Some more progress, this is how it now renders 'out-of-the-box':


Turned out the missing material was due to a typo in some ID tag

It now only seem to ignore the alpha channel in the diffuse value.

Also something weird is going on with the material binding as it sometimes attaches to the mesh while it should always be attached to the node object.


Anyone has a clue on why that could happen, all the refs are defined in a loop and thus exactly the same except for some names and matrices and there is nothing special/different about the parts referenced ether.

Hi Roland - I started with Toby Nelson’s LDraw Blender importer and created an additional module to automate the render. I modified the importer to enable common LDraw capabilities like supporting multiple search paths, importing an archive library etc... The addon can be used by any application using the out of the box Blender API/addon calls. You can see full details at my GitHub repo repo. I believe working directly with the LDraw format is optimal.

   

Cheers,

[Roland Melkert]

Hi Roland - I started with Toby Nelson’s LDraw Blender importer and created an additional module to automate the render. I modified the importer to enable common LDraw capabilities like supporting multiple search paths, importing an archive library etc... The addon can be used by any application using the out of the box Blender API/addon calls. You can see full details at my GitHub repo repo. I believe working directly with the LDraw format is optimal.

Seems very interesting, I'll take a look at it.

I'm still hoping to setup something universal though as my goal is to be able to export animations with the promise of Blender's faster (then povray) rendering at similar or better quality.

Export is the easiest to do this with as the LDCad internals know exactly how to process LDraw and animation scripts already.

[Roland Melkert]

Another update on my progress

It now handles MPD, transparency and fake seams.

   



I also seem to have indirectly solved the material binding problem as a result of using a different approach which was needed to preserve the LDraw recursion (submodels) inside the export file.



Lighting is still a bit overexposed haven't really played with lighting in blender nor the collada file itself.

Still need a lot of tweaks and cleanup as the whole process is still very fragile (e.g. mpd's using embedded parts won't export correctly).

I'm still hoping to find someone willing to help me with the collada materials etc.

[Orion Pobursky]

I'm still hoping to find someone willing to help me with the collada materials etc.

Unfortunately I think you'd get better luck in a Blender focused forum or a larger AFOL community forum.

[Nicolas]

Unfortunately I think you'd get better luck in a Blender focused forum or a larger AFOL community forum.

Hello, I am the Mecabricks guy 
If you want to get in touch with me, I could answer your Blender questions I saw in this thread. However, I can already tell you that if you want to get photorealistic results, you will have to write your own addon for Blender in order to build your specialised materials for the built in renderers (Cycles/Eevee). Generic formats like collada can only output generic materials. In the case of Blender, it is basically the principled shader with default settings. Besides as you already found out, you do not have a great control over how material and mesh data are structured which has a great impact on the render time and memory used.

[Roland Melkert]

Hello, I am the Mecabricks guy 
If you want to get in touch with me, I could answer your Blender questions I saw in this thread. However, I can already tell you that if you want to get photorealistic results, you will have to write your own addon for Blender in order to build your specialised materials for the built in renderers (Cycles/Eevee). Generic formats like collada can only output generic materials. In the case of Blender, it is basically the principled shader with default settings. Besides as you already found out, you do not have a great control over how material and mesh data are structured which has a great impact on the render time and memory used.

Thanks,

I already discovered some major downsides to the collada format and especially how Blender imports them (I suspect they don't fully follow the spec on some things).

But all in all I'm quite happy with the result it gives, I love that default 'milky' look cycles generates even with the default materials.

The main reason I hope to avoid writing a blender plugin is it would mean I have to basically rewrite the animation interpretation code in python.

I'm considering a small plugin which would post process the materials and lighting though, I would like some pointers on that some day if you don't mind.

[Nicolas]

I'm considering a small plugin which would post process the materials.

Yes, this shall really be on top of your to do list once you are happy about how your meshes import as this is the whole purpose of using a ray tracing software. Also make sure that materials are linked to meshes, not objects. This means that you can only use the same mesh with the same material. Using the same mesh instance with multiple materials (by linking the material to the object instead of the mesh) seems to be a good idea but is actually not (most 3D software actually don't even support this option). See the instances options in the Mecabricks Collada exporter.

[Roland Melkert]

Using the same mesh instance with multiple materials (by linking the material to the object instead of the mesh) seems to be a good idea but is actually not (most 3D software actually don't even support this option).

Yes I discovered that the hard way.

I'm now generating all material-part combinations as nodes in the library_nodes branch.

And then reference those using instance_node elements in the scene branch.

This seems to work the best, except sometimes Blender decides a node in the library branch is a standalone object and adds it separately to the scene without any unit corrections or scaling.

I'm close on pinpointing why that happens though.

[Philippe Hurbain]

Maybe RenderMan could be interesting too? See https://www.eurobricks.com/forum/index.p...nt-3206590

12 hours 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.

[Roland Melkert]

Update....

I've been working on the new export off and on again and decided to concentrate on geometry and animation data and leave the material side of things as they are.

I've also started a second exporter for the glTF2 format as it seems to have a much better support in Blender (and the 3D community as a whole).

glTF2 is easy to generate but seems to have only limited animation support.

On the plus-side I already managed to export glTF2 files including a simple (static) test animation. Blender accepts the file but the animation possibilities of glTF2 seem to be very limited.

   

Collada on the other end has very extensive animation support but I'm not sure Blender would actually import it all. 

In short I'm looking for some advise/thoughts on these issues, or maybe recommendations on a third format ?

I would also appreciate some collada animation test files if any one knows where to get them?

Attached is a glTF2 test export for the 5510.mpd example, any comments and feedback is welcome. (I removed the attachment, it's outdated).

[Roland Melkert]

Another update....

I finished basic glTF export, including animations. Animations are limited to include only object position and orientation as that's the only thing the glTF2 format allows (besides scaling).

Did a small render test, took cycles 15 minutes, which gave me the attached gif. I attached it as a zip as 1MB gif's are too large to attach as is.


I'm still not sure if collada would offer more animation possibilities, I might even drop collada from 1.7 as glTF2 seems to be enough (for now).

[Orion Pobursky]

Another update....

I finished basic glTF export, including animations. Animations are limited to include only object position and orientation as that's the only thing the glTF2 format allows (besides scaling).

Did a small render test, took cycles 15 minutes, which gave me the attached gif. I attached it as a zip as 1MB gif's are too large to attach as is.


I'm still not sure if collada would offer more animation possibilities, I might even drop collada from 1.7 as glTF2 seems to be enough (for now).

Awesome man. LDCad animation is on my list of things to learn.

[Philippe Hurbain]

Nice!!!

Animations are limited to include only object position and orientation as that's the only thing the glTF2 format allows (besides scaling).

What else is missing, warped meshes?

[Roland Melkert]

What else is missing, warped meshes?

Object visibility, camera fov, active 'out' camera, light color, light enabled, material changes. All of these can be done in LDCad animations.

I could probably fake visibility by putting objects far away when they need to be hidden and material changes can also be done by having multiple meshes of which only one is visible at the time. But these kind of workarounds complicated the export process considerable.

[MotoR]

Another update....

I finished basic glTF export, including animations. Animations are limited to include only object position and orientation as that's the only thing the glTF2 format allows (besides scaling).

Did a small render test, took cycles 15 minutes, which gave me the attached gif. I attached it as a zip as 1MB gif's are too large to attach as is.


I'm still not sure if collada would offer more animation possibilities, I might even drop collada from 1.7 as glTF2 seems to be enough (for now).

Hello. Where can I download a version with glTF export?   I found only 1.6d, released on 05 April 2020, on your website. Does the version support the glTF export?

[Roland Melkert]

Hello. Where can I download a version with glTF export?   I found only 1.6d, released on 05 April 2020, on your website. Does the version support the glTF export?

This feature is part of the 1.7 Alfa version, which I haven't released yet.

Development is in a bit of a pause at the moment, but I'm hoping to pick things back up in February.

I was also waiting on a Blender update as the glTF plugin of 2.82 had some bugs spoiling some minor things.

Those problems seem to be resolved in 2.91 though.

[Cam's Bricks]

This feature is part of the 1.7 Alfa version, which I haven't released yet.

Development is in a bit of a pause at the moment, but I'm hoping to pick things back up in February.

I was also waiting on a Blender update as the glTF plugin of 2.82 had some bugs spoiling some minor things.

Those problems seem to be resolved in 2.91 though.

Did this make it into the alpha? I havent been in front of my home PC in months and I hoped I could finally try out Blender for renders when I get it setup this weekend.

[Roland Melkert]

Did this make it into the alpha? I havent been in front of my home PC in months and I hoped I could finally try out Blender for renders when I get it setup this weekend.

The currently available Alpha 1 includes both the collada and glTF export (in the alt+e menu)

But I might remove the collada one at some point because it is unfinished as glTF seemed the better choice.

The lack of animation in glTF i'm hoping to compensate with extensions (would need a blender plugin to read though, but I'll have to research that first.).

[Cam's Bricks]

The currently available Alpha 1 includes both the collada and glTF export (in the alt+e menu)

But I might remove the collada one at some point because it is unfinished as glTF seemed the better choice.

The lack of animation in glTF i'm hoping to compensate with extensions (would need a blender plugin to read though, but I'll have to research that first.).

Im just wanting to do static renders so if the gITF will accomplish that then I will give that a shot.

[Roland Melkert]

Im just wanting to do static renders so if the gITF will accomplish that then I will give that a shot.

glTF will export static models just fine in the current version.

It just needs some post tweaking at the moment.

- dial down the light intensity or it will look overexposed.
- some materials need better default properties (transparent parts aren't that transparent at the moment etc).
- also be sure to delete the default camera/light as the glTF includes those too.

If you want to tweak materials used in all exports you can do that using the files in the glTF/defaults folder.

I would be very interested if you make any improvements on those settings,  as I'm no blender expert so the current default material settings are far from perfect

[Cam's Bricks]

I would be very interested if you make any improvements on those settings,  as I'm no blender expert so the current default material settings are far from perfect

Im no expert either. I am reading your post thinking I know these words but until I dive into this, I dont understand how I might delete these things let alone update materials. I am sure once I dive in, I might find somethings and I will be sure to share them back when I find them.

[Cam's Bricks]

glTF will export static models just fine in the current version.

It just needs some post tweaking at the moment.

- dial down the light intensity or it will look overexposed.
- some materials need better default properties (transparent parts aren't that transparent at the moment etc).
- also be sure to delete the default camera/light as the glTF includes those too.

If you want to tweak materials used in all exports you can do that using the files in the glTF/defaults folder.

I would be very interested if you make any improvements on those settings,  as I'm no blender expert so the current default material settings are far from perfect

So I have some results now that I have my 1.7 version working. 

For some reason the default colors are not the default LDraw colors. Is there a reason for this? 

Here is the first render using the default export colors (even the ground is supposed to be Dark Bluish Gray):


I thought it was over exposed for sure. I first thought to check the hex color values and found they were different than the LD standard colors. I changed them to the default colors:


I then thought that the LEGO wasnt shiny enough so I changed the roughness to 0.33 on all the materials:


I also thought the black was too blue so I changed that to RGB HEX #111A20


Im going to keep playing with this. I know that the lighting reflects and can have a big effect on color. Once I can figure out how to share my scene I will do that as well for consistency sake as a comparison.

Hope this is helpful.

[Roland Melkert]

So I have some results now that I have my 1.7 version working.

Seems very promising, I will make the 0.33 roughness the default.

Did you use cycles for these renderings?

You had to change the LDraw colors using the LDConfig.ldr file for this so I'm thinking to add an overwrite file to the glTF configuration set.

That way you can use alternative values during export without changing the LDraw color pallets.

Maybe even one per main group (plastic/metal/etc).

Or maybe even a .js per color number (e.g. mat_4.js) while still using the generic ones if there isn't one for a specific color.

Again thanks for sharing your finding.

[Max Murtazin]

This is for sure cycles, it doesn't like LDraw color values much

[Roland Melkert]

This is for sure cycles, it doesn't like LDraw color values much

It's probably a gamma/srgb thing just like in povray.

[Max Murtazin]

By the way, if you would need some help with pearl materials, I was working for quite long time with those and can aid in that field

[Roland Melkert]

By the way, if you would need some help with pearl materials, I was working for quite long time with those and can aid in that field

Any material definitions are welcome.

I've set the exporter up to use glTF template files, pearl is currently using:

Code:

"name": "%defName%",
"emissiveFactor": [0,0,0],
"pbrMetallicRoughness": {
    "baseColorFactor": [%defR%, %defG%, %defB%, 1],
    "metallicFactor": 0.5,
    "roughnessFactor": 0.5
},
"doubleSided": %defDoubleSided%

But at the moment these are basically just place holders, I would love to have some decent settings as the default.

[Max Murtazin]

glTF might be quite a problem to work with. Thing is, most of Pearl materials can't be properly done in glTF definitions due to them needing fresnel color varying (change of color depending on the angle light reflects from the part). If you have any way to import material as Blender nodes into the render scene, I can work around that

[Max Murtazin]

If you have a way to run a blender script on import of the rendering scene, I can also write a script that would load blender node material

[Max Murtazin]

Also, since we are dealing with Cycles, many color values for render can be taken from Studio, if solution that would work fine with LDraw color values wouldn't be found of course

[Roland Melkert]

I noticed the lack of color/material options of glTF too, but as I understand it there are a number of extensions.

We could even add a custom one and let a blender plugin work with that data to do some post import stuff like you sugested.

I'm planning to look into this anyway as I need lots of things not available in glTF for the animation export side of LDCad's glTF export. Things like visibility control, material changes, etc.

Most important thing for this to work is finding out if the default glTF blender import plugin preserves the 'unknown' data somewhere or just ignores it.

If it ignores it I would consider forking the blender import to add my needed post processing stuff to it.

But I haven't had much time to look into any of this.

[Max Murtazin]

Would be good to see such things working. Moving my rendering workflow from Studio eyesight to Blender would be a great thing to have, since dealing with the mess eyesight settings file structure is (imagine having to use XML to write a node tree) causing lots of pain. Maybe would be even a last thing needed to move from Studio to LDCad

[Cam's Bricks]

Seems very promising, I will make the 0.33 roughness the default.

Did you use cycles for these renderings?

You had to change the LDraw colors using the LDConfig.ldr file for this so I'm thinking to add an overwrite file to the glTF configuration set.

That way you can use alternative values during export without changing the LDraw color pallets.

Maybe even one per main group (plastic/metal/etc).

Or maybe even a .js per color number (e.g. mat_4.js) while still using the generic ones if there isn't one for a specific color.

Again thanks for sharing your finding.

Actually I changed them in the blender material in blender to match the LDraw color definition. I only changed the “base color” on each material to match the color code provided by ldconfig. 

I’m not sure if there is a way to just pass that hex through natively? 

I do think that since eyesight from studio is based on blender cycles, we finally have the opportunity to let the studio devs share something back to us in LDraw land 😅

There are a few other things I want to play with like a consistent scene to use as a starting point. The lighting in all my renders is one “sun” light set to 4 intensity on the right side of the model and then a 500W point light on the left positioned to be a secondary fill light. 

Hope this is helpful.

[Cam's Bricks]

Would be good to see such things working. Moving my rendering workflow from Studio eyesight to Blender would be a great thing to have, since dealing with the mess eyesight settings file structure is (imagine having to use XML to write a node tree) causing lots of pain. Maybe would be even a last thing needed to move from Studio to LDCad

Any chance you can help with the transparent materials? I see those are a definite area we could improve.

[Milan Vančura]

I would be very interested if you make any improvements on those settings,  as I'm no blender expert so the current default material settings are far from perfect

I'm (still) a beginner in blender but I remember I tested materials Matthew made for his ldraw import/export plugin - what about to join forces?

[Max Murtazin]

Any chance you can help with the transparent materials? I see those are a definite area we could improve.

I have some simple code for those too, but not something much impressive. Can share node setup in PM

[Max Murtazin]

I, for some reason, can't message you in PM

[Roland Melkert]

Well I've been tweaking on the glTF export this week and discovered why textures didn't work.

A glTF export from LDCad 1.7 Alpha 2 into Belender gives this:

  alpha2.jpg (Size: 28.29 KB / Downloads: 49)


An improvement over the Alpha 1 version but not what I wanted.

The problem is textures in LDraw are basically stickers you put on a part of the mesh.

glTF does not support that it basically assumes textures are wallpapers. Pre blending the images isn't good ether as it will give you this:
   


Next I decided to try and fix the issue inside Blender to see what a export to glTF would generate.

The texture material from the LDCad export generates this for the blender material.
   


The only way to get what I want is to manually change the shader into something like this:
   

edit: Bit shorter by avoiding the extra shaders (still not preserved in a export)
   

But when you export this to glTF in blender it will loose the background color again 

I'm not sure this is a blender (export plugin) thing or a general glTF issue.

Anyone know of a way to get the above result using valid glTF2 ?

Or should I just abandon the idea and maybe try another format. USD seems promising, but I'm not very motivated to start writing a (4th) exporter from scratch

[Cam's Bricks]

Is the goal to export the whole of animations to blender?

I saw that Matthew Morrison's LDrawExport (and import apparently) plug in can read the STEP meta and set key frames. It seems that the solution is not writing an export from LDCad but rather an Import plugin for Blender. 

I am really excited by the prospects of all this! Thanks again for your hard work!

Here is a link to the Git Hub Page for that Exporter:
https://github.com/cuddlyogre/ExportLDraw

Thread here on LDraw:
https://forums.ldraw.org/thread-24153-post-45248.html

[Max Murtazin]

I believe that only way to handle texture like in LDraw is modifying importer

[Max Murtazin]

Probably best way to handle colors will be using separate material file. Any typical model file format has very limited capabilities of handling materials. I suggest using XML-formatted node file, it's how Studio's renderer handles materials, and it's perfectly compatible with Blender. I have been already working for quite some time on import/export of XML nodes for Blender, so I certainly can help with that

[Javier Orquera]

Hello: I'm following this thread and I like the idea.
On the glTF problem: do you read the manual of blender? If not here it is: https://docs.blender.org/manual/en/lates...gltf2.html.
I am trying to help. Have good luck with the project.

[Roland Melkert]

Is the goal to export the whole of animations to blender?

I saw that Matthew Morrison's LDrawExport (and import apparently) plug in can read the STEP meta and set key frames. It seems that the solution is not writing an export from LDCad but rather an Import plugin for Blender. 

Yes. but mostly because cycles seemed to be easier/faster to use then povray.

Problem I'm having is LDCad's animations are scripted, there are over 12000 lines of code making that happen, rewriting this in a blender plugin is not really an option for me at the moment

With glTF I was hoping to get as much of the data across using the native format and then fill in missing things using a extension. Something I could write a much smaller / simpler blender glTF plugin extension for.

Here is a link to the Git Hub Page for that Exporter:
https://github.com/cuddlyogre/ExportLDraw

Thread here on LDraw:
https://forums.ldraw.org/thread-24153-post-45248.html

Thanks I will check that out.

[Roland Melkert]

Probably best way to handle colors will be using separate material file. Any typical model file format has very limited capabilities of handling materials. I suggest using XML-formatted node file, it's how Studio's renderer handles materials, and it's perfectly compatible with Blender. I have been already working for quite some time on import/export of XML nodes for Blender, so I certainly can help with that

Did not know you can export/import blender node data, I'll have to look into that.

Thanks for the pointer.

[Roland Melkert]

Hello: I'm following this thread and I like the idea.
On the glTF problem: do you read the manual of blender? If not here it is: https://docs.blender.org/manual/en/lates...gltf2.html.
I am trying to help. Have good luck with the project.

Yes I did see those, but they are a bit vague about details, so I have been looking in the plugin's own code for some more pointers.