First impressions

[BertVanRaemdonck]

You blew me away, Toby! I was planning to spend my summer on improving the LDRImporter, and now you show up with something way better than I could ever hope to achieve. Your importer tackles mpd models perfectly, does a great job with normals, has no problem with generated parts and attains an insane speed (my 5111 piece WIP Big Ben in about 30 seconds!). Furthermore, the code looks very transparent at first sight. It's great that we could be an inspiration to you, and it joys me to see little pieces of our own code return here. So awesome job!

That being said, here are some remarks I have after a first tryout:

• I think the default scale is quite big. When I tried to change the scale, nothing changed, however. Changing other values like the gap size did have an effect though, and I can spot nothing in the code that fixes the scale on a certain value...
• I see you have a fresnel node for the transparent materials, but not for the rest. Why not? The Fresnel effect is something present in every material. The roughness of the diffuse might be a little bit higher for my taste too.
• When importing certain pieces, like the minifig binoculars, I get the warning that the program found double sided polygons. From what I understand from the code, this is something that lies with the parts themselves, and is nothing that the importer can fix. However, the result is something that is really messy to fix in Blender. Are you sure there is nothing you can do to make the part as good as possible? You could guess a normal and apply that consistently, so that it wouldn't be too much work to adjust everything manually in Blender.

Furthermore, your program looks really complete, but there are still some goals worth striving for:

• Don't do the logo's with geometry, but with a normal map. This requires UV-unwrapping of the studs though, something I've been told is quite tricky.
• Display mold marks on the bricks in logical places. This can be done with normal maps, or perhaps with geometry. I have a .dat file of such a logo with mold mark lying around by the way.
• Render slopes with the grainy texture (a voronoi texture works beautifully for this, see my custom LDRImporter branch). As far as I know, though, there is no way to automatically decide which faces should get this texture, so it would require a hard coded list, which means quite a bit of work.
• Don't use an edge split modifier with an angle limit. Parts like 2489 get smooth edges due to this, even where they shouldn't. A solution could be to interpret the "2" lines from the .dat files, and use them to determine which edges should be sharp and which ones smooth.
• Implement bevels with a bevel shader. There is one available online, but this uses osl, which requires you to render with cpu. I'm looking myself into a way of building a custom node that blurs normal maps, but I'm still in the research stage.
• Give the option to remove unnecessary geometry. You might be able to detect cases in which a stud is covered by a brick, or the underside of a brick is obscured. This might lighten the load of the computer, but with how fast your importer is, that isn't much of a problem!

That's everything I can think about after an exhilarating first test. Keep up the good work!

[TobyLobster]

Thank you @BertVanRaemdonck for the kind words and for the considered feedback, it's much appreciated! I've just released a new version (v1.0.1) which fixes the issue of the scale not changing properly. It also adds fresnel to the regular non-transparent materials as you suggest.

You are right that with some older parts in the LDraw library (parts that are not yet BFC certified) the direction of the normal is ambiguous. In this case I create two faces back to back - one pointing 'out' and one pointing 'in'. This way the model should render correctly with no user intervention required - an important goal I feel.

However I can see the resulting mesh is not as 'clean' for further modelling work as it ideally would be with single faces pointing the right way. So there's an argument for an option (off by default) that takes a 'best guess' at the face orientations and lets the user manually clean up any errors by flipping normals. I'll take a look at that.

In regards to future goals, there's certainly much food for thought there.

[BertVanRaemdonck]

Thanks for your speedy reaction and fixes. I understand your decision with making those double normals, as it does allow for a quick rendering. However, as soon as you start going in advanced materials, things go wrong. Already with the Fresnel node, for example: now that that node has been added to the basic material setup, those double sided faces render wrong because Fresnel uses normal information, so now the issue certainly becomes relevant.

Here are a few more things I noticed:

