Hi Guys,

I recently got into making lego animations and wanted to make an animation using Finn from adventure time. I'm mainly looking for the hat as I was able to recreate the rest of his minifig easily. I searched through LDraw, digital bricks, and Brick Link Studios but was unable to find the hat. I know the model exists as I've seen a few images of the 3d model but haven't been able to find the actual model. I would appreciate any help in finding the hat!

Thanks!
Gabin Marlin!

Attached Files

Thumbnail(s)
   

  250x250p.jpeg (Size: 4.99 KB / Downloads: 45)
  250x250p.png (Size: 15.42 KB / Downloads: 45)

Just noticed that there is a strange situation with Krana Vu. For some reason, one of it's subfiles, the half of the part one, is in the official library. Meanwhile model itself is not. Probably it should be reviewed, and if anything is okay certified? I don't think it's okay to have a subfile be floating in the official part library without the part itself

Subfile: https://www.ldraw.org/parts/official-par...s/42042s01
Part: https://www.ldraw.org/cgi-bin/ptdetail.c.../42042.dat

Like discussed elsewhere, I'm considering starting a public github repository for the LDCad shadow library.

For this I would like some feedback about how to do this best.

I really could use some help deciding about the following things:

- License type
I'm currently using "Free for non commercial use" in all the .dat files, I've decided to change that to something more permissive like "CC BY-SA 4.0" but if someone has an alternative suggestion I'm open to that too.
The problem with this is I will need to contact the people whom contributed shadow info over the years (they are all members of the forum though )
But worst-case scenario I'll just leave those files out (just about 400 .dat's in total or so)

- Author / change tracking.
Currently I only have a single Author line, but I figure a public repo needs some more information.
I really don't want a part tracker level of tracking, but I guess there should be some rules header wise.


I already made a private repository to do some tests with, so once a license is chosen it will be ready to go.

I also want to add some tools to LDCad to help format / maintain shadow info intended to be donated to the repo.


Any ideas/suggestions about how to get this repo/project started are welcome.

Hey,

this release introduces a complex and powerful feature:
The !LPE CONST meta command.
It allows you to use constants in almost any line type and replace them with a real value when needed.
However, the constants will be removed from a line when the line is modified from another source that is not the constant itself.
When you change a value of a constant afterwards, you need to click manually on the "Update/compile linked subfile data" button.

  icon32_subcompile.png (Size: 1.72 KB / Downloads: 75)
You can see the calculated value in the warnings section of the text editor.

Syntax:

• ...use the "!LPE CONST" meta command to define re-usable constants in parts and subparts.
  
• ...use calculated expressions for constants, too.
  
• ...quick-fix/replace constants with the text editor.
  
• ...combine "!LPE CONST" with "!LPE CSG" meta commands (but not with !TEXMAP commands, yet).
  

1. Download and extract LDPartEditor_win32_x64.zip
   
2. Run LDPartEditor-1.8.60.msi
   
3. Start LDPartEditor from the start menu
   

1. Download and extract LDPartEditor_linux_x64.zip
   
2. Install ldparteditor_1.8.60-1_amd64.deb
   
3. Start LDPartEditor from the menu or via launcher
   

1. Download and extract LDPartEditor_mac_x64.zip
   
2. Mount LDPartEditor-1.8.60.dmg
   
3. Drag LDPartEditor.app to the Applications folder
   
4. Copy ldparteditor.sh to your home folder
       4a. Open a Terminal.app and run ./ldparteditor.sh
       4b. Or open a Terminal.app and run /Applications/LDPartEditor.app/Contents/MacOS/LDPartEditor
   

• OpenGL 2.1 compatible Graphics Card
  
• Operating System (64-bit): Windows [7 or newer], Linux [e.g. Ubuntu Linux >=14.4], Mac OS X [>=10.6]
  
• CPU: Multicore-Processor e.g. Intel Core 2 Duo or AMD Athlon II (>2.0Ghz)
  
• RAM: 4GB
  
• Video-Memory: 1 GB
  
• Free Disk Space: 100 MB
  

• Operating System (64bit): Windows 7,8,10, Linux [e.g. Ubuntu Linux >=14.4], Mac OS X [>=10.6]
  
• OpenGL 3.3 compatible Graphics Card
  
• CPU: Multicore-Processor with 4 cores (or more)
  
• RAM: >4 GB
  
• Video-Memory: >1 GB
  
• Free Disk Space: 512 MB
  
