Lasse D

Studio 2.0 (or rather, "Part Designer") is able to export to LDraw. Unfortunately Bricklink has chosen to roll out their own standard for texture mapping, rather than following the official spec. I do 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. When creating a new part in Part Designer, you can choose either "Minifig", "Decorated Part" or "Create Part From Scratch". I will start with "Decorated Parts" and take the two other options later. Update! The new location for Studio2LDraw is https://brickhub.org/i/apps/studio2ldraw.htm Using the checker.png by Nils from the LDraw forum and some basic gradient picture, I have created test files for most of the decorated parts currently available from Part Designer The Studio "LDraw" File Format - Findings Exporting to LDraw from the Part Designer will result in .dat files containing something along the lines of: 0 FILE studio_test_1_8_checker.dat 0 Brick 1 x 8 checker 0 Name: studio_test_1_8_checker.dat 0 Author: 0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt 0 BFC CERTIFY CCW 0 PE_TEX_PATH -1 0 PE_TEX_INFO iVBORw0KGgoAAAAN(...)uQmCC 1 16 0.0000 -24.0000 0.0000 1.0000 0.0000 0.0000 0.0000 1.0000 0.0000 0.0000 0.0000 1.0000 s/3008s01.dat 3 16 -80.000 -24.000 -10.000 -80.000 0.000 -10.000 80.000 0.000 -10.000 0.045 0.955 0.045 0.045 0.955 0.045 3 16 -80.000 -24.000 -10.000 80.000 0.000 -10.000 80.000 -24.000 -10.000 0.045 0.955 0.955 0.045 0.955 0.955 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 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. Computing Projections 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. I have found the following heuristic works for most of the supported parts (see exceptions in the section below): 1) Take the minimal axis-aligned 3D bounding box of all the points of the triangles. Call this box B. Let Bx, By, and Bz be its length along the X, Y and Z-axes, respectively. 2) Expand B by 10% in each direction to account for the border introduced to the picture. 3) If 2*By < Bx and 2*By < Bz, then assume the projection should be performed on an XZ plane. Otherwise, project onto an XY plane. 4) No matter the projection, choose the points for the planar projection defined in the LDraw specification to be corners from B. Exceptions: 2x4 Brick and 2x2x2 Slope For the parts "Brick 2 x 4" and "Slope 2 x 2 x 2" you can choose two pictures for decorating the front and back of the part. 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. For the 2x2x2 slope, the two pictures also get merged into a single picture, however, this time they are side-by-side: Front picture on the left and rear picture on the right. For both exceptions, I have had to introduce "magical numbers" in order to get a proper alignment of projections. Please see the source code here for how to compute projections in JavaScript for the buildinginstructions.js project. Non-Standard Alignment of Sub-Part and Geometries Please take a look at the line for the sub part: 1 16 0.0000 -24.0000 0.0000 1.0000 0.0000 0.0000 0.0000 1.0000 0.0000 0.0000 0.0000 1.0000 s/3008s01.dat The positioning is off: Normally you would place the sub part at (0, 0, 0), but here it is at (0, 24, 0). This position has to be translated so that the sub part is at (0, 0, 0) in order for the custom part to appear correctly. You have to subtract the position of the sub part from all the positions of the triangles as well. 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. Please tell me if you have other observations. My plan for now is to continue with Minifigs.

Ray tracing is as far as I know not efficient enough to de done real-time. I am looking into shaders that can show transparent elements realistically. Right now I have not found anything from Blender that can help with this - the nearest I can come is volumetric rendering, but that requires pre-computation of textures for volumes, which is not something I have by hand. Once (if ever) I have found a good solution, I can publish the results, but right now I am hitting a wall with this.

We are some who are working on real time renders that are open source, but it will take a massive amount of effort to make something that looks as good as those ray tracing algorithms from Blender et. al. that studio uses.

I would like to join. As this is the week of Le Mans, I am not sure about staying there Wednesday, but the days before then should be alright.

While I'm a bit disturbed by the severed head in the terrarium, it seems quite nicely balanced with colors. The part selection, however, does not bring out the same awe as the Diner and many other modulars before it.

Yeah 5571 Black Cat is much larger than 1:25. However. I believe others on Rebrickable have made trailers for it with instructions.

As I see it, I have to place all of my videos as private and ask users to use some kind of overlay platform if they want to add comments (I saw GAB made such a platform some time ago, but apparently it is being used mainly for political extremism. I hope to find a more children-friendly platform) It is a shame that they wanted to profit on illegally mining information from minors. And again they seem to do everything in their power to take the "you" out of "youtube".

That's odd. Let's take it from the top: Permo said paper does not "radiate" and does not "attack the eyes like a monitor does". I found this statement odd, looked it up and found only CRT's "radiate", while LCD and LED screens did not. This is where my source comes into the picture, and my response was the rather blunt: "Paper actually does "attack" eyes in the same way as a digital screen since it reflects light...". I made the assumption that when Permo said "attack the eyes", they meant in the sense that the eye would take damage due to this attack and I based my searching on this. All the results I could find regarding damage on eyes from screens were as I described in my previous post. This is also where we seem to be at odds and you seem to hinge on the "attack" angle rather than the "damage" angle which is what I am referring to. In hindsight I should not have used the word "attack" given how you have locked onto it, but I wanted to use the word from Permo. Now you have given me a reference that finds how blue light can cause damage. I thank you for this and find it interesting. Clearly LED screens shine blue light directly given how they are constructed, but what about LCD and paper? How much blue light do they emit that has a negative impact on eyes? From your first response to my initial comment my guess is that reflective light from LCD screens is worse than from paper, so if you have a source on that as well, then this would be interesting to read up on.

