LDCad 1.3 Beta 1 (win+linux)

[Roland Melkert]

Time flies, just three months after 1.2 I'm proud to release version 1.3

It's major new features are:

• Basic part snapping on (growing) subset of parts
  
• Spring generation
  
• Closed loop paths (e.g. rubber band)
  
• Part ghosting
  

I'm very proud on the part snapping but I feel it isn't just good enough so I kept it disabled by default for now. You can enable it at anytime using the compass or shift+p

Please note snapping works only on a selected group of parts. This because extra information is needed for it to work. I've input this information for over 700 .dat files. this results in full information for all parts in the following bin groups:

• The 'Plain bricks', 'Pat. bricks' and 'normal plates' under sorted/bricks
  
• The 'Axles', 'Beams and liftarms', 'Bricks', 'Connectors and pins', 'Gears', 'Plates', 'Pneumatic', 'Shocks' groups under sorted/technic
  
• It also includes the power function template related parts.
  

You can download the latest version as per usual from the main site

I've also created a youtube clip which demonstrates most new features.


And finally some screenshots featuring the new example models:





Hope you all like the new version, if you have any comments / questions let me know.

[Michael Horvath]

Are the new camera modes coming any time soon?

[Roland Melkert]

It's on the todo for beta 2, but I'm not completely sure yet about it's shape and/or form. It won't be locking options for the trackball though, I've tried that and did not like it.

[Michael Horvath]

What do you mean by 'trackball'?

[Roland Melkert]

The current camera system uses a trackball. I wanted to add optional locking so it behaves more like e.g. LDD but I did not like how that turned out.

So I'm planning to add a second dedicated (LDD like) camera system so the user can choose to use that one instead of the trackball. I think this is more user friendly then stacks of sub options which could act weird in certain combinations/circumstances (e.g. locking y while y isn't pointing vertical)

[Michael Horvath]

I don't remember how the LDD camera works. I've only used it once or twice.

I suppose it could become difficult to determine where the camera should 'snap' to when there is gimbal lock.

[Ignacio Fernandez Galvan]

