Bojan Pavsic

@nemo So that we're clear. What we're talking here is an external app... LDD will (most certainly) never support this. I know what does all this take from programming perspective as i'm a software developer for 20 years.

@nemo and what happens if let's say person A makes a part #12345 and sends that around with his lxf. Then comes person B that doesn't know about person A and makes another version of part #12345 (which might or even might not be the same part - as we all know the differences between BL/LDD/MLCAD part names...). Will you do that by hand? Maybe... What about those people that don't know how to decompress the file. Or where to copy the new files... In a matter of weeks, TLG would get tons of e-mail "LDD doesn't work anymore", forums would be flooded with people not knowing what to do... (ok, maybe not that much but still... get the point?) For this to work, there would have to be a webpage/webservice/something that would have all the new parts, all of their versions (approved by administrators) and a button downloader. When this is done, then there's the problem with custom parts. Ok, let's say only original Lego parts are allowed. Then someone comes along who would like his custom minifig. Then another who'd like Brickarms (or whatever that Lego weapons maker/seller is) parts... To get a custom part into LDD is the least of the problems and i just wrote down only a couple of them.

1. Better groups. - unhide group - move groups from one parent group, to another (possible now with selecting the group, creating a subgroup at destination, then deleting the parent group). - naming a group, disabling group preview (way faster than all the unnecessary rendering). 2. Hinges - the ability to fix a hinge (so it's non-moveable): fixed value, min, max - IK (inverse kinematics) algorithms (move the endpoint, automaticly calculates the angles of hinges) 3. Camera - add the ability to add set min and max distance from the camera (could be helpful to "see" through walls - min distance and to make rendering faster on bigger files - max distance) 4. File support - run multiple instances, "AllowMultipleLDDInstances" from settings doesn't work or i'm not using it right or add the ability to open multiple files at once (i think the first option is easier, but the second is better - memory usage) - LDD projects that would include multiple LXF files (like 3 modular buildings, each in it's own file, displayed together on a street). That would help a lot on bigger projects. 5. Customization - custom keybindings / mousebindings

Well, if you want to insert a new item and you don't rebuild the db.lif, you need to inject the data into the original one and change quite some other bytes in there (which represent the sizes of the chunks in there) and you need to update the lifs TOC... It's easy if you know how the lifs are made. If you don't want to change everything, you have to find a piece with the same number of polygons and edges and replace it, but that's not really the point, is it... The bigger problem with .g files is that the lifs were the same since version 3.x (don't know how they were before), but the .g files changed through versions... Dunno if they'll keep the files the same, now that they added the edge data. I hope they will :)

@pauldk Even if you'd find a software to extract LIF files, you wouldn't be able to create a new part that easy. First you'd need to find the exact scale, so your new parts wouldn't stand out. Then you'd need to create the 3D graphic mesh, the 3D collision mesh, the shading data and the connection data. Afterwards you'd need to pack it all back together. And trust me... that's not easy.

@nemo What about adding new data files without changing the original files?

I put together a simple test setup: two 1x85 studs long "plates", rotation point at one end. The other end before rotation: and after a rotation by 0,002 degrees: The angle still says 0 degrees, but it's actually not. Internally it has 0,002 degrees, but it displays 0. If you retype it to 0, it wont change, because the edit component wont see the difference, so you need to change it to 1 degree (or any other value) and back to 0. This small angle is hardly visible even at this distance from the rotation point, so if you try it with 10 or 20 studs, there will be no visible difference, but mathematicly and in the internal data, there is one. That's why i usually calculate all my angles and enter with as many possible decimals (8-10), which is not really necessary for smaller projects, but in bigger one, it all adds up... If you'd make a setup with like 1000 studs, you'd see the difference between even smaller angles. More pics at http://www.brickshelf.com/cgi-bin/gallery.cgi?f=483646 (when it becomes public)