That's very interesting. I looked into this topic before I made my post and followed the citations provided here: https://www.news-medical.net/health/Does-looking-at-a-computer-damage-your-eyes.aspx The problems stated there all seem to be caused by sustained close-up visual activity, which would not be relevant here as you would be performing frequent changes in focus as you change from screen to the physical pieces. This was what I used to support my argument that with modern screens your eyes would not receive a worse impact than when using paper. Do you have citations behind how paper affects the eyes differently, and how that can have a negative impact? I know you say it is technical, but I am willing to learn.

I would prefer to have the choice of purchasing paper instructions as add-ons to sets. The environmental impact of printing all these millions of almost-single-use booklets cannot be trivialized. I'm not happy with the arguments put forth in this thread, so I will try to counter some of them: This is a false equivalence. The electronic devices are not single-use. Displaying building instructions will be just one among many, many other usages of these devices. Just because the individual does not have many building instructions does not mean that the environmental impact is trivial. I would like to see the numbers: What is the environmental impact of one instructions booklet vs. the power it takes for a device to display the same instructions. Funny. Whenever my power has been out, I have only been able to build digitally since my phone and laptop run on batteries - my lights for seeing the bricks do not... Digital copies can easily be copied - easier than paper, so I would say the argument is reversed. Unless your screen is a CRT, there is no "radiation" of concern. Paper actually does "attack" eyes in the same way as a digital screen since it reflects light... I fail to see the argument that refresh rates has on this argument.

Thanks. You are not the only one to make that comment, and I will try to make the windscreen on the convertible transparent as it does not need side windows. I have now made a video of the model showing how it is constructed. The building instructions introduce a new feature: Choose your own color. And unlike on other websites, the color change here is free :) The free building instructions are here: https://brickhub.org/i/492

Thanks for the feedback. I am thinking of how I can show a Targa version with the interior visible. This will require a different approach to the windscreen. But first. The engine: The middle section had to be rebuilt to make way for the engine. The changes have primarily been on the rear window surrounds, where it works best with the section built upside-down. Unfortunately this is a goodbye to the grilles, but square holes are also fairly true to the original A new detail has also been added to the top with the rear view camera.

This is my take on the new C8 Corvette which was released recently. It is the first mid-engined Corvette and is going to retail for less than $60k in the US. With the performance numbers it is putting out, it might become one of the greatest disruptions we have seen in recent times. Characteristic for this model are the side scoops which you can option with contrasting colors (I have had a lot of fun with the online configurator), the mid-engined proportions and hard angles, such as at the engine cover, rear wing, nose and headlights. The most challenging part of the model was to get the nose and headlights right. This is how I started out: The headlights on the real car have LEG strips on the sides, but I was simply unable to fit them into the space available. The nose was also a bit too tall and I wanted to include the winglets in the side intakes. It took me a day, but I was able to make the updates to the front: Other changes from this version to the one you see in the top include new side intakes, updated windscreen and other minor improvements. Now. Would you like to see a fake engine and transparent engine cover?

And that is really the best outcome we could hope for: ldconfig.ldr will not be restricted by legacy software and all programs (at least in the AIOI) will work as expected.

I don't think the use case you mention is acceptable and I can understand the frustration, so I have raised the concern in the thread. While I was the one to initially mention the incompatibility with MLCad, I chose to stay out of the discussion and simply updated all of my own software which also broke due to this change. In fact, I used 10000+ to indicate 'edge colors', so this was a particularly annoying change

Those 10000+ colors do not work with MLCad and it was a deliberate decision. See this thread: https://forums.ldraw.org/thread-23434-page-7.html I am also still using MLCad, but we are encouraged to switch.

Yeah the tipper module should be run at low speed for optimal throughput. 1 or 2 works the best with M and L motors, while XL motors can run at 3-5 on a train regulator. The tipping bird module is brand new and trust me. If I made a video, you would chuckle at the failure of its current state.

My pump module has turned out to be quite popular as a "behind the scenes" kind of module, being used in some wonderful GBC modules where the pump is just a cog in the machine. I have made some improvements to the module which makes it easier on the motors, more interesting to look at and with a better balancing of the anti-jamming mechanism: My dipping bird module is currently a complete failure. I will give it another go, though.

The level of detail in this model is astonishing! Very, very well done! It is also interesting to see you have modeled the drivetrain rather than the exhaust. It is often the other way around. Bonus points for all the half-stud offsetting and for modeling the triangles of the rear suspension.

Thanks. It means a lot.

Thanks for the reminder. I have just added the Fürth and Nürnberg skylines from the Eurobricks event to the list of MOCs as well - no reason for not bringing them along.

Much later than the end of April, and the instructions are now complete for all three cars including stickers: Car #7: https://brickhub.org/i/428 Car #8: https://brickhub.org/i/353 And car #9: https://brickhub.org/i/429 Please tell me if you have any issues with the building instructions. I understand older versions of Internet Explorer and Netscape don't render the pages correctly. I am looking into this issue. The stickers are made using normal paper and wood glue. See the video in the first post for more information.

Creator | 30571 Pelican Download file: https://brickhub.org/i/data/447/30571 - Pelican.mpd Building instructions: https://brickhub.org/i/447 Built and rendered using Studio 2.0 Step rotations and OMR compliance using brickhub.org

It depends on the complexity of your structure, but by computing the placements of parts in the LDraw format might be doable. This is what I did for the large ring in this GBC module: I computed the placements of the inner 1x2 bricks and used sub models with the 1x2 bricks placed at (0,0,0) to model the ring even through other parts (including the Technic pins) are used in it. The instructions can be seen here: https://brickhub.org/i/425 The math for computing the placements is fairly basic, but will of course be slightly different when using 1x2 plates and round 1x1 plates to achieve a similar shape in smaller scale.

Dippy Bird? That gives me a great idea for another module!