Great thing the grouping (it was in 1.2, but I'm a bit late). But the groups are not saved, or am I doing something wrong? I guess it's not trivial to have a syntax that works with non-contiguous (in the model file) parts.

[Ignacio Fernandez Galvan]

And regarding the closed paths (in particular Technic chains, like "Technic chain tread 17 (closed)"), is it possible to change the phase (rotate the whole chain forward/backward)? There seems to be a slight misalignment here too, which is more noticeable if the radius is made smaller (try two points with radius 30, 80 units apart), the parts in the curve don't match exactly (see image), and I don't mean the first/last (which would require an exact total length), could it be that the length is computed along the curve, rather than in a straight line?

[Roland Melkert]

It's a rounding thing internally it uses a 0.51ldu resolution to approximate the curve. So unless the donor part exactly lines up with a step it will be slightly off the analog curve.

Usually it isn't really that of a problem but the combination of the relative small link parts, a strong curve (radius<40) and the fact links have overlap makes it visible.

I'll see if things improve if increase the internal resolution.

edit, forgot about your other question.

You can rotate the links on the curve by rotating the first (circle) path point.

edit2: i just checked t's 1ldu stepping.

[Roland Melkert]

No grouping isn't stored yet I need to come up with a new meta for that.

The main problem I'm having with that is that in LDCad groups can exist out of parts from multiple files (trough nesting). So I'm going to need some sort of global unique identifier.

There are some automatic groups though, those will be present without saving (e.g. the path endings).

[Roland Melkert]

I've played around with the resolution it won't matter even if I a 100 times higher.

could it be that the length is computed along the curve, rather than in a straight line?

You are right, the problem lies in the fact i calculate the length along the curve (16ldu for the links) while placement visually needs that 16ldu in a straight line, so the sharper the angle the bigger the offset no matter the internal resolution.

I think i need to invent an additional placement kind (similar to dynamic) to solve this for the perfectionists (which includes myself )

Thanks for pointing it out.

[Ignacio Fernandez Galvan]

I'm glad you are a perfectionist, that means there's a chance to have this fixed

You may want to have a look at this file, and compare the manually-created chain and the LDCad-generated one. Note, too, that the "radius" is not the distance from the center to the top in the manual chain, because no component in placed exactly at the vertical. In fact, the radius is not any nice number, it must be such that 16 LDU define an angle of 30 degrees (12 pieces per full circle), which gives (16/2)/sin(30/2) = 30.9096... if I'm not mistaken. It would be cool to have some kind of automatic calculator that gets the radius correct, given the number of teeth and donor size

[Roland Melkert]

I'll try to improve it (probably using a new skin option), but I'm not sure it will be in Beta 2.

As for the calc tool, it's funny because I just started working on a generic selection info feature.

The first version shows angle and length information for the items in the current selection, cur dev version:



You could use those numbers for placement of things like shocks and universal axle joints.

Also I was just wondering if there could be more useful info to show the user, and your suggestion is right in that ally

[Ignacio Fernandez Galvan]

As for the calc tool, it's funny because I just started working on a generic selection info feature.

[...]

Also I was just wondering if there could be more useful info to show the user, and your suggestion is right in that ally

In my imagination, it would not be just a "calc" feature, or show info. Once you have a path with a fixed step size (16 in this case) associated to a circle path point, you'd (optionally) change the circle's radius not in 0.5 LDU steps (or whatever), but in integer number of donors, the formula is simple: for n donors of size s the radius is (s/2)*sin(180/n).

Of course, this is an idea that I find useful for this particular case, I don't know if it's useful enough in other cases to deserve a real implementation. But, speaking of a calc tool, a triangle solver would be handy. And for showing info, maybe displaying the transformation matrix as angles, when possible.

[Ignacio Fernandez Galvan]

Just another thing. In the flexible hose template (flexHose.ldr), is it possible to assign different colors to the two components of the start/end caps (752 and 755)? 755 is actually part of the rubber piece, while 752 is hard plastic and can be detached.

[Roland Melkert]

Yes, the end of that path are using the auto groups I wrote about above. They use auto grouping to make placement easier.

You can ungroup them (ctrl+shift+g), like any other normal group to manipulate the loose parts. Afterwards you can reapply the auto groups (in the group menu) or restore it manually (ctrl+g).

[Roland Melkert]

I'm thinking the simplist solution would be to allow the user to set the internal resolution, setting it to 16 in the case of this chain should fix every thing.

Here's a how it looks while using a quick hack (everything uses the 16ldu grid )



Bit offtopic, one perfectionist to another. How would you go on solving placement of multple universal axle joints. I'm having troubles with it even with the new info feature in my beta 2 deb build:



It's ok from a distance now, but the axle also needs to 'roll' along it own length, any idea on how to make that easier?

[Ignacio Fernandez Galvan]

I'm thinking the simplist solution would be to allow the user to set the internal resolution, setting it to 16 in the case of this chain should fix every thing.

That's probably better, as you'd have to account for the actual chain path not being tangent to the ideal circle, but to the real polygon. Would the user still need to compute the correct radius? And does the "phase" of the second circle change when you rotate the first one?

Bit offtopic, one perfectionist to another. How would you go on solving placement of multple universal axle joints. I'm having troubles with it even with the new info feature in my beta 2 deb build:

It's ok from a distance now, but the axle also needs to 'roll' along it own length, any idea on how to make that easier?

Not at the moment, I'm afraid. I think all the cases I've dealt with were solvable in a plane, which makes it relatively easy. But a mechanics simulator would rock

[Ignacio Fernandez Galvan]

I would need flexible templates for rigid axles (under strain) and for free pneumatic hoses (without the thicker end). Are this available or planned? Should I try to create them myself?

[Roland Melkert]

Would the user still need to compute the correct radius? And does the "phase" of the second circle change when you rotate the first one?

I'm not sure what you mean, the stepping is used to describe the path around all points (bezier and circle a like). Internally the point info is converted to a array of positions and the distance between them is always the grid stepping. So when you set that distance equal to the skin size, it will map perfectly cause the curve section length is equal to the the link (straight) length.

It doesn't matter how many circles (and mixed in beziers) you add to the path the links will line up perfectly except the last one in regards to the first one. To get that one correct the user still needs to play with the circle radius's and bezier ctrl points to get it to close fit exact. I can't provide those radius's because it depends on other points and the things you want the chain to go around etc.

But a mechanics simulator would rock

It's purely placement for now, but the major feature I want to introduce with 1.4 will be animation. At that point simulating the mechanics will become possible using scripts (I hope).

[Roland Melkert]

I might add a template for the pneu hose without the ends. But you can easily make that one your self, just place a normal pneumatic hose and remove it's caps afterwards. Don't forget to ungroup them first.

A bendable plain axle shouldn't be to hard to make yourself ether. You could use (a copy of) the existing flex system hose template and replace it's skin donors after placement.

If you want certain custom made template's to appear in the bin, create files for them and place them at a location that is part of the 'user templates locations' list dialog (prefs/ldraw)

[Ignacio Fernandez Galvan]

I might add a template for the pneu hose without the ends. But you can easily make that one your self, just place a normal pneumatic hose and remove it's caps afterwards. Don't forget to ungroup them first.

That's what I did for the moment, but without the end cap there is no... well, cap. There's no surface or edge lines at the end of the hose. I'd need a replacement for 165.dat, a non-stretched hose end.

A bendable plain axle shouldn't be to hard to make yourself ether. You could use (a copy of) the existing flex system hose template and replace it's skin donors after placement.

I'll try, sure, I just didn't want to waste my time in case you already had it planned

[Roland Melkert]

That's what I did for the moment, but without the end cap there is no... well, cap. There's no surface or edge lines at the end of the hose. I'd need a replacement for 165.dat, a non-stretched hose end.

If you have a suitable part handy you could use those as caps or extra skin sections (like the flex hose).

A suitable part only needs the base cylinder(s) and a donut surface. You could create a donor part for it (see the donors folder of LDCad for examples)

[Ignacio Fernandez Galvan]

I'm not sure what you mean, the stepping is used to describe the path around all points (bezier and circle a like). Internally the point info is converted to a array of positions and the distance between them is always the grid stepping. So when you set that distance equal to the skin size, it will map perfectly cause the curve section length is equal to the the link (straight) length.

Maybe a picture helps. Suppose you have a setup with two wheels, such that there are three links per full turn (just to exaggerate the differences). The initial circle is 1, and the initial link is "a" (then "b", "c"...).

Will the chain be created as is the top case? This is more realistic (for chains, at least), but more difficult to compute, I guess. It would also need more care from the user, to set the relative rotation of the different circles correctly (rotate circle 2 only and the chain would break, but a different distance between the circles would need different rotation).

Or will it be done as in the bottom case, by trying to follow the "ideal" path in discrete steps?

[Roland Melkert]

I see,

All paths (circle, bezier and combo's alike) use the bottom method.

It will first calculate points along the circle, belt, bezier parts etc using varying of (high) precision. Then later all points in the full path are converted/reduced to the equal stepping mentioned before using interpolation where needed.

The equal stepping is needed so I can easily calculate how to spread the skin sections etc.

[Ignacio Fernandez Galvan]

A suitable part only needs the base cylinder(s) and a donut surface. You could create a donor part for it (see the donors folder of LDCad for examples)

I just realized that the hose has no inner surface either. So I took the liberty to:

a) add an inner surface to the hose segment donor.
b) create a donor for the unattached hose end.
c) create a template for a hose with unattached ends.

