LDCad 1.2 Public Alpha 1

[Roland Melkert]

Took me awhile but here's the first test version of LDCad 1.2.

It's major new features are templates and highly configurable flexible parts.

Do note this is an Alpha version, meaning it is not jet feature complete. Although all core functionality is working I'm still working on some additional support features I'm hoping to offer in the next version.

As a result working with the new flexible parts requires some expertise for now. I'll try to give some quick pointers here to get you started:

• Start a new model like in previous versions.
  
• Locate the 'templates' group in the bin and navigate around in it to select a template (e.g. pneumatics/hose)
  
• Drag the part to your model like any other part.
  
• A dialog will ask if you want to create a submodel (mpd) or new file (ldr), choose one.
  
• The template will be copied into the target model and a reference to that new model will be added to the current model.
  
• You can now move it around like any other part/submodel and edit by double clicking it.
  

When editing the tube itself you can bend it's path by moving and or adding points around. The simplest way to do this is by selecting a point and pressing the insert key. A new point will be added AFTER the one you selected, but also always before the last point on the path.

While editing a path there are some general guidelines which should make things easier (until the support features I mentioned above are ready).

• Keep track of the #1 point it should remain at 0,0,0 for ease of use.
  
• When shaping the part, you are working blind for now. So use the 'end' key to swap between models to see the path in relation to the higher model.
  
• Generally you want to position the start of the path using the reference in the higher model using it, when that's done move the last point of the path to the destination location using the paths own session.
  
• When start and end points are positioned correctly, select the first point again and start inserting extra points to guide the path to it's goal.
  
• Rotate a point to change direction and shape bends using the green and red spheres.
  
• Use ortho mode whenever possible, it offers much better insight about direction and makes using the grid easier.
  
• Use 'p' (show/hide editing pin), 'g' (show hide grid for selection), 'o' (change grid orientation to match the selection), 'i' (show hide the info panel), 'r' (rotate mode) and 'm' (move mode) instead of the mouse whenever needed.
  

I think this should get you started, I could probably write a book about the path options themselves, but for now I'm limiting this novel to using template based paths. If you're brave enough to try and create a custom part, you can do so via 'file/new...' and the special 'path' group in the special parts folder. I'll write a better guide if needed, just ask.

Ok, here are the downloads. They are all archive (standalone/portable) versions and I recommend you use them separately from any other LDCad installation.

LDCad-1-2-Public-Alpha-1-Linux-32.tar.bz2
LDCad-1-2-Public-Alpha-1-Linux-64.tar.bz2
LDCad-1-2-Public-Alpha-1-Win-32.7z

Some caution, I haven't had time to really test the Linux versions, but they should work ok. Please let me know if they act especially weird or something.

Some screenshots:





I've also attached the mpd shown in these screenshots, to prove any LDraw renderer should be able to show the flexible parts.

In closure please remind this is a test/alpha version so any comments and bug reports are welcome ether here or by direct email (see www.melkert.net/LDCad for my email address )

I'm especially curious about what experienced part authors have to say / think about the collection templates / path options, because they are in many ways just like official parts.

[Travis Cobbs]

I have a few observations based on looking at your sample model in LDView. My first observation is that, once LDView has a bug fixed, your hoses will look much nicer in LDView if you add a line to the top of their definition saying "0 Unofficial Part". This will cause LDView to treat the hose as a part, and therefore perform smoothing on it.

Currently, there is a bug in LDView that causes really bad results with your hoses after doing this. However, I am working on a fix for this bug, and while I'm not currently happy with the performance of my fix, it does basically work. While doing this, I discovered that your hoses are missing conditional lines between the segments. Adding those would cause the smoothing to look really good (with my LDView fix).

Another problem is that you split quads into two triangles prior to doing the deformation, and the deformation can result in output where the two triangles that make up the quad have different normals. These triangles should have a conditional line added between them.

Note: My LDView bug is that if the two triangles ARE co-planar, LDView doesn't treat them properly, and ends up producing very bizarre smoothing results. My tweak to fix that is to add fake conditionals between adjacent co-planar polygons (just for smoothing) in order to make my smoothing algorithm work better. While testing my fix, I had to set the tolerance when checking if two normals are "equal" to a fairly loose value (.02 for each of the x,y,z components of a normalized vector wasn't quite loose enough; .1 caused excessive smoothing).

[Travis Cobbs]

Philo: I seem to remember you reporting this LDView bug. Do you have any parts that I could test my fix against?

[Philippe Hurbain]

Hi Travis,
Sorry, I'm not home now, so I don't have examples at hand...