• Not all of the studs get the logo, stud4a.dat, for instance. Your list of stud primitives in the code isn't complete, in other words.
• Having a Fresnel with an IOR of 1.52 for rubber materials, and setting a higher roughness there, will result in better looking rubber materials. Now they look a bit too much like regular plastic in my opinion.
• And another thing that might be implemented in the far future: the option to import bricks with more detail on the underside: indented cylinders where the studs are on the other side of the surface etc. Tricky to do, as you have to cleverly change the geometry of each part. And best to use in conjunction with the feature that would delete invisible geometry to prevent excessive geometry.

[TobyLobster]

You are right about the normals of course.

I've just released v1.0.2 which by default resolves the normals using Blender's Recalculate Normals functionality as you suggested. I've left the option of using the previous handling using two faces back to back (it might be of use to people exporting for games for instance).

Recalculate Normals works pretty well. There are 351 files that are not BFC Certified in the official set, and of these it fixes 65% of them (231 files) completely. The stubborn remainder (120 files) are improved, but may require some user intervention. The only way to fix these properly is to update the LDraw files to make them BFC Certified.

This release also includes your suggested improvements to the rubber material.

With regard to the studs, there are many stud designs, but only some of them should have a logo. I've entered some thoughts on this on a separate issue #2

[JoshTheDerf]

Just a quick question, do any of those parts without a "0 BFC CERTIFY" line contain any BFC instructions at all? Something I did with my parser was to ignore the BFC CERTIFY instruction, instead handling any BFC lines found. Not sure if that is a safe thing to do, but if a part is not certified and still has instructions, it would probably help with converting it to a proper mesh.

[TobyLobster]

@Tribex Nice idea. I've just done some text searches and turns out the only BFC instructions in those difficult parts are - five files use "BFC NOCERTIFY" (which makes sense) and - one file has a "BFC CERTIFY CCW" followed by a "BFC NOCLIP" which turns it off. So nothing to be gained for the official parts. There still could be wins for unofficial parts.

[JoshTheDerf]

@TobyLobster Alright, thanks for the clarification. :)

[BertVanRaemdonck]

Thanks for thoroughly looking into the issues, Toby. You really are too kind.

I'm now doing a series of renders of different models in a single file, and here's what I noticed:

• When I make a change to the materials, and afterwards import another model in the same file, the edited materials get overwritten by the default. This is something rather irritating, as it leads to quite some work. I suggest checking if the material exists first, and if it does, using that one. You could say you sometimes want the default back, but I suppose that if people start to do really special things, they'll change the name of the material (like making a slope material based of an original smooth material).
• Related to this, when you make a change to a part's geometry, and then import another model, these changes don't get carried over to the parts of the new model. You could save people some work cleaning up normals, applying different materials to a single part etc. If they do a one time change, they'll normally click on the part they want to make special and press U. This will give the selected mesh the .001 extension. So usually, the mesh without the extension will be the unchanged, original one.
• I build my models in LDCad, and the Rubber bands get imported perfectly. However, the rope gets imported as a series of individual small cylinders, instead of a single part. Looking into the .mpd files, I can't really find an indication why ropes would be any different from rubber bands though...

[TobyLobster]

@BertVanRaemdonck I've just released v1.0.3, which as you suggested now does not overwrite materials or meshes. It processes the LDraw "2" edges to find all the sharp edges - and the results look very good (screenshot on releases page). The variations on stud designs with the logo are also included.

If you have an example mpd file showing the rubber band / rope issue you could send, that would help me.

With regard to Bevel, given that a suitable Bevel shader is not yet available, and may be some time away, would the next best solution be to use normal maps something like this ?

[BertVanRaemdonck]

Very nice! It fixes everything very nicely visually. An extra feature might be to set the crease value of those edges as well to something in the 0.90s, so that users can use the bevel modifier on parts without having to specify all of the sharp edges first. This way, it's possible to "generate" high definition parts in Blender that still look realistic in closeup, and not so jagged as they often do. This would be an indispensable feature for rendering photorealistic micro creations, and doesn't seem like a lot of work to implement!