Here are the files. Feel free to modify/rename/include them in future releases.

[Roland Melkert]

Thanks,

The pneuhose donor doesn't have internals cause I figured you never see it and it will bloat the fallback code considerable. But it might be useful if you want to use transparent hoses.

you could also use the full ones for e.g. 5 segments at the ends and the slim ones for the middle if you want the endings to be realistic in cases where the hose doesn't connect to something.

[Jason Smith]

Wow, impressive update. Again the Linux support is so much appreciated.

Thank You

[Ignacio Fernandez Galvan]

A bendable plain axle shouldn't be to hard to make yourself ether. You could use (a copy of) the existing flex system hose template and replace it's skin donors after placement.

And here is a template for a bendable rigid axle. It's scaled and positioned to be a direct replacement of the plain 8-axle (3707).

Again, modify at wish if you think it's worth including in the official LDCad.

EDIT: Maybe it's better like this, with the end pieces truly rigid, since the axle is probably inserted somewhere.

EDIT 2: Can I convince LDCad to include the needed unofficial donor parts in the mpd file?

[Ignacio Fernandez Galvan]

Could you provide more detailed information about what the different skin parameters mean?

And is it possible to some kind of adaptive resolution, such that a new segment is only added when the angle with the previous one exceeds some tolerance value?

[Roland Melkert]

I've might have gone overboard with the options, I'll try to describe them below. Similar information will be added to the main site at some point.


Basics

Part: Donor ldraw file, must be findable by LDCad for generating the part, must be supplied with the model if placement is static or dynamic for other software.

Color: Donor part color, if non 16 it might also cause a split of the part into multiple subparts depending on other skin section colors.