My LDView bug is that if the two triangles ARE co-planar, LDView doesn't treat them properly, and ends up producing very bizarre smoothing results.

...but basically, yes, it's the problem. For a structure like this tube, it results in a weird twisted look. Creating "virtual" condlines in planar areas will definitely improve smoothness of many parts! I have been tempted so many times to introduce condlines in planar areas to avoid this kind of problems...

(.02 for each of the x,y,z components of a normalized vector wasn't quite loose enough; .1 caused excessive smoothing)

Do you have a rough value of facets angle that will trigger this smoothing? Presently Edger2 defaults to create condlines above 0.1°. If I set the correct default value, "virtual condline" will do the smoothing job below the threshold, and real one will do above.

[Roland Melkert]

if you add a line to the top of their definition saying "0 Unofficial Part". This will cause LDView to treat the hose as a part, and therefore perform smoothing on it.

Is it ok if this line follows after "0 !LDCAD GENERATED" (but before the bfc one) making it part of the maintained code block. Or does LDView stop processing the header as soon it finds non header metas or something? You could also add it to the template as a workaround in the current version though.

While doing this, I discovered that your hoses are missing conditional lines between the segments. Adding those would cause the smoothing to look really good (with my LDView fix).

That should be forced by adding those type 5 lines in the donor, only downside is they will cause duplicate lines for all but the last segment. Although I probably be able to add detection for that without too many costly vertex compares. Next Alpha will have a custom donor (with minimal geometry) for hoses I'll make a note to add those lines in those files.

Another problem is that you split quads into two triangles prior to doing the deformation, and the deformation can result in output where the two triangles that make up the quad have different normals. These triangles should have a conditional line added between them.

So basically I need to add a conditional line between split quad triangles if the angle between their normals is below a certain (0.02 deg or dot prod ?) value?

[Travis Cobbs]

The "0 Unofficial Part" can be anywhere in the definition at all (including the very end), and LDView will still treat the "file" as a part. However, it's probably best to put it near the top somewhere.

I don't think you can put the conditionals in the donor part, because the control points going to the next segment depend on the location of the points in the next segment.

My current "normals are approximately equal" check doesn't involve the angle between them at all, but checks the x, y, and z coordinates of both (normalized) normals to see that they are within some threshold. I wanted to test the new code quickly, and that was the fastest way to do so. I'll update it to do the dot product, then choose an appropriate threshold (perhaps 1 degree). Note that if I set my current threshold to .1, visually I can see that surfaces with 10-20 degree angles between them get smoothed, so 1 degree may not be as unreasonably big as it sounds.

[Travis Cobbs]

I just set the angle threshold to 1 degree, and it looks fairly reasonable. Here is the hose in standard view:

And here it is from another angle, zoomed in. You can see the weird pattern where the missing conditional lines lead to problems:

[Philippe Hurbain]

This is great! Could you share a beta including this feature?
If the "planar smoothing" occurs below 1°, I'll let edger2 minimum threshold to present 0.1°, at 1° condlines are sometimes missing on edge of shapes, in their original purpose...

[Roland Melkert]

I don't think you can put the conditionals in the donor part, because the control points going to the next segment depend on the location of the points in the next segment.

The control points are being transformed just like all other points but you are right this will go wrong (or less accurate) for control points whom overlap into another segment. I could account for that though, I'll look into that for the next version. I was already considering it at one point for instances the donor it self has overlap with other segments. I decided against that feature because of all the extra buffering / matrix operations required for it to work properly. But limiting it to just the type 5 control points might be acceptable.

Thanks for your tests I would very much like to see these generated parts at their best in LDView

[Ignacio Fernandez Galvan]

Just tried the linux-64 version. I could see the templates, but then closed the program, opened it again, and the templates are all red crosses. So deleted the directory and this seems reproducible:

1. Start LDCad, select the LDraw directory, select the templates bin (no need to select "new" or "open"). The templates appear.
2. Close LDCad.
3. Start LDCad, select the templates bin. Just red crosses.

I'd say there's something wrong either in my system or in the default path for the templates. More investigation reveals that:

4. Close LDCad. Delete config/templates.inv.
5. Start LDCad, select the templates bin. The templates appear again.

The paths in templates.inv look OK, though.

[Roland Melkert]

Thanks for reporting,

This is an Linux only issue due to the \ vs / thing. I'm using it pretty transparent throughout my code but it seems to go wrong when bin items are using a subfolder prefix (like all templates do).

I'll fix this in the next version, for now you could apply a simple workaround by blocking the template.inv disk io:

• Close LDCad
  
• Edit the templates.inv to clear it's content.
  
• Change the file to readonly
  

The application will now be forced to regenerate the inventory on each start up, which isn't that bad because there aren't that many items in it (yet).

[Ignacio Fernandez Galvan]

Thank you, that's working fine. Other things I noticed (linux 64bit, again):

1. After moving a control point, I click "undo", but nothing changes until I rotate the view (for instance).

2. When inserting a new path point, would it be possible to insert it somewhere along the current path, and require selecting it to move it? I think that could make path creation more convenient.

3. This is something already happened with 1.1. If I click on the properties box, to view the mainpart properties, and then click on "Discard", the dialog is closed, but the mouse behaviour gets into rotation mode, as if the click on the button had been passed to the main view too.

4. The approximate length of the path is written to the file as a comment, is it possible to view it also in the GUI? If it isn't, I wish it were.

5. I'd like a rubber hose without stretched ends too.

[Roland Melkert]

When inserting a new path point, would it be possible to insert it somewhere along the current path, and require selecting it to move it?

I'm not sure what you mean, but if you select e.g. the 3rd point of a 6 point path and press the ins key the new point will be the new 4th). Same goes for drag and drop from the bin, as long you currently have a point selected the new one will be placed behind it (unless it's the last point of the path) order wise. If none or the last one is selected it will always become the second last one. This is to keep the keep the last point and it's 'companion' parts (caps) together.

