Hi all,

I noticed that part 32531 has been moved to 32531a, but is 90 degrees turned pertaining to 32531a and b.

I think we need a correction there, because I now have an old model that has a few of these 90 degrees turned... ;-)


  32531.png (Size: 67.58 KB / Downloads: 36)

Jaco

Yes, I'm thinking it's time!

Every pattern I create (which admittedly isn't that many yet) seems to involve passing through the SVG format at some point. But we're still missing a tool for converting SVG graphics directly to LDraw, and I know there have been a couple started already. (Img4Dat has planned SVG functionality, SvgToDat I believe handles basic primitives only, etc.)

My proposal is to start with the single task of converting SVG paths to vertices that can be imported, say, into LDPE at a reasonable resolution for mesh generation. And since SVG paths are really just a combination of cartesian coordinates (rel or abs) and Bezier control points, all that's really needed is a way to take the cubic Bezier math and make a polyline out of that—perhaps with an option between points evenly spaced, or according to curvature (so that tighter curves get more points). Best of all, that information is already stored in a nice, human-readable xml format within the svg file.

The use case for this arose when working on this part. I was able to lift those vectors directly from the official instruction booklet, put them into Inkscape, export a PNG and trace that manually in LDPE. But how much faster if I could have taken the paths themselves (or the xml data from inside the svg file) and drop them into a tool in LDPE, maybe adjust the precision a little bit, and instantly have the vertices I need to triangulate the pattern!

I'm thinking—in fact, I'm sure—that the math part of this has already been worked out many times over, and all that's missing is to code it in a way that's specific to LDraw. If we only focus on converting paths (which, again, is really just converting Bézier curves), then it think it becomes much easier to tackle than trying to incorporate the entire SVG spec into an LDraw tool, because a lot of that is probably stuff we can do more or less by hand.

So who's up for the challenge, and how can I help? I never learned to code, though I do understand programming languages generally. I just don't know a git from a commit from a pull request. ;-) And I'm not fluent in math, but I can figure out problems on an ad hoc basis, or at least look up the answers!

Guys,

I know we have put a lot of effort into the new 3817b/3816b - Minifig Legs by obsoeting the old 3817/3816 but the new geometry with the sloped backside is clearly wrong:

   

Any ideas how to correct the part without the need to reverse the whole conversion?

w.

The PT currently uses the forums to authenticate users. While this currently works well enough, but with the next gen PT in development, we have an opportunity to discuss what we would like to do going forward.

I see 2 viable options:

- Keep the current system with the forums being the controlling account
Pros: Familiarity. Easier to PM authors with questions.
Cons: At the mercy of the developers of the forums to not break things. Rewrites needed if we decide to change software.

- The PT and the forum accounts separate
Pros: Thing only break if we break them. Having an API to tie into is easier.
Cons: More things to sign into. More difficult to tie stuff back to the forums (like the Parts Author badges)

Now that I've pondered and written the above, I think I'm in favor of keeping the forums and PT tied together.

I've needed this part for a very long time now but still cant figure it out. I've created a file in PS and even got it over into meca bricks but I still don't know how to get it over to Stud.io. I'm hoping someone here might be able to help finish it up? Let me know what I can send you to help! Appreciate the help!

I have a PNG of the file of the decal I created in PS available. 
The photoshop file available of course too. (I used the mecabricks template) The part looks pretty good in Mecabricks
An exported version as a 3D object from mecabricks.

Heres the BL link to the part... https://www.bricklink.com/v2/catalog/cat...6#T=C&C=86

I hope thats helpful.

Attached Files

Thumbnail(s)
   

Hello! :-)

There is two tiger mask this and that:

https://www.bricklink.com/v2/catalog/cat...D#T=C&C=68

https://www.bricklink.com/v2/catalog/cat...D#T=C&C=68

And I think this is the basic mask:

http://www.digital-bricks.de/en/index.ph...part=15083

http://www.digital-bricks.de/en/index.ph...part=15084

Can you put together these two mask?

Thank you very much! :-)

The topic that is bugging me a bit lately, is what should be really put in priority - precise geometry, or cutting down on that a bit, to have model be shaded way more nicely? Example of that would be the cut cylinder on the 50921. It features cylinder cut by the other one. In the current version, it looks like this:
   
The thin triangles lead to a pretty unpleasant shading, which essentially keeps edges very clear
   

It can be fixed by merging some of the vertices, but that results in cylinder not being really circular anymore:
       

I am not sure which approach is favorable. First result has pretty precise shaping, but loses in appearance. Second one is more fine in how it looks, and precision loss, while present, is not that dramatic

Is it possible to get a rotation matrix for a circular primitive, given a simple (I guess quadratic) Bézier curve?

All of our curved prims are circles or conical, and I’ve read that any affine transformation of a conic section will result in another conic section. If the simple Bézier curves are likewise conic (which may be a wrong assumption), then theoretically they can all be represented by a 2D shear matrix, right?

I found a bug in the release script of the PT. If the first lines after the header are TEXMAP lines, the !HISTORY line for the release after those TEXMAP metas. I've currently found 6 affected parts in the Official Library:

parts/36069ap01.dat
parts/36069bp01.dat
parts/98088p01.dat
parts/98088p02.dat
parts/98088p03.dat
parts/98088p04.dat


If you find any more, let me know.

Note: This does not affect any visible aspects of the part. The only problem is that the header is out of compliance with the Header Spec.

I'll track the down the source of the bug and recycle the affected parts for the 2022-06 release.

Hi, I'm using this part in a MOC that I want to digitize in LDraw format...
https://rebrickable.com/parts/3660pr0005...lot-print/
BrickLink 3660pb003 • BrickOwl 259299 • LDraw 3660pr0005 • LEGO 3660pr0005

Does anyone feel like tackling this? I don't know the procedure for getting printed parts added. It has an LDraw number, but nothing in the official or unofficial parts library that I can find.

Thanks
Bill