LDCad 1.5 progress / opinions req

[Roland Melkert]

Made some real progress this weekend so I would like to post some previews in order to gather some feedback.

Main reason for this is me not being completely sure on the details / behavior of the new LDraw source code window. So any suggestions / feedback on that would be very much appreciated.

Here's a screen shot of the 1.5 gui while using undocked windows and the new source window.

And here's one with everything docked (notice the second part bin).

The source window is read only at the moment but in the very least I want it to be able to control selections. And maybe manage third party meta's (e.g. LPUB)?

Any thoughts?

[Richard Speyer]

Looking good.
I think it would be good to highlight any selected parts in the source code window.
If we can't directly edit in the source window, maybe the option to open the "properties" dialog for a part line.
If I put multiple part bins, are the tabs the same or independent?

[Roland Melkert]

Looking good.

Thanks

I think it would be good to highlight any selected parts in the source code window.

The source window will highlight the selection, I'm just not sure how to handle lines which can't be selected in the 3D view (step meta etc) as things can get messy from basically having two different selection sets.

If we can't directly edit in the source window, maybe the option to open the "properties" dialog for a part line.

As for the property dialogs I'm thinking to ether add some new ones for third party meta's and fallback to a simple single text line input for unknown content.

If I put multiple part bins, are the tabs the same or independent?

Every part bin window has it's own view / state io etc, this goes for all dockable windows. There's also no limit on the amount you can have open of the same kind (incl none).

[Merlijn Wissink]

Looks great! I especially like the source window (although the 2nd parts-bin also looks useful).

Regarding the source window, I'd like it to behave a bit like in MLCad. When I make instructions, I build the model in LDCad and then I open it in MLCad to reorganize all steps. Because, with such a source window, it's easy to see the order of the parts and being able to move whole steps back and forth. I'd really like that, being able to move the order of the parts directly in the source window.

[Philippe Hurbain]