Related to the edges, when you select a mesh and go into edit mode for the very first time, a seemingly random collection of verts/edges/faces has been selected by default. Setting the initial selection to zero wouldn't make much difference, but it would be prettier ;)

Also, when I use the "select sharp edges" function on a mesh, it doesn't select all of the edges that look sharp. Not sure how this works. Furthermore, when I push the "sharp" button for edges in the shading/UV window when in editing mode, even when nothing is selected, suddenly all of the edges that look sharp get the blue color. Again, nothing very important, but it is a bit strange.

The file with the strange rope consisting of separate cylinders can be found here.

I'm not too sure about that method with the normal maps. Baking generally takes a long time, so it would undo all of the hard work you put into making the importer efficient. I still think generating a normal map in the node editor is the best way, by blurring the sharp edges of the normal map. But of course, nothing's stopping you to try out the baking method!

PS: I really like how you're naming the different releases! I'm already wondering what you will do after Znap...

[TobyLobster]

@BertVanRaemdonck Good feedback - thanks! I've just released v1.0.4, which has a new Bevel edges option - which adds a Bevel modifier as you suggest - looks very nice. I think the Edit Mode selection should be better now, and should show the sharp edges OK too. The "select sharp edges" menu seems to have it's own idea about what is sharp. To select all the actual sharp edges, select one of them, then Select Similar (Shift G) > Sharpness. The rope issue is fixed too. Enjoy :-)

[BertVanRaemdonck]

Sounds promising, and that picture on the releases page looks almost photorealistic! It could be improved further by applying a subdivision surface modifier to the mesh. Since you defined the weight of the edges, the results should come out okay. The result is then that you won't see the polygonal contours of the barrel any more, for example, completely getting rid of the numerical vibe. (This is actually what I was trying to say in my previous comment, but I accidentally typed the name of the wrong modifier...)

I wish I could test it, but I'm under the impression something went wrong with the release. I don't see any new commits here in the repo, on the releases page it says it's on the same commit as the previous release, and when I download the files, the version file still says its v1.0.3.

[TobyLobster]

Oops - my mistake. v1.0.5 now released to fix this.

[TobyLobster]

@BertVanRaemdonck The subdivision surface modifier works nicely on the barrel btw, thanks for that thought, but there are issues with seams on some other parts, so I'm hesitant to apply it automatically for everything.

[BertVanRaemdonck]

You're perfectly right about that subsurf of course.

I encountered a new issue in the meantime, and it's about the orientation of the stud logos. There are parts (I discovered it on bow brick 41762) with mirrored logos. Others have logos with different orientations on the same part (e.g. round brick 6143, logically). Instead of literally copying the transformation matrix of the stud part for the logo, it would be better to eliminate mirror operations from it (through the determinant of the matrix, I believe) and to disregard the rotation around the local y-axis of the logo.

Also, I've recently learned that the Fresnel node actually isn't as physically accurate as I believed. This video describes a fix. This shouldn't be too difficult to implement, and would get rid of the sometimes just a tad too reflective surfaces, I think.

[TobyLobster]

I have released a new version that fixes the logo reflection issue. The unwanted logo rotation is a trickier issue. The correct rotation is not always well defined by the ldraw model. For instance bricks 3001 and 429 are similar in shape to each other, but they have different logo orientations in real life. These bricks are modelled correctly, so they both work fine as is. But if the importer tried to remove local rotations, this would make one or both incorrect. The best fix would be to fix the original offending ldraw models so the studs pointed the correct way. A messier fix would be to have a hardcoded list of parts whose logos need rotating to point in a particular orientation.

I've also added node groups with proper PBR nodes as described in the video.

[BertVanRaemdonck]