Hm, from what i found out, LDD works with more then 2 decimals... It only displays/rounds to 2 of them. So you can write in the angle field like 12,0045 and it will display 12. Then you enter 12 without the decimals and LDD will visibly make the small change in angle (0,0045). The stored values (in .lif and .lxf) are single floats anyways, which means about 7-8 precision digits (and since angles go up to 180, that's 3 digits in front of the decimal point and 4-5 behind it on the largest angles).

What are the lengths of the white bricks (sides)? Are they fixed or can they be adjusted by a stud or something? What is the ratio between the bottom middle brick and the side bricks connected to it (1:1 as in your picture from the building instruction)? What's the ratio between the front part and the back part and so on... I need to have some bounds to give it to the computer to calculate things - which things are fixed, which have some bounds (min/max or ratio compared to some other edge)... btw, the length that you wrote (18 studs) is actually 17 studs from the studs of one brick to the studs of the other. 18 studs apart are the outer edges of those 2 bricks,

As Ralph_S already pointed out... Yea, it's not gonna work. Btw, some time ago i made a little program for exact and not so exact pythagorean triplets in Lego... Maybe you will find it useful. www.pavsic.com/kocke.si/LegoTools.exe p.s.: It's in Slovene - Button Izračunaj means Calculate, - Eps is the error that you allow 0 = exact (only whole numbers ~ pythagorean triplets), 0.01 = 1%, etc... - Min / Max are the bounds for the values a & b (sides of the triangle) - You can click into the list on the left side to see the whole triangle - Please don't ask for translation or changes cause i don't have the sources anymore (HDD broke down) and i'm really not into writing a new one... a least not for now.

This is just a matter of simple math... Let's start with angle 5: the triangle has 3 edges, 10, 10 and 6 in length. You can use the Pythagorean theorem only in right triangles, which means we have to split the triangle (if you make the red line in your picture all the way up to the angle 5). You get a right triangle with the edges 10, 3 and sqrt(10*10 - 3 * 3) which is not important right now... You can calculate the angle 5: sin(a5 / 2) = 3 / 10 => a5 = 2 * arcsin(3/10) = 34,9152 degrees Angle 1 and 4 are the same, so are angles 2 and 3. Now we're moving on the next triangle. Let's make a line that goes through a1 and a4. That makes a similar triangle as is the one we used in the calculation of angle 5: x / 6 = 24 / 10 => x = 14,4 (that's the width of the whole thing) if we take only half of it (to get a right triangle), the length of the is 7,2 If we make a perpendicular line to this last line we did through A2 (or A3, whichever side were're looking at, it's the same...), we get a triangle A1, A2 and the 90 degrees angle in the middle... the triangle parts of the angles A1 and A2 are: sin (a2_1) = ((7,2 - 3) / 6) => a2_1 = 44,427, a2 = a3 = 134,427 degrees the only thing left is a1 / a4, which is made out of 2 parts... a1_1 = 90 - a2_1 = 45,573 degrees a1_2 = 90 - a5/2 = 72,5424 a1 = a4 = 118,1154 degrees There's the question of the angle of the hinge on the inside brick which is 90 - a5/2 = 72,5424 So all together (in a hinge in LDD angle of 0 degrees means actualy fully open angle / 180 degrees / which means you need to use 180 - angle values): a1 = a4 = 118,1154 degrees => 61,8846 a2 = a3 = 134,427 degrees => 45,573 a5 = 34,9152 degrees => 145,0848 ax = 72,5424 degrees => 107,4576

It's a pretty old topic, but i'll share my experiment anyways (it's from the beginning of 2011). The difference from the idea that fred67 proposed is, that i took a working 9V motor. That way the same bogey was used as a motor and as power pickup. Here's the video i made to show how it works. I took a working 9V motor apart and disconnected the motor from the wheels. Then i cut a PF extension cable (50cm) in half and made a hole into the motor where usually the PF motors have the wire. I put a diode bridge in there (i didn't use MOS-FET bridge, because i'm not that good with electronics and the voltage drop is not that important anyways, since you can drive everything with higher voltage anyways). I put some capacitors in there too, just to have a small "power reserve" for the IR receiver. When i took the IR receiver apart, i found out a very nice thing. The output lines 9V/GND are connected to the input lines 9V/GND. That means the receiver can be powered from the output and the input doesn't need to be connected to anything (as seen on the video). Inside the bogey i connected the wheels to the diode bridge, then to the capacitors and then to the 9V/GND. The C1/C2 lines where connected to the motor. (so 1 PF cable to get the power and to drive the motor). Basicly it's something that Helmantel and Mark Bellis already wrote.

The meshes for all parts in LDD are in db.lif. They're written as a list of vertices and normals. There's a list of indices to create triangles. Some meshes have texture coordinates too. I did get the data out of the 3.x database, didn't really check the 4.x database (but it has some additional info about edges and shading).

Being a 15+ years in software developing myself, i learned much about multithreading, 3D graphics etc. on the way. First of all, porting a singlethread to a multithread is not really easy. It requires lots of additional work to synchronize the threads. Maybe if only some parts (like calculations, where most of the data is only read and not written) would be multithreaded (so the main thread would split into multiple threads, each would calculate a part of the result data, which would then be merged after). A full blown native multithreaded software would need to be rewritten from scratch, which TLG most certainly wont do. As you correctly found out, moving lots of parts really slows down, since the count of calculations goes up really fast. For example (without any optimization): if you have like 200 bricks with 1000 free connection points and you move 1 brick with like 10 connection points, that's about 10.000 checks (1000 x 10). On the other hand if you move 10 bricks with like 100 connection points, that's 100.000 checks (10x more -> 10x slower). With a "normal" refresh rate of like 25fps (and that's pretty low), that's 2.5 million checks (again... without optimization, with fictional numbers). And this is just for connection points. Then there's the geometry overlaps, which of each of the bricks has A LOT (thou probably the first check is overlapping the border boxes first, which is quite fast). One of the solutions could be diving into OpenCL (which utilizes GPUs, CPUs and all other compatible processing units in the computer), but i'm 99.9% sure that they wont choose that path, since half of the LDD users don't even have "draw outlines" compatible computers.

Very nice, has a lot more details then mine. Well, tbh, i was more focusing on the technic features (as i am more in the technic department) then on the looks, but next time, i'll put much more focus on that too. It was sort of a "turn off thinking between programming" thing, just to relax a bit :) At first wasn't really thinking of publishing it at all...

Very nice! I haven't seen it. But it really is powerful. I used an M motor for lifting because i couldn't squeeze 2 XLs in there with everything else in there, so mine only lifts a couple of pallets. I made it more for "show" so to say and was using in on 3 local LUG exhibitions, mainly to move the pallets around from a truck down to the table and back. Sometimes i even put some candy on them and drove them to the edge of the table so the kids watching could take them :)

Yes, i know about the third motor. The thing is that i started to create a CH-53 Sea Stallion (which has 6 bladed rotor and 2 engines). Since i only used a couple of pictures found on google by searching "CH-53", it found pictures of CH-53E too. I liked the tail of the E version (the titled one), so i made that one (at that time i didn't really know that there's multiple versions of CH-53). Basicly the model is CH-53 (without the E) but with the "E" tail. I'm not really into aircraft and military stuff (that's why i mixed up the Sea and Super stallion...), but a friend wanted to convert the 7738 (Coast Guard heli) into a special ops version and wanted to repaint the back section and all those parts from the OOB into black (since they're only in orange). I'm more "purist" type builder, so i created this one (after his advice to look at some CH-53 photos).

Well, there's a small flaw thou :D The height that it can lift is only double the range of the LA (since i used a pulley system with a chain), which in practice isn't that much...

Hehe, i just did that for everyone to see, how the thing works. I did use a little trick thou :D The rear rotor is not actually connected to the main one in LDD. Since the height of the long axle leading to the front rotor is a little bit offset (1/2 of a plate), i couldn't connect the two axles with an axle connector (if you check the LDD file, you'll see what i mean). In real bricks, that wouldn't be a bit problem thou, that's why i didn't bother to fix it. I took the screenshot so that one of the main rotor blades covers that part, so it isn't seen :) Btw, all part colors are checked with LDD manager, so it's buildable in this color. (only the minifigs aren't... but they're in there just for show anyways). When i'll have some time, i'll recolor it to make an LBG/DBG/Black version to see how it'd look.