Rotation is the initial transformation (no scaling, must be pure rotation) on the donor part.


sizes:

Basesize is the scaling over the y-axis (after rotation) to get the base size to use for placement.

Segmentsize is the space occupied on the curve, usually this is 100% but you could set it to a static value to force overlap (e.g. in chains).

Tolerance is the amount of stretching allowed to fit the base sized donor on the segment. This is used to close gaps resulting from leftover space.


segments:

Groupid is used to group multiple skin sections, when non zero skin with the same id are alternated per segment.

Count is the number of segment to use with this skin, zero means auto/unlimited.

max merge controls joining segments of the same skin when they are (more or less) inline with each other. A limit is sometimes needed to prevent noticeable misalignment over long lengths.

edges controls what to do with overlapping edges on the outer y axis of the donor. By default the left (+Y) ones on the donor are dropped except for the first segment. The option is only applied when placement is deform.


Donorcenter:

Center lets you choose what position of the donor to use for final placements on the curve.

Offset lets you set an Y offset on the above position.


Donorplacement:

Type selects the method of generation, static uses the calculated matrix for segments, dynamic will interpolate the rotation at the placements (curve) position, deform will generate type 2...5 lines from the donor mesh to smooth out the donor over the curve.

Inline donor references will try to copy type 1 lines from the donor instead of referring the donor file it self. Only used for static and dynamic placement.

Final scale will be used to stretch/shrink the donor to the real segment size, usually this means applying the tolerance from the size options on the base size.

Alignment determent how to to place the donor (position chosen in the previous panel) on the curve, it uses a relative notation meaning 0 is no change and -1 move full length to left.



Hope this is somewhat clear.

[Roland Melkert]

Thanks,