Looks good indeed, but I can feel your pain about coherency between text and 3DView. I guess that the worse is for metas that are somehow linked to following parts such as BFC INVERTNEXT (not so annoying here since you don't make a parts editor) or GROUP metas.

I'm just not sure how to handle lines which can't be selected in the 3D view

I feel that text view selection is a superset of 3D view selection, as you can add more things to selection in text (but not the opposite).
As one of the purpose of text view is to manage stepping, I think it would be nice to somehow highlight in text view the current step as shown in 3D (and update that field in 3D view if more 0 STEP are added or deleted in text). Another concern is ROTSTEP meta - how to make this convenient?

The detachable bins look great too - Beeing able to overlap them partially to keep consumed screen area down looks interesting (but needs to be tested to see if it's pactical

[Trevor Sandy]

Very nice!

Do you plan to enable cut and paste within the source window and 3D 'reload' from source in the 1.5 roadmap?

The ability to manage source (i.e. cut and paste step and subfile content) is very useful - especilly when preparing for instructions generation.

[Willy Tschager]

Will the color of filetype/position/matrix be changeable via the Prefs? How about the font size?

w.

[Roland Melkert]

Looks good indeed, but I can feel your pain about coherency between text and 3DView. I guess that the worse is for metas that are somehow linked to following parts such as BFC INVERTNEXT (not so annoying here since you don't make a parts editor) or GROUP metas.

Yes, and the fun thing about the LDCad group next meta's is they currently only get moved / added to the correct place at save time. So I'm thinking to just remove/hide them from the source window all together as they aren't interesting during editing anyhow.

I feel that text view selection is a superset of 3D view selection, as you can add more things to selection in text (but not the opposite).

Indeed, and I'm also wondering about the fact I keep track of the selection 'click order' in the 3D view while you probably want line order in the source window.

Another concern is ROTSTEP meta - how to make this convenient?

I'm currently not really familiar with LPUB but adding parse level awareness support for it shouldn't be a big problem. Maybe even apply that rotation information in a new special part bin building group or something.

[Roland Melkert]

Will the color of filetype/position/matrix be changeable via the Prefs? How about the font size?

Current colors font size etc are more or less placeholders as I just needed some basics in order to test the underlying OpenGL mass text renderer I've been mostly working on for this source window.

Also a full GUI color / font editor /manager is on my 1.5 feature list, although it probably be in beta 2 at the earliest. Alternative will always be editing the config files as all colors and font sizes etc are the main.gui file.

[Philippe Hurbain]

Yes, and the fun thing about the LDCad group next meta's is they currently only get moved / added to the correct place at save time. So I'm thinking to just remove/hide them from the source window all together as they aren't interesting during editing anyhow.

It makes (a lot of) sense!

Speaking of groups, I have encountered situations where I needed to change orientation or position of a part within a group. Maybe I missed something, but I found no other way but ungrouping to make the modification. What about a "nested mode for groups" or at least possibility to remove from group the part which was used to select group?

I'm currently not really familiar with LPUB but adding parse level awareness support for it shouldn't be a big problem. Maybe even apply that rotation information in a new special part bin building group or something.

Strictly speaking ROTSTEP is not a LPUB command but a very old meta (I believe it was introduced by LDlite, and further extended by MLCad - See www.lm-software.com/mlcad/Specification_V2.0.pdf ) to set orientation of a model in view mode. So I guess it might be interesting to support it in LDCad view mode?

[Roland Melkert]

Speaking of groups, I have encountered situations where I needed to change orientation or position of a part within a group. Maybe I missed something, but I found no other way but ungrouping to make the modification. What about a "nested mode for groups" or at least possibility to remove from group the part which was used to select group?

Currently you can only change the rotation center of an existing group. I have some additional plans concerning groups but none of those include reorganizing their contents, I'll have to think about how to do that as nesting etc is already complicated enough for most people

Strictly speaking ROTSTEP is not a LPUB command but a very old meta (I believe it was introduced by LDlite, and further extended by MLCad - See www.lm-software.com/mlcad/Specification_V2.0.pdf ) to set orientation of a model in view mode. So I guess it might be interesting to support it in LDCad view mode?

Thanks, I'll will look into that as I was planning to support some MLCad meta's as part of the source window anyway.

[Gerald Lasser]

After observing the great development of your SW, I have to admit I did not browse all threads, so may be the question has been asked already:

When flexible parts are used, I am always having the issue of determining the proper length of the part. I have put this up with LSYNTH once here. Now I saw that you have the line within the file that reads:

0 // The path is approx 88.761183 mm (221.90) and exists out of 40 segments.

I'm very happy to see this! So LDCad is calculating the length already. Would it be possible to limit this lenght? I.e. if you insert a flex axle they have a specific lenght and it would be good to see them shaped with their original length displayed.

Second point would be a nice cable management.
- Once to have a flex part that has a lenght of e.g. 25 studs and can only be routed with this constraint.
- Secondly to have options for one and the same cable. I mean that during building you need to re-route the cable probably.
- I did this with the MLCAD GROUP command within LPUB. I created submodels of a certain length which I then swapped with the help of the LPUB REMOVE GROUP command adn inserted the next submodel. That is quite hard to manage and some assistance by the editor would be really great.

Thansk!

[Roland Melkert]

When flexible parts are used, I am always having the issue of determining the proper length of the part....... Would it be possible to limit this lenght?

You can limit the length by specifying a fixed number of segments in the path's skin info combined with 0% tolerance and e.g. 5mm as a base size. That way having e.g. 10 segments will be 50mm. Like so:

   

But like the above demonstrates the 80% segment size (to prevent gaps while not deforming) will complicate things some what. So it is probably easier to use the special length management meta's I've mentioned earlier in the thread.

Those can be used to define ranges of length constrains which then can be used to associate the part with different kinds of static LDraw part numbers. Example:

   

Second point would be a nice cable management.

Working with lots of generated content can get very complicated inside LDCad too. Currently the easiest way is to use nested mode and part/model hiding, or shape things in the path subfile itself so you only seeing one hose at a time.

I do have some ideas on how to improve working with lots of pneuhoses etc but nothing groundbreaking, so any suggestions are welcome.

[Gerald Lasser]

Thanks for the screenshot! I really need to dig into these settings, looks very interesting!

Regarding the cable management I do some writeup and post it later.

[Roland Melkert]

Just wanted to show I'm still working on 1.5 although I'm way behind my initial schedule for it

A screenshot

I just finished the generic source window handling, as demonstrated in this youtube clip

I'm not completely sure this is how it will be in the final version as I'm still a bit unclear on how to precisely handle the nesting mode combined with the source window (it's currently not dummy proof).

Based on the clip I would very much like to hear what people are thinking about the current approach.

Any feedback is very much appreciated.

[Richard Speyer]

That looks great!
I think the on screen text feedback works well.
I don't have any advice about the source window as I don't do anything particularly complicated.

[Philippe Hurbain]

Difficult to give detailed feedback before playing with the real thing, but looks great so far!

[Merlijn Wissink]

Looks very promising!

[Roland Melkert]

Thanks all,

Difficult to give detailed feedback before playing with the real thing

I kinda figured that, so I'm considering putting up an (public) Alpha version soon as a Beta is going to take me at least another month of two.

I just need to finish some details and work trough the 1.4 known bugs list before uploading it. It won't be as stable as a Beta though and it's still missing two of the new major features. but that's kinda what the Alpha stands for

[Jason Allemann]

I was just coming in to the forum to ask how to insert custom meta commands using LDCad, but based on this thread I'm guessing it's not possible in 1.4?

Also, does LDCad support rotation steps? Couldn't find them anywhere.

In my limited testing I like a lot about LDCad. Unfortunately lack of the above two features are deal breakers for me being able to really switch to it. I was also lamenting the lack of a source window, but it looks like that's coming in 1.5.

Looking forward to future updates. Keep up the amazing work!

J

[Roland Melkert]

Yes 1.4 only handles visible items, the only exception on this is the step meta which can be inserted using ctrl+ins.

1.5 will allow for any meta ins/duplicate/copy/paste. If it's an unknown meta it will simply be handled as a comment.

I'm also planing to make the 1.5 version aware of LPub meta's so you can drag them from the part bin but this will probably not be in the first public alpha I'm planning.

To efficiently handle unknown meta's you could also setup templates though.

[Jason Allemann]

Cool, looking forward to it!

[Trevor Sandy]

Hi Roland,

Can you give a status/prospect of LDCad's support for saving a template as a part (.dat) - as it already supports saving as an inline and stand alone submodel (.ldr).

This capability is especially useful for LPub3D's ability to automatically treat complex user-defined parts.

Let's take a shock absorber for example. When creating instructions with such a part, it is desirable to treat the absorber as a single part so it can be efficiently and automatically managed in the PLI/BOM.

As a submodel, the part components will be displayed requiring some advanced manipulation to "transform" into a single BOM/PLI part. Another good example is 8870 LEGO® Power Functions Light.

I am working on a part substitution framework for LPub3D that will allow substitution of the modeled part with a different representation. The light example would benefit from this functionality where instead of having the show the actual modeled part which would take the form as installed in the model, a substitute "shortcut" or catalog representation would be used in the PLI/BOM. I believe the ability to save LDCad templates as parts would be complementary to this new capability as well as the overall ability to produce complex CAI overall.

Cheers,
Trevor

[Roland Melkert]

Can you give a status/prospect of LDCad's support for saving a template as a part (.dat) - as it already supports saving as an inline and stand alone submodel (.ldr).

This capability is especially useful for LPub3D's ability to automatically treat complex user-defined parts.

Let's take a shock absorber for example. When creating instructions with such a part, it is desirable to treat the absorber as a single part so it can be efficiently and automatically managed in the PLI/BOM.

As a submodel, the part components will be displayed requiring some advanced manipulation to "transform" into a single BOM/PLI part. Another good example is 8870 LEGO® Power Functions Light.

I am working on a part substitution framework for LPub3D that will allow substitution of the modeled part with a different representation. The light example would benefit from this functionality where instead of having the show the actual modeled part which would take the form as installed in the model, a substitute "shortcut" or catalog representation would be used in the PLI/BOM. I believe the ability to save LDCad templates as parts would be complementary to this new capability as well as the overall ability to produce complex CAI overall.

Actually the generated hose/shock etc might be called .ldr inside the mpd but it has the lines

Code:

0 UNOFFICIAL PART
0 BFC CERTIFY CCW

In the header, LPub3D can use that to thread them as parts instead of submodels. There is also the option to include alias info with LDCad path content. This is somewhat untested / unused at the moment as I was targeting it at some future feature which has become low prio.

Anyway those alias metas can be used to reference an official (static) ldraw part for use in BOM lists. This is done by setting up a table of lengths combined with .dat filenames. I could add something simular to the spring based parts, which will only need a single static 'mascot' I think.

I can then add some static comment line in the generated code mentioning the resolved alias, which you can then use in the BOM.

I'll try to flesh these features out for the 1.5 Beta 2 and add alias info to the default templates. If you have any additional ideas / suggestions feel free to let me now.

[Trevor Sandy]

Thanks Roland.

In fact, I was thinking a solution for saving a template as a part could be as simple as doing just that.

For example, at the "How do you want to use this template" dialog, simply add the options to either create an inline or standalone part.

In LDCad, out-of-the-box templates are all parts but, oddly, they are not persisted in the model as such.

For the inline part, I imagine the behavior could be to write the custom part file into its parent mpd - as you can do with MPDCenter for example.

For the stand alone part, I would parameterize this with a preference setting enabling the user to define where to save custom parts. Example locations:

- unofficial library path
- unique path
- model location (default)

There is already a parts bin filter group for all parts used in the current model - which I notice also lists ldr files. This location can be optimized for custom/editable parts.

I think this approach is elegant as custom parts will have exactly the same characteristics as other parts allowing LPub3D or any other editor a singular logic to determine.

For the substitution framework, I intend to use an alias table (like annotations currently) perhaps loaded into memory on startup as this approach will be independent of editors so someone editing with MLCad or whatever can also take advantage of alternative representations.

Cheers,
Trevor

[Roland Melkert]

In LDCad, out-of-the-box templates are all parts but, oddly, they are not persisted in the model as such.

I'm not sure what you mean here.

After you use a template to make a copy into a mpd it is still considered a part even though it uses the ldr extension. It is just listed in session panel list etc because it's editable not much unlike models are.

The "0 Unofficial part" line should tell a parser its a part no matter the extension or location. The line is commonly used in many files in the wild so it has become standard practice to do so. Even more so then using "0 !LDRAW_ORG Unofficial_Part" as that implies it is due to become part of the official library at some point.

For the substitution framework, I intend to use an alias table (like annotations currently) perhaps loaded into memory on startup as this approach will be independent of editors so someone editing with MLCad or whatever can also take advantage of alternative representations.

Maybe we should invent some sort of official alias meta for these kinds of generated parts?

[Trevor Sandy]

In LDCad, out-of-the-box templates are all parts but, oddly, they are not persisted in the model as such.

I'm not sure what you mean here.

My apologies, when I refer to parts I was stupidly expecting files using the .dat extension. If I look in the LDraw "part" library official or unofficial, all part files, including the types part, subpart, primitive, 48_primitive, shortcut, alias, colour and all legacy file types, carry the .dat extension. As a result, I expected the LDraw template process to produce also a .dat file if it is the intention of the user to produce a part.

I expected .ldr files to be associated with models and submodels.

After you use a template to make a copy into a mpd it is still considered a part even though it uses the ldr extension. It is just listed in session panel list etc because it's editable not much unlike models are.

The "0 Unofficial part" line should tell a parser its a part no matter the extension or location. The line is commonly used in many files in the wild so it has become standard practice to do so. Even more so then using "0 !LDRAW_ORG Unofficial_Part" as that implies it is due to become part of the official library at some point.

I realize there are file type metas and I do code to take them into account when determining unofficial parts, but I find this approach to be less than ideal. Implementation of the file type meta seems to be without adherance to a standard so, as with LDCad, when an author uses a different meta format, I must manitain code to manage the mutation. For instruction generation, it is mainly important to distinguish between multi-component items that do not require part breakdow (i.e. parts) and those that do (i.e. models/submodels).

For me, saving a part (generated from a template) using the .dat extension enhances the human-readabilty (a key tenant of LDraw it seems) and offers an efficient alternative to unmanaged part type meta mutations.

For the substitution framework, I intend to use an alias table (like annotations currently) perhaps loaded into memory on startup as this approach will be independent of editors so someone editing with MLCad or whatever can also take advantage of alternative representations.

Maybe we should invent some sort of official alias meta for these kinds of generated parts?

I use MPDCenter as a reference as it is positioned to be the Ldraw "standard enforcer". MPDCenter has already defined Part/Unofficial_Part Alias as file types. As LDCad is the only LDraw template processor I know, perhaps it could be good to add this meta to the template part and include some reference to the master/static LDraw part id. On building the PLI, I chould check if the part is an alias representation and use its LDraw master in the PLI.

These are just my thoughts.

Cheers,

Trevor