The issue with the rotating logo's isn't so much that their absolute rotation might not be accurate: not many people will notice it when the logo's are facing the wrong side of the brick. However, what is noticeable, is when multiple logo's on the same brick face different direction. So you keep the transformation of one of the logo's, and use the same one for all of the bricks that have the same orientation except for the rotation about the y axis. In the case of 6143 it would be very hard to fix the .dat file because the studs used aren't rotational symmetric...

Also, I was thinking it might be fun to do something with toon shading to approach a look like in the building instructions. However, I played with some settings, but I never got it to work quite right: somehow a lot of the edge lines were interrupted in places, and I can't seem to find anything about that issue online. Manually indicating the edges that should be included in the freestyle seems to solve the issue, but of course that would take ages. So I was wondering if it were possible to give users the option to import the model either with realistic or toon materials. The toon option would then already install the tool shader everywhere, mark the edges to be used in the freestyle and maybe already enable the freestyle checkbox etc. Just a thought for an extra feature for a program that can hardly be improved!

[codinguncut]

Hi TobyLobsters,

this is absolute awesome. I have tried every possible library for the past 2 days and this is the first one that creates viable normals. I am actually using blender to convert LDraw items to other formats (i.e. Wavefront OBJ) and then to OpenGL and this library has been an absolute life-saver.

Thank you! Johannes

[TobyLobster]

@BertVanRaemdonck Rotating the logos consistently is not easy. Certainly there are some real parts with logos at different angles e.g. both vertically and horizontally aligned. Perhaps I could isolate just the standard horizontally aligned logos and align them in the manner you suggest? Then maybe separately align just the vertical logos with each other? This doesn't cater for studs at say 45 degrees to the vertical though. Needs thought, and the implementation is not straightforward. Otherwise, yes, fixing 6143 would need a separate stud definition for each orientation of the stud I guess. Toon shading looks fun, but I'm afraid I don't have time to investigate this atm. If you come up with a toon solution, let me know.

[TobyLobster]

@codinguncut Thanks Johannes, good luck with the project.

[BertVanRaemdonck]

Tommy Styrvoky pointed out to me that there is an issue with the "Link Parts" option. It works fine while it is selected, but when it is deselected, there is no difference: when you go into edit mode and edit a part, the change goes for all of the instances of the part. I've looked into the code and can't really tell what's wrong. If all else fails, the solution can be as simple as selecting everything and making each object a single user of its data.

As for the Toon Shader, this is just the moment I stop having free time. But maybe a find a gap and the right documentation (it isn't looking very promising...), so who knows? It would definitely be fun to make some kind of animated instructions!

[TobyLobster]

@BertVanRaemdonck I have just released a new version that fixes the Linked Parts issue and adds support for LeoCAD group names.

[TobyLobster]

@BertVanRaemdonck Ok, so I found some time to emulate the look of the Lego instruction manuals. It uses Blender's Freestyle to render the lines. Note the black outlines for most parts, but white outlines for black parts. It creates/uses two render targets composited together, one layer for the solid parts, one for the transparent parts.

Released in the 'Ideas' release.

[BertVanRaemdonck]

I had a simple idea recently to increase the realism of the renders with just a couple of lines of code. I don't think it's worth the trouble of creating a pull request, so I'll just make my suggestion here:

Have you noticed that not all logos on studs "stick out" equally? Sometimes, there's a stark relief while at other times it's very hard to see the logo because it is so faint. It doesn't depend on which part or which color it is, and the variation just seems kind of random, like you can see on the picture.

It's just consistent throughout a single part. An easy way to implement this variation would be to assign each part a random value that either determines the vertical scale or vertical offset of the logos - whichever one looks best. The result would still be that parts with the same ID will have the same value, but still, it's some variation to start with that could add some nice realistic randomness to the renders.

The best way to implement this would be to have the logos done with a bump map and just couple the random output of an object info node to the strength to have variation between parts with the same geometry. But that would require some serious extra coding for a small feature.