I really have my problems in idealisation of this pattern like requested http://www.ldraw.org/cgi-bin/ptdetail.cg...004p07.dat.

Here is what I came along with the picture provided by Steffen.

Is this really better than the previous?

Attached Files

  icecream2.dat (Size: 31.61 KB / Downloads: 3)

The recently uploaded Mini Snake brought the idea about preventing (auto-)connectivity issues of LDraw related software. The part contains an simple underside stud, but none of the existing stud primitives can be used without a lot of tweaking of the original part shape (see comment about stud4o.dat).
The basic idea is to "convert" the 4-4cylc to a new stud primitive, and then use it instead of the cylc. This step is not forced by the LDraw Standard, but the more i think about it, the more i'm convinced that this last step is worth to be done. If it becomes official, i doubt it will ever be done.
I attached the prototype of that new underside stud. As i have no idea how to name and describe it, help me please to complete it.

Attached Files

  new_stud.dat (Size: 326 bytes / Downloads: 0)

Greetings,

I've just recently written 4 different translators for both LDRAW (.dat) and LDD (.g) files that can write to SolidWorks, Inventor, DXF and LDRAW. This was the result of some issues with the previous DAT2DXF translator I was running into with some bad .dat files and other requests that I have seen on these forums with regards to wanting SolidWorks and Inventor translation. I've attached a video showing how these small applications work.

Below are the links to setup files for each application. Unfortunately, I do not yet know how to create a trusted certificate for my ClickOnce Installer, so you may get a warning when downloading. The link will install the application to your Start Menu in SolidPerformance -> BrickWorks -> Application Name.

There are some requirements as of now, though because I am using ClickOnce, I could possibly rollout an update to support older version of the limitation listed below.

Does not support Windows XP and older.
Requires Microsoft .NET 4.5 (this causes the above limitation and is something I can most likely roll back to .NET 3.5 or 4)
The SolidWorks translator currently only supports SolidWorks 2014 and newer (though I could roll this back to around SolidWorks 2010 possibly, I should have the older SolidWorks.Interop files somewhere, which are forward, but not backwards compatible).
The Inventor translator currently only supports Autodesk Inventor 2014 also, for the same reasons. It will be much harder for me to get the older interop files for this.

For both the SolidWorks and Inventor translators, you can try to run them with older versions, but I have not checked all the api calls to see which versions of their respective software they were implemented. So if I used an API call that was implemented in say, 2013, it would require that as a minimum version.

Finally, here are the links

SolidWorks Brick Builder
Inventor Brick Builder
DXF Brick Builder
LDRAW Brick Builder

The following file on the PT has different connection points compared by the LDD parts.
http://www.ldraw.org/cgi-bin/ptdetail.cg...s/x156.dat
Please have a look into the appended mpd file, so you can see what I am talking about.
As Tim already wrote - we are free to change. As i do not own this part, I can not decide what is correct or not.

Attached Files

  x156-42114.mpd (Size: 78.76 KB / Downloads: 3)

This morning I looked through the files that are on hold on the PT.

My personal opinion on releasing parts is - good enough! - because of the following reasons.
1) Very seldom a part is visible in a picture in a close-up. So tiny errors are not visible.
2) If the parts are on the PT they are used - so they can't be that bad.
3) If I need a part and it is not in the library I am disappointed. If that occure too often i lost interest.

What is good enough!
1) Connectivity portions needs to be on the right place.
2) The origin is placed according our agreements.
3) The parts shape follows the visual appearance of the real part.

What should not be a reason not to cert?
1) T-Junction on flat surfaces.
2) Overlapping flat surfaces on opaque parts
3) Missing of some condlines that do not affect the overall appearance.

So do not wonder if I cert a part where you say - so many errors in the file.

I hope lot of you can follow my thoughts and on second iteration on the PT we can make the parts perfect.

Hi again,

I was wondering if anyone had made any progress with this door piece - see Philo's comment on this page:
http://www.ldraw.org/cgi-bin/ptdetail.cg.../2924b.dat

Thanks

Reuben

Hi again,

I'm looking for this piece in LDraw? It's a relatively new piece, featured in sets 6864, 7600, 6863, 2507, 2505, 7199 and 9449.

Here's a picture of the part:
http://www.ebay.co.uk/itm/Lego-Large-Tra...0854961270

Thanks in advance

Reuben

Hi folks,

I noticed that Batman's cape is now available in Lego Digital Designer (LDD). Please refer to the LXF file for set 6864 here:
http://www.brickshelf.com/gallery/ADHO16..._chase.lxf

I was wondering if someone could use the 3D capture technique to turn this into a LDraw part (using 3dvia Printscreen?)

Thanks

Reuben

I’m making a model in MLCad (3.40 if that would matter) and I need a rubber belt in it.

It is just a simple use: a Technic bush 1/2 (#4365a) placed on an old 9V motor (#2838c01) and connected with a belt to Technic wedge belt wheel (#4185) directly above it. And I find it really difficult to get the position and size right.

I found here thread titled “Rubber bands” in which most important (for me) was another link to page “Modeling rubber belts”. The page indeed helped by providing radius of the Technic parts so now at least I knew what to enter for “R1” and “R2” in “Rubber Belt Generator”.

But how should I know what the dimensions (“X” and “Y”) are? Luckily X is 0 in my case. But the other? How do I know on which height an axle/hole is within Technic brick? How do I know on which height motor axle is placed? I guess that to the difference between centers of those axles I should also add both radius to have the height?

Then after solving that how do I know on which position to place that rubber belt so that it aligns well with the Technic parts?

Is there any software to just point two parts (likely limited to some small set of supported parts) and have a rubber belt connecting them generated?

What I find disturbing is that this is entered not as a “Part” but “Belt”. Is it something specific for MLCad? Will other software be able to “understand” that?

Are there any “predefined” values (in particular for rubber belt thickness) of the “standard” LEGO rubber belts like K3 and so on?

I just can't get this to work quite right. I like to use LDD as a starting point for just playing around with new model ideas. It's quick and easy to just throw bricks in place. But then I want to take that into LDCad and break down the one single model into a collection of submodels in a .mpd file.

I can create new submodels in LDCad. I then cut and paste the selection of bricks I want from the existing single model into the empty submodel I just created, making sure to remove position and rotation information as I do so. I'll then take the submodels and "recombine" them into a new main model, this time made of the submodels instead of individual bricks. I can close and reopen the file at this point and everything is fine.

However, if I then go in and add Steps to the submodels I run into a problem. It's not apparent right away. I can create the steps and page through them and it looks fine. But if I close and reopen the file I'll find bricks have moved to different locations. Some are even part of different submodels. I can't seem to figure out what's causing them to move like that. It's definitely a result of adding steps to the submodels.

I can replicate this with any model I make, whether I start in LDD or even make the whole thing in LDCad. I can split a single model into submodels. But as soon as I add Steps to the submodels, the position of random bricks gets messed up upon reopening the file.