At the moment supporting Linux is almost 'free' cause the binaries still work with the newer distributions (I'm compiling in Ubuntu 10).

I'm expecting it to stay that way as long they keep supplying GTK2 alongside GTK3 in Ubuntu etc. If not I'll probably have to upgrade to GTK3 at some point.

[Ignacio Fernandez Galvan]

I'm thinking the simplist solution would be to allow the user to set the internal resolution, setting it to 16 in the case of this chain should fix every thing.

If I may add another feature request, for paths with a fixed number of segments, I'd like being able to add the end cap part wherever the skinned portion ends, and not at the final path point. This would help creating the arm in the attached model, for instance. And corner points would allow creating the other one.

(I just noticed, too, that the rotation center for the end cap is not automatically the end point, shouldn't it be?)

[Roland Melkert]

It's fun to see someone else creating parts, hope it's somewhat 'easy'.

Can I convince LDCad to include the needed unofficial donor parts in the mpd file?

Donors are searched for using the normal LDraw search rules, so if you add a donor to the mpd it should work. At the moment there is no option to embed the parts in a mpd using LDCad it self. But it should be as easy as a copy paste using e.g. notepad or by using a tool like MPDCenter.

I will add a collection of mpd manipulation tools (e.g. sel to submodel, incl unoff parts, etc) at some point.

[Roland Melkert]

Yes I wanted that myself at some point, problem is it's somewhat outside the current way of doing things. You might be able to solve it by adding the cap as a non scaling static skin section.

As for the rotation center of the ends, it depends on the (auto) group. The order used is anchor>cap>point . So to force a non cap center as end center you have to add a path anchor (you'll find it in the 'misc special parts' (top level, crossed picture) part bin group)

[Roland Melkert]

Did a little test, and you can get it to work using a static skin section, like so:

   

edit (thought png would inline automatic ?)

[Ignacio Fernandez Galvan]

Yes I wanted that myself at some point, problem is it's somewhat outside the current way of doing things. You might be able to solve it by adding the cap as a non scaling static skin section.

That helps with the end piece, but I can't do that with the claws if I want to be able to open/close them (without manually changing the rotation matrix), can I? Unless I create a submodel with the claws, and use that as skin donor... yes, that seems to work

[Ignacio Fernandez Galvan]

Yes, it helps, thank you.

So the merge limit is already controlling some kind of adaptive resolution, but there's no way to set the threshold for merging, is there? I think a hose such as the one attached might benefit from a smaller donor size, and a larger merge threshold or whatever.

[Roland Melkert]

Joining will only be applied on the segment level, current version will join when the angle between two segments is less then 0.001 RAD, I could make that an option but I don't think it will help with the example hose.

I usually decrease the basesize if very tight corners are involved, but this will also increase file size when using deform, so on longer hoses it's probably best to use two skin sections one with a low base size for the sharp bend at the beginning and one with a normal base size for the rest.

I'm playing with the idea to somewhat have similar behavior based upon some sort of split option, which will be sort of an inverse join option.

[Ignacio Fernandez Galvan]

Funny problem. When I try to open a file in the current directory from the command line, LDCad crashes, but if I open a file in a subdirectory (or if I include "./" before the filename), then all is fine.

This is Ubuntu 12.04.

[Ignacio Fernandez Galvan]

Joining will only be applied on the segment level, current version will join when the angle between two segments is less then 0.001 RAD, I could make that an option but I don't think it will help with the example hose.

What about a rubber band like this?



The resolution in the large circle is more than enough, I could even lower it (use larger segment size). But the smaller circle does not look so good, so I should actually reduce the segment size. Don't you think a smaller segment size but a larger joining angle would help?

By the way, setting "max merge" to 0 does not seem to be "unlimited" as the popup hint says. It behaves rather like 2.

[Roland Melkert]

Weird, is this in the main application folder of is LDCad in the search path?

I will look into both.

[Roland Melkert]

Rubber bands use the exact same 'resolution' rules etc.

You could solve the example problem by using multiple skin sections to force different kinds of basesize.

As for the angle, you are right using a custom higher threshold (As 0.001 rad is very low) combined with a 1 or 0.5 ldu basesize will probly solve the resolution problem without inflating the fallback code that much.

I will make the threshold a skin option in the next version, I'm also going to do some tests to see if auto splitting is useful or not


The reason only 2 segments are joined is because of the very low threshold, and if remember correctly the angle is calculated between the first and last, so unless all segments are exact in line the angle between the first and last >0.001 quite soon.

[Ignacio Fernandez Galvan]

In the "Lego" directory, I have both LDCad (LDCad-1-3-Beta-1-Linux-64) and the model, I launch it from this directory, like this:

Code:

$ LDCad-1-3-Beta-1-Linux-64/LDCad model.mpd

The main window appears, but as it tries to load the model it segfaults.

But this works:

Code:

$ LDCad-1-3-Beta-1-Linux-64/LDCad ./model.mpd

[Ignacio Fernandez Galvan]

The reason only 2 segments are joined is because of the very low threshold, and if remember correctly the angle is calculated between the first and last, so unless all segments are exact in line the angle between the first and last >0.001 quite soon.

I'm afraid I was not clear, sorry. In this part I was talking about the straight sections (I can see the segments created if I set the condlines to be always displayed). I set the base size to 100%, and then with max merge 10 or 100 I see the difference. But I expected 0 to look the same as 100 (as there will be less than 100 segments to be merged anyway), and instead It had many more segments than 10, and it looked the same as with 2. It's something like:

1: 30 segments per straight section
2: 15 segments
10: 3 segments
100: 1 segment
0: 15 segments

[Roland Melkert]

Thanks, it's not a Linux thing, the windows version does the same. I think it's caused by the 'explode' function I use on the filename.

Thanks for reporting.

[Roland Melkert]

Ok this is very weird.

This is not how it suppose to behave indeed, I'll try to improve/fix it for the next version.

[Roland Melkert]

Hello all,

Someone asked my if they could use LDCad on a Raspberry PI.

This made me very curious so I went the emulator route and managed to compile an ARMv6 version of LDCad.

Sad thing is I only realized halfway through the Raspberry PI only offers OpenGL ES, so LDCad is not going to work or will be very slow using MESA on the tiny computer.

But since I have the binary ready, I decided to share it anyway.

http://www.melkert.net/action/download/L...v6.tar.bz2

Maybe someone could test it on an ARM machine which does offer real OpenGL (are there any?).

This version also (still) needs GTK2 to work.

Please let me now any experiences, as I couldn't really test it myself.

[Roland Melkert]

Hi all,

It seems the Linux 64 bit version is broken on at least suse 13.1,

Could someone using the 64 bit version please confirm it does work on another distro. I would like to determine if this is a bug or a Suse specific thing. I can only comfortable test on VM myself at the moment, and I don't have the time to burn stacks of iso's at the moment.

[Richard Speyer]

I'm using LDCad 1.3 Beta 1 on Slackware64 14.0 with kernel 3.12.7
I've been meaning to register to say thanks for all your hard work.
I'm really appreciating the editing plane options. Once I got used to the idea, it's very powerful.