The approximate length of the path is written to the file as a comment, is it possible to view it also in the GUI? If it isn't, I wish it were.

This is pending in the form of an document info panel, which I probably add to the right lower corner. It will show things like piece count, model size and for paths the length. I'm not sure yet how this panel is going to look/behave but it's whole reason for existing started out with: 'where do I put the path length?'

I'd like a rubber hose without stretched ends too.

You could just delete the caps after the template is copied into a model, or copy the template itself on disk and delete them in the copy if you want to drag and drop it without having to delete them each time. You could also add a user template location (pref/ldraw/user templates) and place altered templates in that location to keep them separate from the default ones, they will show up in the bin just the same (aslong you use category and or keyword tags in them so they match the bin group filter(s)).

I will look into point 1 and 3 for the next version.

[Travis Cobbs]

Unfortunately, the code I have right now is quite slow. The 10143 Death Star II model takes about 9 seconds to load on my Mac without this new code. Adding in the new code bumps that up to 21 seconds. I haven't done any general benchmarking to see if the new code is consistently doubling the load time, but it's very obviously quite slow (so much so that it's obviously not acceptable as-is).

The main reason its so slow is that it gets run at the last minute, right before the smoothing is performed on a part. That means that it's incredibly inefficient, because it is run on "flattened" part geometry. So, for example, for a 2x4 stud, it gets run against all 8 stud caps individually. The proper way to do it is to run it against the disc primitive once, and then reuse the results throughout the entire main file loaded by LDView. (This would prevent adding fake conditionals between two separate sub-files, but that shouldn't be much of a problem.)

I placed the code where I did because I wanted to see if it would work, and I knew that if I put it there, it wouldn't have any secondary effects. I need to put comparable code in the LDraw file-loading section of LDView, so it can be efficient (running once per unique sub-file), but in order to do that, I have to flag these calculated conditionals as being "fake", so they won't get drawn (slowing things down) when LDView is set to draw conditional lines.

So, the short answer to your question is no, because I'm never going to release what I have right now. However, the longer answer is that I can hopefully do either another Beta, or perhaps just a more limited test release, that includes code that produces the same end-result, but does so in a reasonable fashion.

[Ignacio Fernandez Galvan]

I'm not sure what you mean, but if you select e.g. the 3rd point of a 6 point path and press the ins key the new point will be the new 4th). Same goes for drag and drop from the bin, as long you currently have a point selected the new one will be placed behind it (unless it's the last point of the path) order wise.

I mean that when inserting a path point it appears already in drag mode, and it may be more more convenient if it just appears somewhere in the path, and the user can then select it and move it.

You could just delete the caps after the template is copied into a model

Yes, I tried, but then the end is not properly closed, it needs an end piece with normal radius.

Anyway, great work, thank you!

[Philippe Hurbain]

Thanks for the detailed answer, I can wait

[Ignacio Fernandez Galvan]

Is it possible to have a flexible part inside a submodel (and not as a separate one)? I've found I'd like that for the wings this model. You see, I want to be able to move the wing (rotate around the hinge), which should move one end of the flexible hose, but not the other end. Having the whole hose as a separate model makes it rather cumbersome to move the wing.

