Hi,

upgrading the AIOI to 64 Bit required a stripped-down 32 Bit installer for the remnant 32 Bit progs such as MLCad, MPDCenter or LSynth. Here it is:

http://www.holly-wood.it/tmp/LDraw_AIOI_...bit_v1.exe

* The installer comes without the parts library but reads your Windows environment variable (set with the 64 Bit AIOI) and checks for the library.
* If no library can be found it asks for the path and preforms another check.
* If still no library can be found it will exit the installer.
* Sets all paths as usual
* No catalogue or showcase at the end

I would grateful if you could test it. I'm most interested in the initial check for the LDraw Parts Library. Just rename "3004.dat" to something else. Please note that some dialogues haven't been translated yet.

w.

I'm trying to build a library of game-ready parts for use in video games, and would like a library of low-poly bricks to fall back on for bricks I have not yet converted by hand. I've dug around and tried a few methods so far, but all have failed to work.

LdrDat2Obj: Processes 1,466 dats out of the 14,038 in ldraw's parts directory, and then exits silently with no error or log. the last brick it appears to process is 22385p050.dat It processes the parts in an order I can't decipher, so skipping this last brick and moving on isn't possible.

LdrDat2Obj2: no apparent batch process

Toby Nelson/TobyLobster's blender importer: seems to work well, but only allows one .dat to import at a time - that's not workable with 14,000 parts.

Matthew Morrison's blender importer: Crashes every time I try to import a .dat file. I posted more details about the crash in his thread: https://forums.ldraw.org/thread-24153.html

LDView: no apparent batch process

Stud.IO: no way I can see to create a file that contains each brick once.

If I could get the ldraw parts into any conventional 3D model format I would be able to batch convert the results into something game engines can use, including obj, fbx, stl, dae, and -probably- usd.

HI guys

My problem:
I add a submodel in a model, which I want to remove (much) later.
Buffer Exchange therefore falls flat.
In former (MLCad and Lpub) times, this was very simple.
I created a group in MLCad (0 MLCAD BTG...) and removed it later with "0 LPUB REMOVE GROUP" ...).
It seems that this does not work in LPUB3D (2.4.3) anymore.
Does anyone have an idea?


Johann

The following was posted by Willy Tschager in the Standards Board forum. In my opinion, that was not the right place for it, so I am starting a thread here.

(2021-08-13, 11:18)Willy Tschager Wrote: Guys,

in response to this post:

https://forums.ldraw.org/thread-24732.html

the majority of the SteerCo is in favour to add helper parts to the library but before a final vote we would like you to define a standard for these parts such as:

Naming convention
Category
Edges Yes/No on 2D helpers
Edges Yes/No on 3D helpers

The general idea would be to add these to the main library as the separate Alias and Physical parts library hasn't worked very well. In addition these parts shouldn't go through the PT for certification but be usable in all editors. Any input from your side is welcome.

Some example of helpers can be found here:

http://www.holly-wood.it/ldraw/helper-en.html

w.

Hi, I was creating instructions with LPub3D when I encountered this bug.

The torus subpart of https://www.ldraw.org/parts/official-par...rtid=49098 isn't rendered.

I investigate a bit and notice there's no consistency in this bug. Even here on LDraw.org.
Coming next are screenshots of this part as viewed by several softwares :

in the part tracker :
- this one is a 200% view of the PT's thumbnails (maybe generated with LDView ?)


- this one is from the PT's 3D viewer, part is complete, yay !

- in LDView, note that the tree info module shows the primitive and knows that the quads should be rendered (red highlight) :

- in MLCad (the old man knows how do deal with parts) :

- LDCad  (BFC is working here) :


- LPub3D 200% PLI display unsing LDView (since LDView doesn't render the part correctly, it's obvious this one isn't correct) :

- LPub3D with the native rendering engine (works fine) :


- Last but not least, I inlined the torus primitive and "ta-da !" :

LDView finaly rendered the file nicely.

I can't remember when, but it's a bypass I allready used this year and that we discussed here. I used (maybe badly) the search option of the forum and didn't find the thread.

EDIT : The problem still exists in LPub3D

Greetings.

I've just stumbled across what I think is a small bug in LDCad. Since there's a 1.7 version in the works, now's as good a time as any to have found it!

For parts that are far away from the origin (more than 1000LDU), if I open the Reference/selection properties box to put in new coordinates, the numbers/s are displayed with commas as thousands separators. But when I hit Accept to dismiss that box, that comma gets interpreted as a decimal point, and my part moves much closer to the origin - from x=1020 (say) to x=1.02.
Have I described that well enough? Feel free to ask any clarifying questions.

I'm using LDCad 1.6d (LNX64). I don't think I've done anything special with my system localisation settings.

Apologies if this is a known bug, I couldn't find anything on the website or the release notes.

Thanks again for a great product.

Owen.

Hi

Can anyone please make this part for me?

2431pb534
As soon as possible please

Hi

Can anyone please make this part for me?
2431pb580
As soon as possible please

I'm a non-English speaking person, so I may not be able to speak well.
I'll do my best.

I'm going to use LDraw to create an animation and upload it to YouTube.

In this case, should I hide the LEGO logo on the brick studs?

My buddy Dave @ BrickNerd asked me to request the following two parts:

• 41927 - Human Tool Dots Bag Tag Cube - https://www.bricklink.com/v2/catalog/cat...ge?P=69182
  
• 73767 - Human Tool Dots Bag Tag Ring - https://www.bricklink.com/v2/catalog/cat...ge?P=73767