Lego Image Converter

[Pascale]

Ido not care for the reason for Bricklink to go this way. It personally took me almost a month to implement it, so I fully understand if they wanted to choose something less complex. Instead I would like to dedicate this thread to converting between the two formats. In order to do this, we have to understand the format that Studio exports to. If you want to jump directly to a live demo, then please click "3D" on the page I have set up here.

Please note that I have inserted the "!LICENSE" line in order to ensure that the files may be shared and used. The commands "PE_TEX_PATH" and "PE_TEX_INFO" are proprietary from Studio. I have not yet found a "PE_TEX_PATH" command that does not say "-1", so let's ignore it for now. The other command has a base64 encoded picture as the argument.

The geometry lines have one sub part (in this case "s/3008s01.dat") and 2 or more triangle lines. I have yet to see any file being generated with quads, lines or any other content after the encoded picture.

The base64-encoded picture is not simply the picture you upload to Part Designer. It will be processed. I have found that the encoded picture is scaled up and has been given a transparent border. I do not know why the border is added - perhaps someone can give me some insight here.

In the LDraw specification you have to specify how to project a texture onto underlying geometry. Unfortunately the exported LDraw files from Studio do not contain any other information than what I have stated above. You thus have to take each part one-by-one and compute your own LDraw TEXMAP projections.

For the 2x4 brick, the two pictures get merged into a single picture - the front picture on top and the back picture below. There will be 4 triangles in the LDraw file - the two first for the front side, and the other for the back side.

By following the observations above, I have been able to create the converter from Studio LDraw to standard LDraw as seen in the source code here for. This is what powers the 3D viewer here. As you can see, there are still some precision issues - most noticeably on the 1 x 8 tile where the "10% rule" doesn't seem to work perfectly. Another issue is that I cull textured surfaces on transparent parts, while Studio does not.

What is the end goal here? Are you looking to use the Studio Part Designer to generate stickers or decorate parts in LDraw vs using LDPatternCreator? (I get the appeal, LDPC is great at what it does but its is a steep learning curve and I dont want to redraw the decals I have made for printing as a vector only to have to draw them again...as a vector)

Probably -1 just means embedded, 0 would be disabled and 1 point to an externally linked image in the future. The rest is just kinda baffling news. I've never bothered using textured parts in either program and for me as a 3D artist this seems pretty lo-fi. Has the thought of proper UV-mapping even ever crossed anyone's mind?

The end goal is to be able to convert between LDraw files as exported by Part Designer and official LDraw files. There are a lot of members in my LUG who make trains using Studio 2.0 and they are perplexed by their models not working in LDView, and other LDraw-compatible software. These are typically people who do not want to deal with vector graphics, but still want logos on their models.

The LDraw file format specifies neither normals, UV's (apart from for texture mapping) nor actual meshes, so you will find a lot of functionality missing if you are used to work with Blender and similar tools.

Do you have an example where Studio UV mapping is significantly different from cylindrical (or even front/back planar) projections? I couldn't find one (and I think that Part Designer uses plain planar anyway)

Oh wonderful. I will have to play with it! Can i ask if it might be possible to have it generate just the "sticker"? I have many instructions I make that would benefit greatly from showing when to place the stickers

Hi @supertruper1988. If you want to create a sticker that is placed after the parts that it sticks to, then you should not use parts with textures, as that will leave big gaps in your parts until the stickers are placed. Instead, I recommend making the sticker as a part based on box5.dat, and a quad with the texture on the quad. This will give you stickers similarly to what you see in this model.

Stickers are supposed to be placed over normal, gap-less parts. @supertruper1988, You could get images images from Lasse tool and create stickers with @roland online tool (but that works only for flat stickers)

I guess what I am asking is for a tool to make a sticker from art I have made in illustrator. I have tried the SVG2DAT and it interprets the bounding box as a color and I cannot make it go away. There is also LD Pattern Creator but I find it very hard to use after having used image editing software for years and the thought of redrawing art that I have already drawn once at 1:1 size is very frustrating.

There is also img4dat that converts a bitmap to LDraw pattern. Works pretty well if the source image is clean (such as illustrator image exported to bitmap). Seems awkward to convert vector to bitmap to kind of vector, but when it works... See -23242-post-31099.html#pid31099 .The tool itself is a bit rough on edges, but you can get used to it

Ever wanted to turn the scans from quixel into a Lego building? Well now its possible. I created this little converter with the geometrie nodes and it can take any scan and turn it into Legos.

rferre38403840 1.63 MB

Basicly the Geometrie nodes take the imported mesh and turn it into voxels. I did this by creating a 3 dimentional grid and then using the geometrie proximity node to remove every vertice that is outside of the original mesh. On each vertex i am now able to place a lego brick with the instance on points node. I did this once for the normal Lego bricks and again with a three times more dense grid on the z axis to get the result for the thinner Lego plates.

00213241292 133 KB

00113241292 211 KB

After i got the voxel grids i seperated the vertices from those grids based on the normal of the original shape. Each normal value got a different type of Lego piece. Intersecting pieces also needed to be removed and i added a little bit of a random value to the plates and bricks by replacing some plates with round ones, those grill like Lego tiles or round ones with holes. Afterwards i transfered the vertex color of the original shape to the Lego piece instances and thats it.

00413241292 229 KB

Basicly it takes the original mesh and puts it into a grid. With the geometry proximty node i turn the mesh into a voxel grid. That i do once for the big bricks and then for the small plates, which have one third of the height of the normal bricks. Based on the normal of the original mesh i then distriputed the different lego pieces across the grid and everywhere those bricks where placed i remove the base bricks. To phrase it simple if there is a normal of a certain value place this 1x2 slope here and remove the bricks that it intersects with.

currently everything is based on thhe normals. the hollow studs are just random but are placed random at points where tiles and flat plates where suposed to be too keep it a little bit organized. Also right now i dont use the official lego colors because i didnt manage to reduce the color of the shader into the oficcial colors.

When i create the voxel version of the base mesh it is not a filled up version just a hull. Because of the Geometry proximity node it only leaves those vertices that are near the surface of the base mesh so inner vertices will be deleted as well.

A lot was posted all over the internet about capturing HDMI output and whether CamLink is worth its $120 price tag since there are $20 alternatives out there. Trying to decide for myself I googled around and all I found were discussions on image/video quality, like this very informative video from Tech Audit TV:

Camlink takes the HDMI in the format (resolution, pixel data depth etc.) in which the camera delivers it, repackages it (as in: adds necessary control bits, maybe rearranges the bit order for image pixel data, but else does not touch the video), and sends it down the USB3.0 lane. The only processing you may select is to allow for some color subsampling (you actually have no choice but to do so for 4k sources, as 4k at 4:4:4 exceeds even the USB3.0 bandwidth by a margin). To sum it up: Camlink basically does not process the image data, at most it reshuffles the bit order on pixel level and, if instructed to, drops some of the data on color to make bitrate fit through USB3.0.

3a8082e126