[Philippe Hurbain]

This is to keep the keep the last point and it's 'companion' parts (caps) together.

When I move an end point, end cap doesn't follow it (or, if I move end cap, flex doesn't follow). Do I do something wrong?

[Roland Melkert]

This is to keep the keep the last point and it's 'companion' parts (caps) together.

When I move an end point, end cap doesn't follow it (or, if I move end cap, flex doesn't follow). Do I do something wrong?

No the current version is stuck in 'configuration mode', the next version will be able to go into an alternative mode where the endings are auto grouped with their caps. This is why the current caps already have a 'group' property which you can set to 'start' or 'end'. Same goes for the anchor parts which act like the center points of the endings.

For now you need to manual select the cap and point whenever you want to move ether one. This is why advice to place the starting and ending stuff at their final position asap, and also why I've chosen to insert new points before the last one at all times.

I could have added a quick and dirty grouping just for these end parts, but I wanted to have decent global group handling in one go.

[Roland Melkert]

Is it possible to have a flexible part inside a submodel (and not as a separate one)? I've found I'd like that for the wings this model. You see, I want to be able to move the wing (rotate around the hinge), which should move one end of the flexible hose, but not the other end. Having the whole hose as a separate model makes it rather cumbersome to move the wing.

Like with the lack of grouping blind path plotting is temporary, The next version will have the option to edit a submodel while staying inside the higher one, so you see what you're doing

But you will always have to reposition the flexible parts' ends if you adjust the wing angle. At least until I start adding animation and or auto connection support, which I hope to do at some point in the future.

[Philippe Hurbain]

OK!
Otherwise, I think that description tags "rotation" and "position" in Grid menu are swapped...

[Ignacio Fernandez Galvan]

But you will always have to reposition the flexible parts' ends if you adjust the wing angle. At least until I start adding animation and or auto connection support, which I hope to do at some point in the future.

Do you mean it won't be possible (for the moment) to select the wing and the attached end piece and move them together?

[Roland Melkert]

O wait I misunderstood you, you mean you want to select parts from different sub-models and move them as one?

This might become possible when I implement the nested editing I mentioned above. But I'm not completely sure on how to set that feature up at the moment. So I might limit it to normal editing with the higher model displayed statically displayed on the background.

Although I agree it would be much more useful if you could indeed manipulate all parts of both models as if it was only one model. I'll have to see if that can be done without too much of an impact on existing code, otherwise I might push it to 1.3 or something.

A workaround in the current version could be to copy the wings orientation using it's properties dialog (enter key when selected). then go into the path session and add a temporary 1x1 brick (will become a cap) or something at 0,0,0. Then open it's properties dialog and paste the orientation. Finally you change the grid orientation using 'o' to match the new cap (you can delete the cap afterwards). As a result you now are basically working in the same coordinate system as the wing.

Hope this is somewhat useful At the very least it given me an idea for a new menu item (set grid orientation from clipboard pos/ori).

[Ignacio Fernandez Galvan]

O wait I misunderstood you, you mean you want to select parts from different sub-models and move them as one?

Yes, currently that's what would be needed. If it were possible to have the flexible part not as a separate submodel, but as part part of the same submodel as the wing, then the selected parts would not be from different submodels. But for that, you'd have to use some kind of bracketing in the code and not rely on "0 FILE" commands, as I guess is the case now. LSynth does something similar, it uses "0 SYNTH BEGIN" and "0 SYNTH END" to enclose LSynth code, which makes it possible to insert it into any submodel. I don't know if that would be possible for your code.

[Roland Melkert]

It might be possible to insert them anywhere but I've made the explicit choice to force them into managed subfiles. Mainly because these are flexible parts and therefore should be handled like any other part inside a model. The alternative would be to handle them like special groups but I felt that's misusing the nature of grouping somewhat.

Anyway the upcoming nested editing feature will probably resolve / ease your placement issue with this particular model.

[Ignacio Fernandez Galvan]

Is it possible to have templates for flexible parts made up of different pieces, like these cables?

[Roland Melkert]

Yes, but you will need some custom / unofficial subparts.

Once all the needed subparts are official I will add default templates for them, but in the mean time you can configure pretty much any flexible part your self if you are not scared of using some more advanced features.

For this to work you must first configure LDCad to use the unofficial library along side the official one using the 'prefs\LDraw\search paths' dialog. When all needed parts are findable you start a new path file or edit a copy of e.g. the pneumatic hose, I'll assume the later.