This is a model of a Toyota Series 8 forklift. It's modeled with about 1 stud accuracy to the real one (at least compared to the pictures on the internet. There are 3 M-motors and one XL-motor with two PF IR receivers. The XL-motor is used for driving, the M-motors are used for steering, tilting and raising the forks. And here's the design model in LDD (which was used to make the brick version). http://www.brickshelf.com/gallery/bpavsic/MyMOCs/Forklift/vilicar.lxf ps: It's a bit dusty, since it was on my shelf for like half year :D

Hehe, yea, that's where LDD steps in and punches you in the face (illegal methods).

@Brickdoctor Snot is really easy... The only problem that i found using LDD is minor (usually unnoticed) offsets and after half model, you find out, that something doesn't go together. The other thing is HingeAlign... Never use it, only Hinge and i always calculate the angles with a calculator & paper. Btw, that helicopter is nothing... I can't imagine making my WIP supercar for a local LUG competition without LDD.

This is a model of a navy helicopter. I tried to make it as close to the real model as possible buy using SNOT extensively. The color scheme is black, it's a kinda special ops version, not a navy one (which is gray). Here's some pictures: The gray plates on the rotor are the old technic plates , but they're not in LDD, so i used 2 studs shorter plates. The main reason for those plates is that they are rounded so they can go further to the center of the rotor. There's a small hatch on each side at the back, which enables to open the ramp: Troopers inside: The troopers can be removed... ... which leaves quite some place for the small battery box (train one), IR receiver and 2x3 soldiers. Some functionalities: - M-motor, that runs both rotors: - insides with the minifigs: - retractable wheels, which we can raise/drop with the Z12 gear at the bottom back. A small half Z12 is missing on the main wheels since i had some problems with the axle rotation. The weight on the front wheel should block the rear wheels from raising (at least in theory). It also rotates a bit more then the rear ones to fully retract (that's why there's a 20:12 ratio in there): Here's the LDD file, thoroughly grouped: http://www.brickshelf.com/gallery/bpavsic/MyMOCs/CH-53E/ch53.lxf

The problem that you have is not with the axles or 2L connector, it's with the 1/2 bush or the X part. You can easily create the square without the bushes (without any scaffolding), but can't add them afterwards, because the gap between the 2L connector and the base of the X part is just a bit too narrow. It is possible to create it exactly like you want (with scaffolding), but after you save & re-open the file, the X part will be gone. Similar thing happens when you select the parts and clone them. LDD clones them without some parts, either the X part or the bush, but never both together. I'm not sure if the parts are under stress when physicaly created like that (so illegal build) or it's just that LDD part glitch. I'm more leaning towards the first one (illegal build), since if you look at the parts carefully in LDD, the bush cuts into the X piece. I even tried to rotate the horizontal axles by 45 degress (to better fit the curvature of the X part), with no go.

Yes, you're right, it's the 9V track. Basicly all straight tracks are badly modeled, since they don't allow connections on the bottom side. I modeled new ones from plates (8x2, 8x1, 2x1), 1x1 tiles with clip and hard hoses 16L when i was constructing my train station (i had to put them on a baseplate).