LDCad 1.3 Beta 1 (win+linux)


LDCad 1.3 Beta 1 (win+linux)
#1
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:

[Image: 1-3-B1-ForumScrShot1.png]

[Image: 1-3-B1-ForumScrShot2.png]

Hope you all like the new version, if you have any comments / questions let me know.
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#2
Are the new camera modes coming any time soon?
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#3
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.
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#4
What do you mean by 'trackball'?
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#5
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)
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#6
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.
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#7
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.
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#10
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).
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#8
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?

[Image: chain.png]
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#9
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.
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#11
I've played around with the resolution it won't matter even if I a 100 times higher.

Quote: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 Smile)

Thanks for pointing it out.
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#12
I'm glad you are a perfectionist, that means there's a chance to have this fixed Smile

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 Wink


Attached Files
.mpd   test.mpd (Size: 4.27 KB / Downloads: 0)
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#13
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:

[Image: selInfoPrvView.png]

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 Smile
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#14
Roland Melkert Wrote: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 Smile

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.
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#17
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 Smile )

[Image: hqChain.png]

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:

[Image: uniJointProb.png]

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?
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#18
Roland Melkert Wrote: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?

Quote: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 Big Grin
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#20
Ignacio Fernandez Galvan Wrote: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.


Ignacio Fernandez Galvan Wrote:But a mechanics simulator would rock Big Grin

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).
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#24
Roland Melkert Wrote: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?

[Image: chain.png]
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#25
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.
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#33
Roland Melkert Wrote: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?)


Attached Files
.mpd   b.mpd (Size: 4.78 KB / Downloads: 0)
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#35
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)
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#36
Did a little test, and you can get it to work using a static skin section, like so:

   

edit (thought png would inline automatic ?)
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#37
Roland Melkert Wrote: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 Smile
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#15
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.
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#16
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).
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#19
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?
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#21
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)
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#22
Roland Melkert Wrote: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.

Quote: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 Wink
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#23
Quote: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)
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#26
Roland Melkert Wrote: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.


Attached Files
.dat   ldcPnuHoseEnd.dat (Size: 348 bytes / Downloads: 0)
.ldr   pneumaticHoseFree.ldr (Size: 900 bytes / Downloads: 0)
.dat   ldcPnuHoseSeg.dat (Size: 771 bytes / Downloads: 0)
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#27
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.
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#29
Roland Melkert Wrote: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?


Attached Files
.dat   ldcAxleEnd.dat (Size: 1.14 KB / Downloads: 0)
.ldr   technicAxle.ldr (Size: 883 bytes / Downloads: 0)
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#34
It's fun to see someone else creating parts, hope it's somewhat 'easy'.

Ignacio Fernandez Galvan Wrote: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.
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#28
Wow, impressive update. Again the Linux support is so much appreciated.

Thank You
______________________________________________
OS = Ubuntu 14.04 LTS (64bit)
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#32
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.
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#30
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?
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#31
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.
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#38
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.


Attached Files
.ldr   hose.ldr (Size: 1.27 KB / Downloads: 0)
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#39
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.
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#41
Roland Melkert Wrote: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?

[Image: band.png]

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.
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#43
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.
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#45
Roland Melkert Wrote: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
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#47
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.
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#40
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.
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#42
Weird, is this in the main application folder of is LDCad in the search path?

I will look into both.
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#44
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
Reply
Re: LDCad 1.3 Beta 1 (win+linux)
#46
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.
Reply
LDCad 1.3 Beta 1 for Linux on ARMv6
#48
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.
Reply
Re: LDCad 1.3 Beta 1 for Linux on ARMv6
#54
hi Roland,
I just tried it on a Raspberry Pi Model B+.
Package libgtk2.0-bin and libgl1-mesa-glx is installed.
I had to install libglu1-mesa to get it running.
After setting the directory of the parts library, a blank window (no menus, just a status bar at the bottom) shows up with a message "Fatal: OpenGL not available".
Then I installed libgles2-mesa: same result.
Does the fatal error even prevent the menus showing up?
regards,
LC
Reply
Re: LDCad 1.3 Beta 1 for Linux on ARMv6
#55
Thanks for trying,

LDCad primarily uses an pure OpenGL GUI inside a single panel/context. There are two major reasons for getting the 'no OpenGL' message:

wxWidgets failed (using glut) to initialize the context.
or the OpenGL version is below 1.1.

A more precise reason might be given in the log file.

Also the raspberry only has OpenGL ES so no display lists, something I use extensively for the gui rendering. I'm not sure how to make Linux use pure software MESA rendering as an fallback but I'm expecting this is what's needed to get it working (very slowly).

Removing the dependency on display lists is on my long term plans, when that's done a usable version for arm (and Linux tablets etc) becomes possible / usable.
Reply
Re: LDCad 1.3 Beta 1 for Linux on ARMv6
#56
hi Roland,
the logfile has one error message:
glew failed to initialize, no opengl interface available
the rest is OK
regards,
frank
Reply
Re: LDCad 1.3 Beta 1 for Linux on ARMv6
#57
I think this fails because it asks for a normal OpenGL context, while the pi can only offer a OpenGL ES context.

To get a non ES context you need to install a pure software renderer/rasterizer, for example by using http://www.mesa3d.org/intro.html

I'm not completely sure but I don't think this software rendering is installed by default (even if you have some *mesa* libs installed). And it will be VERY slow so it might not be worth the effort.

I'm hoping to support OpenGL ES when the Ubuntu tablets become more mainstream, as I would love to get one of those to play with myself.
Reply
Req info on 64 bit useage (Re: LDCad 1.3 Beta 1)
#49
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.
Reply
Re: Req info on 64 bit useage (Re: LDCad 1.3 Beta 1)
#50
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.
Reply
Re: Req info on 64 bit useage (Re: LDCad 1.3 Beta 1)
#53
Thanks for reporting,

Yes the editing plane can be a bit weird, but up to the part snapping feature it was very important Smile
Reply
Re: Req info on 64 bit useage (Re: LDCad 1.3 Beta 1)
#51
I'm using it in Ubuntu 12.4, no problems so far.

Is there some kind of "about" dialog somewhere to check the exact version, by the way?
Reply
Re: Req info on 64 bit useage (Re: LDCad 1.3 Beta 1)
#52
Glad Unbuntu has no problems, but there seems to be a GTK dependency issue on some other platforms.

Currently there is no indication to see if the 32 or 64 bit version is running, I'll add that to the about box. Only indication at the moment is the tar.gz filename.
Reply
« Next Oldest | Next Newest »



Forum Jump:


Users browsing this thread: 1 Guest(s)
Forum Jump:


Users browsing this thread: 1 Guest(s)