• For a faster start, LDPartEditor and the LDraw™ library should be installed on an SSD.
  

Hi all,

inspired and motivated by this thread, I tried to port the collision detection algorithm of LDInspector to LDCad / Lua. Thanks to Roland and his massive support I have a first version running that seems to not crash immediately.

In the attached example TestMini there are three collisions:
   

Running the collision detection coloring macro, it marks all colliding parts correctly:
   

Having some parts in sub-models like in TextMiniSub, the macro marks the parts in the sub-models recursively which may lead to spurious false-collisions. I'm working on some kind of work-around by (a) adding collision indicators instead of coloring the parts or (b) creating a new flat file which then allows individual coloring of parts.
   

If you are interested in the still-very-beta-proof-of-concept-script, it is attached as txt file - just rename to lua and copy it do LDCad-1-7-Alpha-2/scripts/default/global/ directory. You will need LDCad 1.7 Alpha 2 or later - thanks again to Roland for providing all needed functions. Please do not run the collision detection with too many parts as the time will increase squared to the number of parts. Running this small example with 15 parts already requires 32ms on may machine and the default maximum macro runtime is 250 ms which leads to a maximum of about 40 parts without prolonging the macro execution time.

Attached Files

  TestMini.ldr (Size: 883 bytes / Downloads: 5)
  TestMiniSub.ldr (Size: 686 bytes / Downloads: 4)
  colldet.txt (Size: 16.89 KB / Downloads: 17)

I'm starting to feel like Official Model Repository isn't descriptive enough. "Official" is ambiguous. It could mean these are models that are officially approved by LDraw instead of models of official LEGO sets. I thought maybe LDraw Set Database but LSD is a bad acronym. I'd love to use LEGO somewhere in the name but I think TLG's lawyers would object. Maybe LDraw Official Set Repository/Database?

Thoughts?

This is another one of those where it doesn't look like there's enough information to solve it, but there's clearly only one solution, so there must be!

Consider the case of a pole leaning inside a barrel, such that it rests against both sides and the bottom, forming the three points A, C, and E. These three points and the inside corners of the barrel form two similar right triangles, ABC and CDE.
   
From the known part dimensions, we get the hypotenuse (8) of the smaller triangle and one leg (36) of the larger triangle. We also know that an additional leg from each triangle, BC and CD, add up to 26.

We want to find the missing lengths AC, BC, CD and DE, and by extension, the congruent acute angles at A and C. That will give us the rotation points and angle for the bar. Can we do it?

   

OMR Compliant: Yes
Stickers: No

Attached Files

  6991 - Monorail Transport Base.mpd (Size: 576.65 KB / Downloads: 19)

As opposite to strictly technical topics I start this one as kind of "an evening talk in a pub" or "brainstorming" if you wish: I'm really interested in your ideas and opinions.

I start with a question: do you know the difference between old geographic maps (==pictures) and modern ones, like the openstreetmap project? Modern map is considered being a list of discrete objects and each such object is defined in the text: a path joining points etc. See? Very similar idea to our ldraw format! But there is an important addition, comparing to ldraw: they have very well defined system of metainformation: object types, their capabilities... And the result is: such a map can not only be rendered to a picture form (with any graphical style) but it can be used for completely different tasks. One such task is well known for everybody, nowadays: a car navigation. But even a simple search in the map is a task - de facto it is a database query.

What about thinking more about ldraw format in this way? Isn't there another space then part pictures where ldraw could help, if having proper metadata? Ideally the metadata we already have or could get easily from already existing information in ldraw files.

For example: every time I work on shadow/snapping information for LDCAD ideas of this kind come into my mind: part snapping is one example of non-pictural ldraw usage. What more can we use it for? What about queries? "Hey, my editor, show me gears matching this one", "show me a list of parts with a clip" etc. I slightly remember old SR3D editor did some magic in this way to animate models automatically (bending a hinge moved the attached parts of the model, technic drivetrain worked automatically etc.) but it's so long I do not remember details.

What do YOU think? Do you have any ideas?

I am pretty sure the answer is "no, no, not ever, no thanks, that is a terrible idea" BUT I wanted to ask if there is support for variables in the LDraw file format? 

It would probably take support of all the editors and renders which is probably causing someone's eyebrows to make odd shapes as even type this out  

I am someone who enjoys the "make it once and for all use cases", so the pragmatic nature of making a lot of similar parts that have one or two changes for each iteration feels quite bothersome.