Locate a suitable wire segment donor in the bin and double click it while the skin is selected. This will replace the donor from pneumatic tube segment to a wire segment (the double tubes). You might need to fiddle with the rotation matrix in the skin dialog of the wire segment is differently orientated (the skin dlg assumes default LDraw part authoring rules as discussed in this tread)

Next you replace the pneumatic endcaps with a complete plug the same way.

If one or both of those plugs are the wide version you need to account for the widening / split of the wire. For this you need a subpart containing this widening section (don't know if that's a s\ part in the unofficial library?). You can then place this part as an additional cap just like the connectors them selves or make them part of the skin / wire section by adding additional skin sections (of a single segment) to the path. Don't worry about having multiple end caps and how to keep them together later on, the next version will have auto grouping for them.

Hope this is somewhat clear, It probably needs a (video) tutorial to make more sense, although it really isn't that difficult once you got the hang of it all.

Also if anyone would like to see additional default templates of stuff that's is already in the official library let me know, I'm planning to extend the default collection considerably for the next version anyway. Maybe even include some parts that need custom donors etc. As long those donors are ether supplied to me or are simple enough for me to make myself in a couple of minutes.

[Ignacio Fernandez Galvan]

At the moment I think it could be more convenient for me to create the template directly in the text file with a text editor. At least for adding the different components, which can then be positioned or transformed with the GUI. Using unofficial parts is not a problem at the moment.

I got as far as creating a basic cable template for the 8700 set (I don't have it, but I have several models that refer to it in the instructions). But I don't know how to add the split parts joining the cable and the plug, while keeping them flexible (I don't want to use x994.dat). With LSynth, the donor part is simply 4-4cyli.dat (see this model for example).

Could you tell me how to add the split ends (if possible) to the attached template?

[Roland Melkert]

Well you could use

Code:

0 !LDCAD PATH_SKIN [donCol=16] [donOri=1 0 0 0 1 0 0 0 1] [donPart=x994.dat] [donYSize=100%] [donCen=absCen] [donCenYOfs=0] [donFinScale=fitDon2Seg] [donPlace=deform] [donYAlign=0] [segSize=100%] [segSizeTol=5%] [segsCnt=1] [segsGrp=0] [segsMaxMerge=1]
0 !LDCAD PATH_SKIN [donCol=16] [donOri=1 0 0 0 1 0 0 0 1] [donPart=x993.dat] [donYSize=200%] [donCen=absCen] [donCenYOfs=0] [donFinScale=fitDon2Seg] [donPlace=deform] [donYAlign=0] [segSize=100%] [segSizeTol=5%] [segsCnt=0] [segsGrp=0] [segsMaxMerge=10]
0 !LDCAD PATH_SKIN [donCol=16] [donOri=-1 0 0 0 -1 0 0 0 1] [donPart=x994.dat] [donYSize=100%] [donCen=absCen] [donCenYOfs=0] [donFinScale=fitDon2Seg] [donPlace=deform] [donYAlign=0] [segSize=100%] [segSizeTol=5%] [segsCnt=1] [segsGrp=0] [segsMaxMerge=1]

Instead of the single PATH_SKIN line in your attachment. you will need to adjust the position of the connectors too but the Y segments will deform like all other segments. You could also use the x994 as an extra cap part together with the connector caps. But like you wrote it won't bend that way, but because the limited size of them you won't loose much bending room but it will save on file size.

Or do you mean you don't want to use the x994 part at all, not even for a skin donor? In that case you need to make an alternative for it yourself because one way or another you need a donor for that Y section.

You could (separately) model the donor it self using a path but I don't officially support that in this version, but if you strip away the !LDCAD metas by hand afterwards the resulting part defined by the fallback lines could be used like any other dat/ldr file donor wise.

Hope this helps

[Ignacio Fernandez Galvan]

Ah, I see... that's probably good enough.

Or do you mean you don't want to use the x994 part at all, not even for a skin donor? In that case you need to make an alternative for it yourself because one way or another you need a donor for that Y section.

Yes, that was my initial intent, as I don't like the shape of x994 too much. But I think I can stand it for the moment I was hoping it would be possible to have something like 5 separate paths in the same template (one for the central double cable, and 4 for the different split sections at the ends) and 2 end caps (the connectors/plugs).

[Roland Melkert]

One path per part is the current limitation, but I might consider adding support for splitting the path in some (distant) future version if one or more real life parts need it without having a good enough fallback solution.

For now I like to concentrate on more needed extensions like closed paths for things like bands and chain/link tracks using sections defined by circle/arc points instead of bezier points etc.