Thinking about doing a LDCad 1.7 version


Thinking about doing a LDCad 1.7 version
#1
Hi all,

I've got some semi big (need a beta stage) features on my LDCad todo list I don't really want to do in a 1.6d/e version, namely:

- !DATA support
- !ATTACHTO support
- minor snapping and scripting extensions


So I'm thinking to do a 1.7 version instead with a couple of more things I wanted to do in 2.0. But that version is a looooooong way out.

For this I would like to include some bigger new features to really make it worth the effort.

I'm thinking about these features myself:

- Interactive animation (spin a gear to see what happens, given you scripted it to do so Big Grin  )
- Custom 'single line' bin content (to drag and drop unknown/preconfigured meta's etc). Probably as an extension to templates.

If anyone has some additional ideas this is the time to let me know.
Reply
RE: Thinking about doing a LDCad 1.7 version
#2
With !DATA support, would that allow us to work with bitmap textures directly in the program? Maybe load our own PNG files, combine with the existing functionality of your sticker generator, and make sticker parts right there in LDCad?  Big Grin

A second idea I had recently, and I don't know how trivial or complicated this would be, but is it possible to have step numbering that starts at a number other than 1? So for example, you start a new submodel and specify that its step numbering begins with Step 24 (to match official instructions)?

And I love the interactive animation idea—though in a perfect world, of course, I want to spin the gear and see what happens without knowing how to script it first.  Rolleyes
Reply
RE: Thinking about doing a LDCad 1.7 version
#3
(2020-01-13, 23:01)N. W. Perry Wrote: A second idea I had recently, and I don't know how trivial or complicated this would be, but is it possible to have step numbering that starts at a number other than 1? So for example, you start a new submodel and specify that its step numbering begins with Step 24 (to match official instructions)?

This is very easy to do in LPub3D.
Configuration ---> Build Instructions Setup... ---> Project Setup: Activate "Continous step numbers"


.png   LPub3D.PNG (Size: 15.63 KB / Downloads: 737)

Or insert following meta:
0 !LPUB CONTINUOUS_STEP_NUMBERS GLOBAL TRUE
If nothing goes right, go left.
Reply
RE: Thinking about doing a LDCad 1.7 version
#10
(2020-01-14, 7:56)Johann Eisner Wrote: This is very easy to do in LPub3D.
Configuration ---> Build Instructions Setup... ---> Project Setup: Activate "Continous step numbers"



Or insert following meta:
0 !LPUB CONTINUOUS_STEP_NUMBERS GLOBAL TRUE

OK. I don't use LPub since I don't need to generate my own instructions, but I know I can import its metas. Will LDCad know what to do with it? And this says "global"—can I apply this meta to individual submodels?
Reply
RE: Thinking about doing a LDCad 1.7 version
#17
(2020-01-14, 15:50)N. W. Perry Wrote: OK. I don't use LPub since I don't need to generate my own instructions, but I know I can import its metas. Will LDCad know what to do with it? And this says "global"—can I apply this meta to individual submodels?

I've been thinking about fully supporting LPub meta's ?(including the inventory balloons etc) for 2.0, but It might be too big a thing for 1.7

Maybe a light version where only the step numbering gets applied, still need to research al the LPub meta's though.

On that note does anyone have a good reference on the LPub(3d) meta's?
Reply
RE: Thinking about doing a LDCad 1.7 version
#24
(2020-01-13, 23:01)N. W. Perry Wrote: And I love the interactive animation idea—though in a perfect world, of course, I want to spin the gear and see what happens without knowing how to script it first. 

Yes, why should I have to know how to script?
Reply
RE: Thinking about doing a LDCad 1.7 version
#25
(2020-01-14, 22:18)Magnus Forsberg Wrote: Yes, why should I have to know how to script?

Because it's extremely difficult to create a true mechanical simulator, things will always only work partial.

Also I want it to be able to do things like move a minifig lever to open a door or something, things that aren't really connected.

This way you could make a full blown "Point and click" adventure game or something Smile
Reply
RE: Thinking about doing a LDCad 1.7 version
#4
Include the themes: https://forums.ldraw.org/thread-23675.html

and make the gray one the default theme.

w.
LEGO ergo sum
Reply
RE: Thinking about doing a LDCad 1.7 version
#5
(2020-01-14, 9:10)Willy Tschager Wrote: Include the themes: https://forums.ldraw.org/thread-23675.html
and make the gray one the default theme.
+1...
Reply
RE: Thinking about doing a LDCad 1.7 version
#18
(2020-01-14, 9:10)Willy Tschager Wrote: Include the themes: https://forums.ldraw.org/thread-23675.html

If Miguel is ok with it I'll include it.

(2020-01-14, 9:10)Willy Tschager Wrote: and make the gray one the default theme.

The default theme used to be grey.

   

People complaint so I changed it to mimic LEGO booklets.

People still complained  Big Grin

But I'm happy to add the option.
Reply
RE: Thinking about doing a LDCad 1.7 version
#6
Installable stuff with integrated interface?
- Set inventories
- Custom templates
- Custom connectivity
Reply
RE: Thinking about doing a LDCad 1.7 version
#19
(2020-01-14, 9:17)Philippe Hurbain Wrote: Installable stuff with integrated interface?
- Set inventories
- Custom templates
- Custom connectivity

This is at the core of 2.0 where I've setup a 'package' system. It's also the reason for it's slow development as I'm not happy with it's current incarnation.

Might be able to set something simple up using additional .sf (==zip) files though.
Reply
RE: Thinking about doing a LDCad 1.7 version
#7
I would very much like to see the support or display of information that comes with the !HELP and !CMDLINE metas.

The data is in the files, but to get to this data (during building) seems difficult i.e. impossible.
Reply
RE: Thinking about doing a LDCad 1.7 version
#20
(2020-01-14, 13:17)Gerald Lasser Wrote: I would very much like to see the support or display of information that comes with the !HELP and !CMDLINE metas.

The data is in the files, but to get to this data (during building) seems difficult i.e. impossible.

Good one.

Maybe trough a small "?" icon in the bin cells which open a hint panel on mouse over?
Reply
RE: Thinking about doing a LDCad 1.7 version
#8
A couple of things (in order of my perceived difficulty to implement):
- The sync name and filename option in the header dialog should be the default
- Please move the Export submenu from Views->Editing Views to the File menu
- Have all the nodes in the source window automatically collapse when exiting nested mode
- I'd like a "reload data" menu option that forces LDCad to reload templates, donors, the parts bin, and pbg files without having to close and reopen LDCad itself.
- An all-in-one, duplicate and mirror subfile option would be a nice to have
Reply
RE: Thinking about doing a LDCad 1.7 version
#11
(2020-01-14, 14:57)Orion Pobursky Wrote: - I'd like a "reload data" menu option that forces LDCad to reload templates, donors, the parts bin, and pbg files without having to close and reopen LDCad itself.

+1 for that! I'm often tweaking my parts bins in TextEdit and there's no way to see the changes in LDCad without exiting the program.
Reply
RE: Thinking about doing a LDCad 1.7 version
#13
(2020-01-14, 14:57)Orion Pobursky Wrote: - Have all the nodes in the source window automatically collapse when exiting nested mode
- I'd like a "reload data" menu option that forces LDCad to reload templates, donors, the parts bin, and pbg files without having to close and reopen LDCad itself.
+1!
Reply
RE: Thinking about doing a LDCad 1.7 version
#21
(2020-01-14, 14:57)Orion Pobursky Wrote: - The sync name and filename option in the header dialog should be the default
You can set the name sync to default by checking the "Add name to new models" option in any header dialog.

(2020-01-14, 14:57)Orion Pobursky Wrote: - Please move the Export submenu from Views->Editing Views to the File menu
I'll move it as more people seem to have a problem finding it.

(2020-01-14, 14:57)Orion Pobursky Wrote: - Have all the nodes in the source window automatically collapse when exiting nested mode
I'll make it an option.

(2020-01-14, 14:57)Orion Pobursky Wrote: - I'd like a "reload data" menu option that forces LDCad to reload templates, donors, the parts bin, and pbg files without having to close and reopen LDCad itself.
This is a tough one but I'll look into it.

(2020-01-14, 14:57)Orion Pobursky Wrote: - An all-in-one, duplicate and mirror subfile option would be a nice to have
Shouldn't be a problem.
Reply
RE: Thinking about doing a LDCad 1.7 version
#30
Roland Melkert Wrote:
(2020-01-14, 14:57)Orion Pobursky Wrote: - An all-in-one, duplicate and mirror subfile option would be a nice to have
Shouldn't be a problem.

It would be really cool if you could select a subfile and have have LDCad create a new, mirrored subfile. Even cooler would be if you could have it recurse through the child subfiles and mirror them too.
Reply
RE: Thinking about doing a LDCad 1.7 version
#9
(2020-01-13, 20:41)Roland Melkert Wrote: - !DATA support
- !ATTACHTO support

Since both:

https://forums.ldraw.org/thread-23756.html
https://forums.ldraw.org/thread-23683.html

haven't been ratified by the LSB I wonder what your plans are? I would appreciate if you could bring them to a happy ending.

w.
LEGO ergo sum
Reply
RE: Thinking about doing a LDCad 1.7 version
#16
(2020-01-14, 15:41)Willy Tschager Wrote: Since both:

https://forums.ldraw.org/thread-23756.html
https://forums.ldraw.org/thread-23683.html

haven't been ratified by the LSB I wonder what your plans are? I would appreciate if you could bring them to a happy ending.

I wanted to do some experimenting to see if the proposals are rectify worthy.

Especially with the !DATA one I would like to get the feel of things, programming wise, before voting on it.
Reply
RE: Thinking about doing a LDCad 1.7 version
#26
Agreed. Always good to experiment before setting things in tablets of stone!!!
Reply
RE: Thinking about doing a LDCad 1.7 version
#12
(2020-01-13, 20:41)Roland Melkert Wrote: If anyone has some additional ideas this is the time to let me know.

A option in the Clean up... menu, for the file type. (! LDRAW_ORG Model, ! LDRAW_ORG Unofficial Model)
to easier OMRize a file.
If nothing goes right, go left.
Reply
RE: Thinking about doing a LDCad 1.7 version
#14
(2020-01-14, 16:13)Johann Eisner Wrote: A option in the Clean up... menu, for the file type. (! LDRAW_ORG Model, ! LDRAW_ORG Unofficial Model)
to easier OMRize a file.

+1, and/or an option to include this with the header defaults.
Reply
RE: Thinking about doing a LDCad 1.7 version
#22
(2020-01-14, 16:13)Johann Eisner Wrote: A option in the Clean up... menu, for the file type. (! LDRAW_ORG Model, ! LDRAW_ORG Unofficial Model)
to easier OMRize a file.

I'll add a "Force LDraw model type" combo with "No change", "Offical", "Onoffical" options.

But I believe the OMR site also changes them automatically.
Reply
RE: Thinking about doing a LDCad 1.7 version
#27
(2020-01-14, 20:53)Roland Melkert Wrote: But I believe the OMR site also changes them automatically.

I just tested now, the OMR site change nothing.
If nothing goes right, go left.
Reply
RE: Thinking about doing a LDCad 1.7 version
#15
An indicator (* after file name in LDCad window bar as usual?) that current file has been modified and needs to be saved?
Reply
RE: Thinking about doing a LDCad 1.7 version
#23
(2020-01-14, 19:05)Philippe Hurbain Wrote: An indicator (* after file name in LDCad window bar as usual?) that current file has been modified and needs to be saved?

Seems trival but it will not change back to "unchanged" after undo.
Reply
RE: Thinking about doing a LDCad 1.7 version
#28
(2020-01-14, 20:40)Roland Melkert Wrote: If Miguel is ok with it I'll include it.

Absolutely! Let me know if you need extra images to complete it. And if you could also implement the feature of full screen editing with no titlebar I would appreciate. It's always extra space for editing.

From the top of my mind I can remember a few things that I would love to see in 1.7. And please excuse me if some are already available. It always amazes me when someone asks for a feature and Roland just replies: "It already can be achieved by doing this and that... "
  1. Keyword search in Hotkey config! PLEASE! 
  2. Export BOM to csv/HTML (I can help with the HTML formatting and retrieving of the parts images from the web)
  3. Export MPD to a single/multiple LDR file
  4. More OpenGL/LDraw rendering tweaks. I hate the problem with tile 1x1 with rounded end. [Image: sad.png]
  5. Extra info in source window, with toggle icons for color and show/hide, that when click on them would allow you to change those properties. But specially, one of the things I really like in stud.io, that would give you a warning if that part does not exist in that particular color. 
Thank you for this opportunity.
Reply
RE: Thinking about doing a LDCad 1.7 version
#29
(2020-01-15, 16:49)Miguel Reizinho Wrote: Absolutely! Let me know if you need extra images to complete it. And if you could also implement the feature of full screen editing with no titlebar I would appreciate. It's always extra space for editing.
Thanks, you don't have to replace all images, recent versions will use images from the default template when they are missing in the second folder.


(2020-01-15, 16:49)Miguel Reizinho Wrote: Keyword search in Hotkey config! PLEASE! 
I'll will add this. Don't know why I haven't already as the menu editing dialog has one too.


(2020-01-15, 16:49)Miguel Reizinho Wrote: Export BOM to csv/HTML (I can help with the HTML formatting and retrieving of the parts images from the web)
There is a basic csv export of the bin content (new in 1.6c) you could process that into anything you want.
That said a simple html export might be fun too, but many people will probably want to tweak it afterwards so I'm not sure.


(2020-01-15, 16:49)Miguel Reizinho Wrote: Export MPD to a single/multiple LDR file
This can be done by copy in nested mode and then paste into a new model.

There are tools for splitting mpd's but most of them work trough the selection.
Maybe I'll add a generic dialog for mass import/export of mpd/mul ldr.


(2020-01-15, 16:49)Miguel Reizinho Wrote: More OpenGL/LDraw rendering tweaks. I hate the problem with tile 1x1 with rounded end. [Image: sad.png]
That's a tough one, but thanks for reminding of this issue as I totally forgot about it Smile


(2020-01-15, 16:49)Miguel Reizinho Wrote: Extra info in source window, with toggle icons for color and show/hide, that when click on them would allow you to change those properties. But specially, one of the things I really like in stud.io, that would give you a warning if that part does not exist in that particular color. 
Visible/color icons are a nice idea, I'll look into that.

Available colors is something I wanted to integrate in the color wheel for awhile (using a special group).

But it needs some kind of db, and I don't really want to make lots of net requests getting them. My latest idea was to add it to the shadow library.
Reply
RE: Thinking about doing a LDCad 1.7 version
#31
Speaking of color wheel, something I miss is a search function, similar to to level part bin search ..
Reply
RE: Thinking about doing a LDCad 1.7 version
#32
(2020-01-17, 6:29)Philippe Hurbain Wrote: Speaking of color wheel, something I miss is a search function, similar to to level part bin search ..
+1 

I know that we can search by LDraw color number, but don't know this by heart. It would help if we could search by the terms "Light Bluish" instead of just 71
Reply
RE: Thinking about doing a LDCad 1.7 version
#42
(2020-01-17, 6:29)Philippe Hurbain Wrote: Speaking of color wheel, something I miss is a search function, similar to to level part bin search ..
Me too! If I need something that isn't one of the dozen colours I have in my Favourites, I usually have to go through each wheel hovering over the ones that look vaguely right - and that can take quite a while sometimes!
Reply
RE: Thinking about doing a LDCad 1.7 version
#43
(2020-01-17, 6:29)Philippe Hurbain Wrote: Speaking of color wheel, something I miss is a search function, similar to to level part bin search ..

Something like this?

   

It's only a 'paint' doodle for now though.
Reply
RE: Thinking about doing a LDCad 1.7 version
#48
(2020-01-20, 20:36)Roland Melkert Wrote: Something like this?
Yes. Also needs an "all colors" bin to allow search on all colors.
Reply
RE: Thinking about doing a LDCad 1.7 version
#49
(2020-01-21, 6:04)Philippe Hurbain Wrote: Yes. Also needs an "all colors" bin to allow search on all colors.

Why not just use an enhanced version of the input dialog, with option to search by color number or name, that appears when you click on the color name? It's probably easier to program.

[Image: Untitled.png]
Reply
RE: Thinking about doing a LDCad 1.7 version
#50
But this would not be consistent with part bin implementation, and filter allows for example to show all "blue" colors and let you choose.
Reply
RE: Thinking about doing a LDCad 1.7 version
#51
(2020-01-21, 16:07)Philippe Hurbain Wrote: But this would not be consistent with part bin implementation, and filter allows for example to show all "blue" colors and let you choose.
You are right, the behaviour would be different.
Reply
RE: Thinking about doing a LDCad 1.7 version
#52
(2020-01-21, 16:26)Miguel Reizinho Wrote: You are right, the behaviour would be different.

I prefer to make it as much the same as the filter in the part bin. So there will also be a special 'search' group for the color bin which initially shows nothing until you enter a filter.

Only thing I'm still not sure about is the space it takes, as it's not always needed and I kinda liked the minimal sized color window. Making it opitional is kinda tough because the 1.x gui rendering is currently very static (2.0 is basically a html like engine whom handles 'div' sections )
Reply
RE: Thinking about doing a LDCad 1.7 version
#53
(2020-01-21, 19:53)Roland Melkert Wrote: I prefer to make it as much the same as the filter in the part bin. So there will also be a special 'search' group for the color bin which initially shows nothing until you enter a filter.

Only thing I'm still not sure about is the space it takes, as it's not always needed and I kinda liked the minimal sized color window. Making it opitional is kinda tough because the 1.x gui rendering is currently very static (2.0 is basically a html like engine whom handles 'div' sections )

Perhaps a dropdown list for v2.0? I really like the color pallete from stud.io. It's very pratical and I would welcome something similiar in LDCaad. It has ability to filter/search, the colors are sorted alphabetically and by type (solid, metalic, transparent), and has a left vertical toolbar where you can see color groups and click on it to see only colors of that particular hue (in the image, the magenta color group was selected):

[Image: studio.png]


In MLCad I used to have the colors on a vertical toolbar to save up some space:

[Image: mlcad.png]
Reply
RE: Thinking about doing a LDCad 1.7 version
#33
(2020-01-16, 23:15)Roland Melkert Wrote: There is a basic csv export of the bin content (new in 1.6c) you could process that into anything you want.
I use that. But then I have to rework it through a Google spreadsheet of mine so I can get the correspondent BL ID and BL Color from the LDraw parts and colors AND combine both to get the LEGO element ID so I can retrieve the correspondent image. It's a complicated process that uses Brickset API for parts information and Ryan Howerter color chart.

You can get the parts info from this URL: https://brickset.com/exportscripts/parts
And color Chart from here: http://ryanhowerter.net/colors.html

Right now it's almost 41.000 different parts and that makes the whole process slow and tiresome.

You can check the file HERE if you are curious. Just enter a LEGO ID (on column B) or a combination of BL ID and BL Color (on columns D and E) to see magic happens

(2020-01-16, 23:15)Roland Melkert Wrote: This can be done by copy in nested mode and then paste into a new model.
Wow! Like I said: it's always amazing to learn something new about LDCad  Smile

(2020-01-16, 23:15)Roland Melkert Wrote: That's a tough one, but thanks for reminding of this issue as I totally forgot about it
Argh! This drives me so mad that I even thought about having my own modified 24246.dat file to prevent this problem (@Philo? hint, hint. nudge, nudge?)
Reply
RE: Thinking about doing a LDCad 1.7 version
#34
Dunno exactly what are your BOM needs. If you need info like BL numbers, it will need an external database anyway. But if you only want a BOM with images, MPDCenter can do that (information->inventory). It uses LDView BOM engine, but pushes it a bit further to generate part thumbnail. That said, I am not against seeing a html BOM generator built in LDCad Big Grin

(2020-01-17, 12:36)Miguel Reizinho Wrote: Argh! This drives me so mad that I even thought about having my own modified 24246.dat file to prevent this problem (@Philo? hint, hint. nudge, nudge?)
Actually this part has been "fixed" for some time, but still on PT, see https://www.ldraw.org/cgi-bin/ptdetail.c...246s01.dat
But a LDCad shading improvement of con0 would be great for some other parts, such as Fabuland torso...
Reply
RE: Thinking about doing a LDCad 1.7 version
#35
(2020-01-17, 13:17)Philippe Hurbain Wrote: Actually this part has been "fixed" for some time, but still on PT, see https://www.ldraw.org/cgi-bin/ptdetail.c...246s01.dat
But a LDCad shading improvement of con0 would be great for some other parts, such as Fabuland torso...

These problem areas all have a single point (shared among many) touching a type 2 line.

So I think the main problem has do with the code only using two shared type 2 points among polygons to generate additional vertices.

I'll have to dig deeper into the code to fully understand the main problem myself, as it's been awhile since I last visited that part of the source Shy
Reply
RE: Thinking about doing a LDCad 1.7 version
#39
(2020-01-17, 13:17)Philippe Hurbain Wrote: Actually this part has been "fixed" for some time, but still on PT, see https://www.ldraw.org/cgi-bin/ptdetail.c...246s01.dat

Thank you for pointing it out! Updated with unofficial subfiles. I'm very happy.   Shy
Reply
RE: Thinking about doing a LDCad 1.7 version
#36
.. what I would like to see:

- small, in shades of gray - which are displayed in a row directly at the top of the editing window

* Bullseye symbol will switch to the central view of the object
* Split window icon - popup as usual
* Cam icon - popup as usual

..then you no longer have to sway through the current "edit views" ... more intuitive, effective and efficient.

apropos - I would find an independent rubric "Export" and "Render" more clearly.

that would be absolutely "trés chic"
Reply
RE: Thinking about doing a LDCad 1.7 version
#38
I think that most can be accomplished with hotkey configs.

(2020-01-19, 20:53)Ulrich Röder Wrote: * Bullseye symbol will switch to the central view of the object
Group: edit window
Subgroup: view
Command: Center the selection in the current view
Key: C

when I press "C", the part selected is centered on view.

Use it together with command right bellow that one: "Center and zoom content in order to fit it inside current view"

With these two hotkeys I think you will be able to achieve what you want.

Quote:* Split window icon - popup as usual
Group: edit window
Subgroup: split
Command: Switch between (temporary) single/multi views
Key: SPACE


Quote:* Cam icon - popup as usual
I don't know if I understood correctly your request, but if your talking about changing view to cam, you can also use hotkeys

Group: edit window
Subgroup: option
Command: Switch between perspective and orthographic projection
Key: V
Reply
RE: Thinking about doing a LDCad 1.7 version
#47
(2020-01-19, 21:30)Miguel Reizinho Wrote: I think that most can be accomplished with hotkey configs.

Group: edit window
Subgroup: view
Command: Center the selection in the current view
Key: C

when I press "C", the part selected is centered on view.

Use it together with command right bellow that one: "Center and zoom content in order to fit it inside current view"

With these two hotkeys I think you will be able to achieve what you want.

Group: edit window
Subgroup: split
Command: Switch between (temporary) single/multi views
Key: SPACE


I don't know if I understood correctly your request, but if your talking about changing view to cam, you can also use hotkeys

Group: edit window
Subgroup: option
Command: Switch between perspective and orthographic projection
Key: V


... yes, of course ... but ... exactly how you describe the whole processes, you have to muddle through yourself with several (to much) "clicks" to the goal ..

that's exactly what I want to shorten to a minimum with my proposal..

two "clicks"...and you are ready....with a mouse movement of perhaps two seconds!!

Efficient and effective!
Reply
RE: Thinking about doing a LDCad 1.7 version
#37
forgot to mention:

keepin pressed Ctrl button while moving selected part/parts results in a copy - a feature like it is known in MLCad
Reply
RE: Thinking about doing a LDCad 1.7 version
#44
(2020-01-19, 21:21)Ulrich Röder Wrote: forgot to mention:

keepin pressed Ctrl button while moving selected part/parts results in a copy - a feature like it is known in MLCad

I'll check MLCad's behavior, but I think ctrl+d (duplicate) does this already.
Reply
RE: Thinking about doing a LDCad 1.7 version
#46
(2020-01-20, 20:39)Roland Melkert Wrote: I'll check MLCad's behavior, but I think ctrl+d (duplicate) does this already.

....for sure ctrl+d works...I know..what I want to say is..that the other method is more handy....the hand stays on the mouse....press ctrl with the other..and track it...it' s more efficient and easier.
Reply
RE: Thinking about doing a LDCad 1.7 version
#40
Just a quick mockup of some icons in the source window:

- color indicators
- step indicators
- comment indicators
- warning indicator (for instance, for part not available in that color)

[Image: Untitled-1.png]

You can see the image in full size by clicking on it. You can also check an animated GIF by clicking HERE.

Also added the "*" at the end of the filename for file not saved but added it to the session manager window since I'm using the noTitleBar addon
Reply
RE: Thinking about doing a LDCad 1.7 version
#45
(2020-01-19, 21:52)Miguel Reizinho Wrote: Just a quick mockup of some icons in the source window:

.....

Also added the "*" at the end of the filename for file not saved but added it to the session manager window since I'm using the noTitleBar addon

Looks nice, I think I'm going to at least add the color icons (will be optional).

Speaking of the session manager window, I'm thinking of dropping the menu list of open models, replacing it by a dialog which can also do some mpd management etc. This will also work better with the new !DATA content.
Reply
RE: Thinking about doing a LDCad 1.7 version
#41
(2020-01-13, 20:41)Roland Melkert Wrote: If anyone has some additional ideas this is the time to let me know.

Two little things that had come up in other threads (these are just reminders, since you'd mentioned wanting to add them to the next release):
-Adding the !THEME meta to the header dialog
-Lowering the minimum value for bezier control points in flexible paths (to allow tighter knots, for example)
Reply
RE: Thinking about doing a LDCad 1.7 version
#54
(2020-01-13, 20:41)Roland Melkert Wrote: So I'm thinking to do a 1.7 version instead with a couple of more things I wanted to do in 2.0. But that version is a looooooong way out.
....
If anyone has some additional ideas this is the time to let me know.
This is great message, Roland, thanks a lot.

The top of my wishlist (filtered for features hopefully doable in 1.7, without full code rewrite in 2.0):

* color bin: textual color search - exactly as it is described in this thread
* color bin: "special color bins" similar to special part bins: colors in current (sub)model, colors in all the mpd of current (sub)model - makes model editing much faster
* performance: maintain the list of "open" snap points (objects) so only those snap points "on the model surface" are counted. Typical example: moving more complex submodel in the main model. This makes my computer completely overloaded today.
* UI: avoid that big jump when moving some submodel or part with hotkeys (in coordinate system) and then trying to fine-tune the place with a mouse. For me, this is the most annoying feature of LDCAD, esp. because I need this workflow when my computer is nearly frozen because of the problem in previous point.
* documentation of scripting language: full documentation of LDCAD API plus some howtos or tutorials. This is missing so much!! It should be probably the point on the top.
Reply
RE: Thinking about doing a LDCad 1.7 version
#55
(2020-01-22, 12:54)Milan Vančura Wrote: <snip>
* documentation of scripting language: full documentation of LDCAD API plus some howtos or tutorials. This is missing so much!! It should be probably the point on the top.
Yeah but nobody wants to write documentation when there are fun features to develop!
Reply
RE: Thinking about doing a LDCad 1.7 version
#56
(2020-01-23, 6:30)Owen Dive Wrote: Yeah but nobody wants to write documentation when there are fun features to develop!
Sure! one thing that could be done while (perhaps) not beeing too tedious would be to provide some simple scripting examples (like a 3 gears geartrain, a 4 bars linkage or a rack and pinion steering). All these exemples are already provided in existing scripts, but are included in overwhelmingly complex models and scripts.
Reply
RE: LDCad 1.7 version: flex parts control points
#57
(2020-01-13, 20:41)Roland Melkert Wrote: If anyone has some additional ideas this is the time to let me know.
- It would be very nice if the bezier handles were visible during control point move (after duplication with insert). That would greatly help to figure out current orientation.
- I still find that control points arrows are too thin. If they were 3 pixels wide instead of just one they would be more visible and easier to select (so many times I select the part behind...)
- Wondering if an "average" function would make sense. It would orient a control point to follow a smooth path between previous and next control points.
Reply
RE: LDCad 1.7 version: flex parts control points
#58
(2020-02-05, 14:34)Philippe Hurbain Wrote: - Wondering if an "average" function would make sense. It would orient a control point to follow a smooth path between previous and next control points.
I'm not sure what you mean here.

I wrote the LDCad code based on this information:

https://en.wikipedia.org/wiki/B%C3%A9zier_curve

Specifically the first one in the 'Higher-order curves' section.

Or do you mean the "Quadratic curves" one, which only have a single control point.
Reply
RE: LDCad 1.7 version: flex parts control points
#59
Here is the idea I have in mind:
   
Sensor, plug and blue brick are fixed, but of course the cable must avoid the brick. When I insert a new control point to get around the brick, I end up in the middle configuration, with a pinch in the cable. The "control point" smoothing function would somehow average (with some weighting depending on distance) the other two control points directions in order to set a "plausible" direction and twist.
Reply
RE: Thinking about doing a LDCad 1.7 version
#60
Could you maybe add a special "View" mode, where all controls are for moving the viewpoint and we cannot accidentally touch and alter a part? Thanks.
Reply
RE: Thinking about doing a LDCad 1.7 version
#61
(2020-02-11, 2:26)Michael Horvath Wrote: Could you maybe add a special "View" mode, where all controls are for moving the viewpoint and we cannot accidentally touch and alter a part? Thanks.
The view mode is already there. Click on the name of model on top right of edit window and select "view" tab.
Reply
RE: Thinking about doing a LDCad 1.7 version
#62
I've noticed that sometime when I snap something (especially a bunch of things at once) to grid or reset the orientation that it doesn't snap all the way but instead gets very close (the largest error I've seen is 0.01 on position, the matrix is usually super close like 0.0001)
Reply
RE: Thinking about doing a LDCad 1.7 version
#65
(2020-02-19, 0:48)Orion Pobursky Wrote: I've noticed that sometime when I snap something (especially a bunch of things at once) to grid or reset the orientation that it doesn't snap all the way but instead gets very close (the largest error I've seen is 0.01 on position, the matrix is usually super close like 0.0001)

Precision has always been an issue even while using all double precision variables.

The main reason is the mutation is applied as a 'difference' to all the parts in the selection.

So if the main part in the selection has been mutated a lot (or is read from low decimal count file) the rounding errors will be amplified.

Alternative might be to use 'snap all to edit grid plane' from the placement menu.
Reply
RE: Thinking about doing a LDCad 1.7 version
#96
(2020-02-24, 18:41)Roland Melkert Wrote: Precision has always been an issue even while using all double precision variables.

The main reason is the mutation is applied as a 'difference' to all the parts in the selection.

So if the main part in the selection has been mutated a lot (or is read from low decimal count file) the rounding errors will be amplified.

Alternative might be to use 'snap all to edit grid plane' from the placement menu.

I've noticed something even stranger…I just spent a bunch of time cleaning up all the rounding errors in a model with lots of rotation in it, and the simple act of closing and then reopening the program seems to have reintroduced them. It's just a .001 difference, but it means that mirrored pairs of parts might have different decimal values, for example. (Note that I'm referring to relative positions here—the file code hasn't changed so the absolute decimal values are all still correct.)

So what causes the change from simply closing and reopening the file?
Reply
RE: Thinking about doing a LDCad 1.7 version
#97
(2020-04-23, 5:34)N. W. Perry Wrote: I've noticed something even stranger…I just spent a bunch of time cleaning up all the rounding errors in a model with lots of rotation in it, and the simple act of closing and then reopening the program seems to have reintroduced them. It's just a .001 difference, but it means that mirrored pairs of parts might have different decimal values, for example. (Note that I'm referring to relative positions here—the file code hasn't changed so the absolute decimal values are all still correct.)

So what causes the change from simply closing and reopening the file?

I think, and Roland can confirm, that LDCad keeps the full precision for each part's position and matrix in memory as long as the file is open. This practice makes sense to me since it will cut down on rounding errors while you are actively editing the model. Once you close the model, the full precision info is lost and LDCad has to rely on the precision written to the LDraw file itself.
Reply
RE: Thinking about doing a LDCad 1.7 version
#98
(2020-04-23, 15:02)Orion Pobursky Wrote: I think, and Roland can confirm, that LDCad keeps the full precision for each part's position and matrix in memory as long as the file is open. This practice makes sense to me since it will cut down on rounding errors while you are actively editing the model. Once you close the model, the full precision info is lost and LDCad has to rely on the precision written to the LDraw file itself.

Good, that's what I was guessing as well—that calculating from the coded values gives a different result than applying the series of mutations I make while editing.

As a follow-up, then, it seems I might be doing something backwards. When adding new parts to a rotated assembly, I first snap to grid and reset orientation of the new part (on the relative orientation of course), then move it into place using part snapping. I should probably snap to grid after moving the part into place, huh?
Reply
RE: Thinking about doing a LDCad 1.7 version
#99
(2020-04-23, 15:02)Orion Pobursky Wrote: I think, and Roland can confirm, that LDCad keeps the full precision for each part's position and matrix in memory as long as the file is open. This practice makes sense to me since it will cut down on rounding errors while you are actively editing the model. Once you close the model, the full precision info is lost and LDCad has to rely on the precision written to the LDraw file itself.

Indeed. Internally all matrices are stored using c++'s double variables.

The mesh vectors are stored as single so they can go '1 on 1' to OpenGL. But matrices are only converted to single floating point for use with OpenGL at the very last moment (while keeping the double as the master).

All matrix file io is double too.

I've experimented with re-normalizing the rotation part of matrices during loading but that made thing worse in certain circumstances.

I've also played around with recognizing common matrix values (0.707 etc) to do substitution, but this too isn't fool proof.

The only real solution would be to store more digits or even the whole double precision content as a string (so it would translate back to the same binary content)



(2020-04-23, 16:56)N. W. Perry Wrote: Good, that's what I was guessing as well—that calculating from the coded values gives a different result than applying the series of mutations I make while editing.

As a follow-up, then, it seems I might be doing something backwards. When adding new parts to a rotated assembly, I first snap to grid and reset orientation of the new part (on the relative orientation of course), then move it into place using part snapping. I should probably snap to grid after moving the part into place, huh?

If you snap to the global grid after positioning something on a relative one you will get visual errors. Or do you mean snapping to the relative grid? If so that might also introduce rounding errors as the relative grid does some matrix operations of its own.

The best way to keep clean numbers in your files is by avoiding rotated assemblies of loose parts. Instead use submodels so only one reference line will have those nasty digits. This might not be an option in technic models though.
Reply
RE: Thinking about doing a LDCad 1.7 version
(2020-04-23, 19:07)Roland Melkert Wrote: The only real solution would be to store more digits or even the whole double precision content as a string (so it would translate back to the same binary content)

Which, I assume, would mean storing that string in a meta tag, or maybe as shadow content?

Quote:If you snap to the global grid after positioning something on a relative one you will get visual errors. Or do you mean snapping to the relative grid? If so that might also introduce rounding errors as the relative grid does some matrix operations of its own.

I did mean relative, but I see now what you mean. I tried snapping to grid after placing the part, and it does result in more rounding errors. I thought at first it was giving me the same result as closing and re-opening the file, but it actually seems to be even more than that.

Quote:The best way to keep clean numbers in your files is by avoiding rotated assemblies of loose parts. Instead use submodels so only one reference line will have those nasty digits. This might not be an option in technic models though.

That's an option indeed. But since I use submodels for organizational reasons, I think for my purposes that's more important than this precision issue. I think as long as I place everything correctly before exiting the file, I'll know that the saved values are as clean and precise as they should be, which will be good enough for me. (I just have to avoid the urge to check the relative positions again after re-opening the file!)  Tongue
Reply
RE: Thinking about doing a LDCad 1.7 version
(2020-04-24, 0:16)N. W. Perry Wrote: Which, I assume, would mean storing that string in a meta tag, or maybe as shadow content?
No I meant like
0.637276437432e-22
but 3 digits is considered 'normal' behaviour.

(2020-04-24, 0:16)N. W. Perry Wrote: That's an option indeed. But since I use submodels for organizational reasons, I think for my purposes that's more important than this precision issue. I think as long as I place everything correctly before exiting the file, I'll know that the saved values are as clean and precise as they should be, which will be good enough for me. (I just have to avoid the urge to check the relative positions again after re-opening the file!)  Tongue
you could also try increasing the
modelFileDecCnt
setting in main.cfg
Reply
RE: Thinking about doing a LDCad 1.7 version
(2020-04-24, 2:33)Roland Melkert Wrote: No I meant like
0.637276437432e-22
but 3 digits is considered 'normal' behaviour.

you could also try increasing the
modelFileDecCnt
setting in main.cfg

Undecided…interesting. I think I'm at a good place for now, but will definitely keep this option in mind. Does the decimal count persist once it's saved in a file, or would LDCad overwrite the coded values if I opened and re-saved a file with different precision?
Reply
RE: Thinking about doing a LDCad 1.7 version
(2020-04-24, 17:04)N. W. Perry Wrote: I think I'm at a good place for now
Probably best you don't want to fall in the rabbit hole known as the wonderful world of floating point precision Smile


(2020-04-24, 17:04)N. W. Perry Wrote: Does the decimal count persist once it's saved in a file, or would LDCad overwrite the coded values if I opened and re-saved a file with different precision?

The option only affects writing of files, reading will always use up to 19 decimal points.

The 19 comes from the maximum power of 10 in a 64 bit integer which is used to store the number after the dot before it's converted to double.
Reply
RE: Thinking about doing a LDCad 1.7 version
(2020-04-24, 19:26)Roland Melkert Wrote: Probably best you don't want to fall in the rabbit hole known as the wonderful world of floating point precision Smile

Yeah…my fear is that I switch to 5 decimal places, and now I'm haunted by rounding errors that are .00001 instead of just .001!  Big Grin

Quote:The option only affects writing of files, reading will always use up to 19 decimal points.

The 19 comes from the maximum power of 10 in a 64 bit integer which is used to store the number after the dot before it's converted to double.

So, if I were to switch from say, 3 to 5 places, and I save a new file…then later I decide to go back to 3 places and re-save that file, it would round all the values down? (I suppose I could just try and see what happens.)
Reply
RE: Thinking about doing a LDCad 1.7 version
(2020-04-24, 23:29)N. W. Perry Wrote: Yeah…my fear is that I switch to 5 decimal places, and now I'm haunted by rounding errors that are .00001 instead of just .001!  Big Grin


So, if I were to switch from say, 3 to 5 places, and I save a new file…then later I decide to go back to 3 places and re-save that file, it would round all the values down? (I suppose I could just try and see what happens.)

Only lines that where mutated during the editing of the file as LDCad preservers all lines it didn't change.
Reply
RE: Thinking about doing a LDCad 1.7 version
#63
I'd like to see a configurable keyboard shortcut that would open the part bin display filter regardless of where the mouse is.  I'm usually finding parts by entering a part number in the filter, and having to mouse over the parts bin to open the filter feels slow.  Thanks for considering it!
Reply
RE: Thinking about doing a LDCad 1.7 version
#66
(2020-02-19, 20:23)Hendrix Wrote: I'd like to see a configurable keyboard shortcut that would open the part bin display filter regardless of where the mouse is.  I'm usually finding parts by entering a part number in the filter, and having to mouse over the parts bin to open the filter feels slow.  Thanks for considering it!

F3 works while the mouse is inside the bin instead of just the filter text box area.

And if you want a global key you could make that happen by writing a small macro, like:

Code:
function runBinSrc()
  local act=ldc.action('partBinWin_filterOpen');
  act:run()
end

function register()
  local macro=ldc.macro('Global bin src')
  macro:setEvent('run', 'runBinSrc')
  macro:setHint("Open the filter dialog of the last used part bin.")
end

And then assign F3 to that macro using the hotkey configuration dialog (right click on the tool bar).
Reply
RE: Thinking about doing a LDCad 1.7 version
#64
I don't know if anybody have this wish already,
but a german language package would be nice. 😉
Maybe in the 2.0 Version.
If nothing goes right, go left.
Reply
RE: Thinking about doing a LDCad 1.7 version
#67
(2020-02-20, 15:07)Johann Eisner Wrote: I don't know if anybody have this wish already,
but a german language package would be nice. 😉
Maybe in the 2.0 Version.

2.0 will be language independent but that version is a long way out.

1.x uses mostly central constants for all non dialog texts so if someone translated that it would be possible to compile a German version. But all the dialogs will still be English.
Reply
RE: Thinking about doing a LDCad 1.7 version
#68
Bug 
Some ideas:

Eye view - the ability to move the camera as if you're in a first person game, this will make it easier to go into tight spaces such as a room in a  house and inspect building errors etc. The movement could be tied to the grid stepping.

The ability to select all parts of a given type or color does exist but only if you assign a keyboard hotkey for 'select working part' or 'select working color' and then holding shift when you want to do 'select working part' / 'select working color' a second time. But shift does not work with the menu item, only a hotkey so maybe add shift support to the menu item and also assign a keyboard shortcut by default for 'select working part/color' because it is used super often.

Also a 'select all connected parts' like in LDD would be cool.

The ability to rotate multiple bricks but where they have their own rotation centers instead of a single rotation center where everything else selected orbits that.

A secondary color ootion like in MSpaint by right clicking on a color square in the color menu and having a second long square telling you the currently selected secondary color.

Also the ability to automatically align another part to a part with a diagonaal edge like a wing plate. example

A new 'node view' editing pane like in the following video for auto generating parametric structures like in grasshoooer/blender: https://youtu.be/8TFrz2eWyB0?t=865

Regards, SNIPE
Reply
RE: Thinking about doing a LDCad 1.7 version
#70
(2020-03-02, 5:32)SNIPE Wrote: Eye view - the ability to move the camera as if you're in a first person game, this will make it easier to go into tight spaces such as a room in a  house and inspect building errors etc. The movement could be tied to the grid stepping.
I'm working on something like this for 1.7, but it will be an animation mode thing.

Originally I wanted to push this back to 2.0 as the 2.0 rendering engine is much better with large scenes as 1.x does only some very basic frustum (near plane) culling.


(2020-03-02, 5:32)SNIPE Wrote: The ability to select all parts of a given type or color does exist but only if you assign a keyboard hotkey for 'select working part' or 'select working color' and then holding shift when you want to do 'select working part' / 'select working color' a second time. But shift does not work with the menu item, only a hotkey so maybe add shift support to the menu item and also assign a keyboard shortcut by default for 'select working part/color' because it is used super often.
If I understand correctly the main problem is selecting a work part/color without loosing the selection?
Maybe an option to make the 'hot' part the working part/color?

(2020-03-02, 5:32)SNIPE Wrote: Also a 'select all connected parts' like in LDD would be cool.
That would be very cool indeed, but its very complicated Big Grin I do have some snapping improvements planned for 2.0 though.

(2020-03-02, 5:32)SNIPE Wrote: The ability to rotate multiple bricks but where they have their own rotation centers instead of a single rotation center where everything else selected orbits that.
Might be handy, I'll look into it.
Until then there is a sample marcro for this, it applies the orientation of the first selected part to all other parts in the selection. If needed you can adjust it to (also) apply relative rotation.

(2020-03-02, 5:32)SNIPE Wrote: A secondary color ootion like in MSpaint by right clicking on a color square in the color menu and having a second long square telling you the currently selected secondary color.
I did consider using multiple work part/colors before but I'm afraid it will complicate things too much.

(2020-03-02, 5:32)SNIPE Wrote: Also the ability to automatically align another part to a part with a diagonaal edge like a wing plate. example
This would need additional information stored in parts (like snapping and mirroring).
Afterwards it would need a way to cycle trough the orientations that information supplies.
Someone has suggested something similar like this before in order to use something other then the parts local 0,0,0 while dragging/snapping.

(2020-03-02, 5:32)SNIPE Wrote: A new 'node view' editing pane like in the following video for auto generating parametric structures like in grasshoooer/blender: https://youtu.be/8TFrz2eWyB0?t=865
Script would the why to do this in 1.6. An interactive flow chart like that video is something I would like very much at some point but it will get complicated very fast.
My LD4DStudio project had something similar to it, but very little people used it. That's why I decided to go script only in LDCad which basiclly does the same (without the gui) trough the aniTools module.
I might bring back some kind of gui for 2.0 though, but not sure yet.
Reply
RE: Thinking about doing a LDCad 1.7 version
#72
(2020-03-04, 19:53)Roland Melkert Wrote: This would need additional information stored in parts (like snapping and mirroring).
Afterwards it would need a way to cycle trough the orientations that information supplies.
Someone has suggested something similar like this before in order to use something other then the parts local 0,0,0 while dragging/snapping.

Some parts have this info included in HELP metas—perhaps there's a way to search these metas for possible suggested rotation angles?

For other parts, Selection Info could help figure these angles, if it were possible to select (or snap to) part vertices.
Reply
RE: Thinking about doing a LDCad 1.7 version
#73
(2020-03-02, 5:32)SNIPE Wrote: Eye view - the ability to move the camera as if you're in a first person game, this will make it easier to go into tight spaces such as a room in a  house and inspect building errors etc. The movement could be tied to the grid stepping.

Yes, I wish for this feature too.

...but LDCad already has so many hotkeys, I don't know where you would fit the controls.
Reply
RE: Thinking about doing a LDCad 1.7 version
#69
Here's an idea I just had (and given our experience with LDCad, I wouldn't be surprised if this isn't already possible and I just don't know it).  Big Grin

What about being able to modify the "insert" command with arrow keys, in order to place the next part to the immediate left/right/top/bottom of the previous one? This could speed up placement of repetitive parts like floor tiles and so on.

(I know that you can already guide the placement of the next part by pointing your cursor, but you still have to "commit" the placement by clicking; my idea would automatically place and commit the next part.)
Reply
RE: Thinking about doing a LDCad 1.7 version
#71
(2020-03-04, 16:32)N. W. Perry Wrote: What about being able to modify the "insert" command with arrow keys, in order to place the next part to the immediate left/right/top/bottom of the previous one? This could speed up placement of repetitive parts like floor tiles and so on.

(I know that you can already guide the placement of the next part by pointing your cursor, but you still have to "commit" the placement by clicking; my idea would automatically place and commit the next part.)
A macro could do this, might be a fun example I'll look into it.
Reply
RE: Thinking about doing a LDCad 1.7 version
#74
Possibility to inline flex parts? That would replace flex part with its fallback code, allowing to access individual elements (eg. change chain links to tread links). Of course that would apply only to discrete element flex.
Reply
RE: Thinking about doing a LDCad 1.7 version
#75
(2020-03-14, 19:38)Philippe Hurbain Wrote: Possibility to inline flex parts? That would replace flex part with its fallback code, allowing to access individual elements (eg. change chain links to tread links). Of course that would apply only to discrete element flex.

I like this idea alot.

But I'm afraid the next request would be to change it back later on. So instead of inline it might be better to make it an option of the subfile (disable regens, make it editable) somehow.
Reply
RE: Thinking about doing a LDCad 1.7 version
#76
(2020-03-16, 19:13)Roland Melkert Wrote: I like this idea alot.

But I'm afraid the next request would be to change it back later on. So instead of inline it might be better to make it an option of the subfile (disable regens, make it editable) somehow.

Not the same but related:
Is there a way to turn off the generation of fallback code and remove it from within LDCad? If not, can there be? I've been manually editing the META with LDDP because I couldn't find a way to do it inside of LDCad.
Reply
RE: Thinking about doing a LDCad 1.7 version
#77
(2020-03-16, 19:32)Orion Pobursky Wrote: Not the same but related:
Is there a way to turn off the generation of fallback code and remove it from within LDCad? If not, can there be? I've been manually editing the META with LDDP because I couldn't find a way to do it inside of LDCad.

Yes, the addFallBack option of the !LDCAD CONTENT meta.

Set it to

never

or

remove

You can do this with any text editor or use the header dialog's path tab's code gen option inside LDCad itself.
Reply
RE: Thinking about doing a LDCad 1.7 version
#78
(2020-03-16, 19:39)Roland Melkert Wrote: Yes, the addFallBack option of the !LDCAD CONTENT meta.

Set it to

never

or

remove

You can do this with any text editor or use the header dialog's path tab's code gen option inside LDCad itself.

Ahh, it's called Code Gen. Got it. I was trying to edit the meta itself in the source window.
Reply
RE: Thinking about doing a LDCad 1.7 version
#79
(2020-03-16, 19:32)Orion Pobursky Wrote: Is there a way to turn off the generation of fallback code and remove it from within LDCad? 
For what purpose? Create clean templates?
Reply
RE: Thinking about doing a LDCad 1.7 version
#80
(2020-03-16, 20:21)Philippe Hurbain Wrote: For what purpose? Create clean templates?

Couple of reasons:
- For flex extensive models, allows me to distribute a file that isn't huge (e.g. 8448)
- Makes it easier to split the file out with a text editor since all the auto-generated isn't there.

Yes, I know I can make LQ templates but call me a perfectionist.
Reply
RE: Thinking about doing a LDCad 1.7 version
#81
(2020-03-16, 20:21)Philippe Hurbain Wrote: For what purpose? Create clean templates?

Templates will automatically exclude fallback, when using "addFallBack=default", given they are stored in a registered template location.
Reply
RE: Thinking about doing a LDCad 1.7 version
#82
(2020-03-16, 20:48)Roland Melkert Wrote: Templates will automatically exclude fallback, when using "addFallBack=default", given they are stored in a registered template location.
Wondered why it worked sometimes... Location!
Reply
RE: Thinking about doing a LDCad 1.7 version
#83
(2020-03-16, 19:32)Orion Pobursky Wrote: Not the same but related:
Is there a way to turn off the generation of fallback code and remove it from within LDCad? If not, can there be? I've been manually editing the META with LDDP because I couldn't find a way to do it inside of LDCad.

Came here to suggest something very similar, yet opposite…

Could it be an option to export only the fallback code, without the !LDCAD metas, specifically as a part (.dat) file with appropriate header? This could be used e.g. to open models with flex elements in other LDraw programs without sacrificing the higher quality of LDCad's generated mesh by using static references. (It's also necessary to view an LDCad-generated spring mesh in an external editor.)

I could see this as a third option when choosing "Duplicate subfile…", and possibly also in "Detach subfile", along with new file and new subfile in the current file.
Reply
RE: Thinking about doing a LDCad 1.7 version
#84
(2020-03-31, 18:40)N. W. Perry Wrote: Could it be an option to export only the fallback code, without the !LDCAD metas, specifically as a part (.dat) file with appropriate header? This could be used e.g. to open models with flex elements in other LDraw programs without sacrificing the higher quality of LDCad's generated mesh by using static references. (It's also necessary to view an LDCad-generated spring mesh in an external editor.)

I could see this as a third option when choosing "Duplicate subfile…", and possibly also in "Detach subfile", along with new file and new subfile in the current file.

Whenever you drop a template on a model it asks if you want to make it part of the mpd or a separate file.

If you choose to make it a separate file and name it something .dat you should be ok most of the time.

Only possible problem is when a generated part has subparts that .dat would technically be a mpd (this is mandated by LDCad's generator).

All LDCad meta's should be transparent to other tools as they would (MUST) just skip those lines.

That said, I'm planning to make some improvements to the mpd split/joint tools for the 1.7 version.

I'll add an extra option to split generated content (with a warning about loosing the original paramters etc) to that version.
Reply
RE: Thinking about doing a LDCad 1.7 version
#85
(2020-03-31, 19:31)Roland Melkert Wrote: Whenever you drop a template on a model it asks if you want to make it part of the mpd or a separate file.

If you choose to make it a separate file and name it something .dat you should be ok most of the time.

Only possible problem is when a generated part has subparts that .dat would technically be a mpd (this is mandated by LDCad's generator).

Interesting…how would that be different from a regular .dat file that references primitives and subparts?

Quote:All LDCad meta's should be transparent to other tools as they would (MUST) just skip those lines.

That said, I'm planning to make some improvements to the mpd split/joint tools for the 1.7 version.

I'll add an extra option to split generated content (with a warning about loosing the original paramters etc) to that version.

Yeah, I suppose technically I don't need to remove the metas, but for some reason it feels like a "cleaner" part file without them. Also, it removes the risk of the mesh being regenerated accidentally if I open the .dat file in LDCad…
Reply
RE: Thinking about doing a LDCad 1.7 version
#86
(2020-04-02, 2:10)N. W. Perry Wrote: Interesting…how would that be different from a regular .dat file that references primitives and subparts?

None, as it becomes (to other software whom don't know the meta's) a normal LDraw file. The fact it's secretly a mpd shouldn't really matter to a parser aware of mpd rules.
Reply
RE: Thinking about doing a LDCad 1.7 version
#87
This one is small:

When I use duplicate this file, can the new filename be a derivative of the old filename (ex. Head.dat -> Head-1.dat) instead of "submodel01.dat" (or whatever the default pattern is)
Reply
RE: Thinking about doing a LDCad 1.7 version
#88
(2020-04-02, 21:13)Orion Pobursky Wrote: This one is small:

When I use duplicate this file, can the new filename be a derivative of the old filename (ex. Head.dat -> Head-1.dat) instead of "submodel01.dat" (or whatever the default pattern is)
+1 !!!
Reply
RE: Thinking about doing a LDCad 1.7 version
#90
And similar... it would be nice if current file name was suggested when using "save as". Generally we just create a derivative of the name.
Reply
RE: Thinking about doing a LDCad 1.7 version
#89
Speaking of small (and +1 to the above, by the way!), here's one that may or may not be:

Would it be possible to assign quantities and colors to group references in a .pbg file, the way you can with individual parts? I use these to list composite parts (hinge assemblies, turntables and so forth) within a set inventory, but at the moment I have to create a separate .pbg for each different color of the assembly, and I can't indicate the quantity at all.

Of course, it's quite possible that there's a way to do this already and I just haven't discovered it! Wink
Reply
RE: Thinking about doing a LDCad 1.7 version
#91
(2020-04-04, 18:03)N. W. Perry Wrote: Would it be possible to assign quantities and colors to group references in a .pbg file, the way you can with individual parts? I use these to list composite parts (hinge assemblies, turntables and so forth) within a set inventory, but at the moment I have to create a separate .pbg for each different color of the assembly, and I can't indicate the quantity at all.

Of course, it's quite possible that there's a way to do this already and I just haven't discovered it! Wink

Interesting use case, there is no way of doing that at the moment though.

Groups don't have those attributes as you can't really select them, you can only go 'into' them.

the original intent of those numbers and colors was to let people build stuff with a limited inventory, the numbers would then go down when a copy is placed in the model.

But I favored other features instead so it got pushed back again and again.

But even in that setup it would only work on a single group not the whole tree.

I could however introduce a new part bin group kind whom let you display the contents of another one in a different color (for the col16 items in that group).

I'll add it to my 1.7 'maybe' list.
Reply
RE: Thinking about doing a LDCad 1.7 version
#92
(2020-04-04, 21:24)Roland Melkert Wrote: Interesting use case, there is no way of doing that at the moment though.

Groups don't have those attributes as you can't really select them, you can only go 'into' them.

the original intent of those numbers and colors was to let people build stuff with a limited inventory, the numbers would then go down when a copy is placed in the model.

But I favored other features instead so it got pushed back again and again.

But even in that setup it would only work on a single group not the whole tree.

I could however introduce a new part bin group kind whom let you display the contents of another one in a different color (for the col16 items in that group).

I'll add it to my 1.7 'maybe' list.

Being able to set the color by inheritance would be really useful! I can see the trouble with quantity, though…that's not as important, really, at least until LDCad makes use of this info.

One workaround is to include the full assembly inside the group, with the correct quantity shown there. (I have to include the assembly in the group anyhow, since I want to use it as the mascot.) Only trouble is this gets me back to making separate groups for each different quantity of the same part, which probably isn't worth it.
Reply
RE: Thinking about doing a LDCad 1.7 version
#93
Here are two suggested minor tweaks that have occurred to me recently:

1) I would love to be able to configure hot keys for changing the active grouping layer from the main editing window. Or at least the first 9 (plus 0 for "none/disabled"); I probably would never get anywhere close to 32 grouping layers. Wink

2) Small human-readability issue: LDCad adds a newline to the end of a main file (LDR or MPD), as required/permitted by the spec, but not to the end of subfiles inside an MPD. I find that I need to add this whitespace manually, to help when I need to scan the source in a text editor. (I appreciate that LDCad doesn't delete the space after I've added it, though!)
Reply
RE: Thinking about doing a LDCad 1.7 version
#94
(2020-04-10, 18:43)N. W. Perry Wrote: 1) I would love to be able to configure hot keys for changing the active grouping layer from the main editing window. Or at least the first 9 (plus 0 for "none/disabled"); I probably would never get anywhere close to 32 grouping layers. Wink

That reminds me, the whole layer thing is a bit experimental in 1.6. It was supposed to become more dynamic (editable names etc). Linking it to hotkeys is/was part of that clean-up.


(2020-04-10, 18:43)N. W. Perry Wrote: 2) Small human-readability issue: LDCad adds a newline to the end of a main file (LDR or MPD), as required/permitted by the spec, but not to the end of subfiles inside an MPD. I find that I need to add this whitespace manually, to help when I need to scan the source in a text editor. (I appreciate that LDCad doesn't delete the space after I've added it, though!)
The trailing newline is because internally all lines are without the next line character(s) only at the moment of writing to disk are they added to each string in the list making them lines.

The main problem with empty lines is pollution when appending new lines etc.

Only real solution I see is to truncate (trim) on read and force a single empty line on write. I could make that an option?
Reply
RE: Thinking about doing a LDCad 1.7 version
#95
(2020-04-10, 19:05)Roland Melkert Wrote: That reminds me, the whole layer thing is a bit experimental in 1.6. It was supposed to become more dynamic (editable names etc). Linking it to hotkeys is/was part of that clean-up.

I didn't know that, but now that you say it, it makes sense. I've also noticed there's no way to see all group information in one place, or move parts from one group to another (including any empty groups, such as if I've ungrouped something and want to put it back together). The recursive grouping is really powerful but can also be a little confusing, especially as it interacts with nested editing and submodels. Being able to view and interact with the entire group "tree" would be very useful, but of course now we're getting much deeper into the weeds. Smile


Quote:The trailing newline is because internally all lines are without the next line character(s) only at the moment of writing to disk are they added to each string in the list making them lines.

The main problem with empty lines is pollution when appending new lines etc.

Only real solution I see is to truncate (trim) on read and force a single empty line on write. I could make that an option?

Could it be an option from Clean-up, maybe? Just to add an empty line before each FILE meta (except the first), in the same way that whitespace is added to force official header formatting? Alternatively, I could just train myself to add an empty line to the end of each submodel, as I already do with STEP commands at the end of each step.
Reply
RE: Thinking about doing a LDCad 1.7 version
Hmm…what about a basic right triangle calculator? This is by far the most common calculation I make, to find the rotation angle of one part against a stationary surface. I don't know if it makes sense to add as part of the Selection Info tool, or perhaps as a macro. (This would probably be a perfect starter project if I ever decide to try some scripting!)

It would work like this—first you select three points:
  • The point ( A ) on a rotated part/assembly that will collide with the stationary surface
  • The rotation center ( B )
  • A point ( C ) orthogonal to the rotation center along the stationary surface
   

Point C gives us the X-value of point A after it's rotated; we need to find its Y-value (in this case). Because we know two sides of a right triangle, we can find the third side length, and move point C by that amount in the Y-direction.

   

Now that A-B and B-C are the same length, we can get the rotation angle to translate A to C.

   

Of course the second part of this already exists; it's just a matter of solving the right triangle to get the second coordinate for the rotated point.
Reply
RE: Thinking about doing a LDCad 1.7 version
You could, probably, do this now with a script. If I didn’t already have like 5 project plates spinning, I’d finally learn how to script in LDCad and eliminate the need for my spreadsheets.
Reply
RE: Thinking about doing a LDCad 1.7 version
(2020-05-05, 19:27)Orion Pobursky Wrote: You could, probably, do this now with a script. If I didn’t already have like 5 project plates spinning, I’d finally learn how to script in LDCad and eliminate the need for my spreadsheets.

Yep, I think so too. Like I said, the perfect starter project if I find myself with no other plates spinning.  Smile
Reply
RE: Thinking about doing a LDCad 1.7 version
(2020-05-05, 19:44)N. W. Perry Wrote: Yep, I think so too. Like I said, the perfect starter project if I find myself with no other plates spinning.  Smile
It's a fairly simple one if you assume it's on the abs yz plane

Code:
function onRun()

  local sel=ldc.selection()
  if sel:getRefCount()<3 then
    return
  end

  local a=sel:getRef(1):getPos()
  local b=sel:getRef(2):getPos()
  local c=sel:getRef(3):getPos()

  a:setX(0)
  b:setX(0)
  c:setX(0)
  c:setY(b:getY())

  local ab=a:getLength(b)
  local bc=b:getLength(c)

  local bb1=ldc.vector(1,0,0):getSignedAngle(a-b, c-b)
  local bb2=math.deg(math.acos(bc/ab))

  local angle=-(bb1-bb2)
  ldc.setClipboardText(angle)

  ldc.dialog.runMessage(angle)
end

function register()

  local macro=ldc.macro('My macro')
  macro:setEvent('run', 'onRun')
end

register()

Could use some more cleanups and dummy proof checks though

It gave me the idea to add access to the relative grid in 1.7, so thanks for that
Reply
RE: Thinking about doing a LDCad 1.7 version
I realized if you assume all selection points are on a plane, you can drop the setX/setY lines and calculate the plane normal instead of using a static x vector

Code:
function onRun()

  local sel=ldc.selection()
  if sel:getRefCount()<3 then
    return
  end

  local a=sel:getRef(1):getPos()
  local b=sel:getRef(2):getPos()
  local c=sel:getRef(3):getPos()

  local ba=a-b
  local bc=c-b

  local n=bc:getCross(ba)
  n:normalize()

  local bb1=n:getSignedAngle(ba, bc)
  local bb2=math.deg(math.acos(bc:getLength()/ba:getLength()))

  local angle=-(bb1-bb2)
  ldc.setClipboardText(angle)

  ldc.dialog.runMessage(angle)
end

neg y makes it somewhat confusing but i think this should work in any orientation, not tested though.
Reply
RE: Thinking about doing a LDCad 1.7 version
(2020-05-05, 22:07)Roland Melkert Wrote: I realized if you assume all selection points are on a plane, you can drop the setX/setY lines and calculate the plane normal instead of using a static x vector

Code:
function onRun()

  local sel=ldc.selection()
  if sel:getRefCount()<3 then
    return
  end

  local a=sel:getRef(1):getPos()
  local b=sel:getRef(2):getPos()
  local c=sel:getRef(3):getPos()

  local ba=a-b
  local bc=c-b

  local n=bc:getCross(ba)
  n:normalize()

  local bb1=n:getSignedAngle(ba, bc)
  local bb2=math.deg(math.acos(bc:getLength()/ba:getLength()))

  local angle=-(bb1-bb2)
  ldc.setClipboardText(angle)

  ldc.dialog.runMessage(angle)
end

neg y makes it somewhat confusing but i think this should work in any orientation, not tested though.

This version got me close, but not quite:
   
Reply
RE: Thinking about doing a LDCad 1.7 version
(2020-05-06, 3:14)N. W. Perry Wrote: This version got me close, but not quite:

It works for me, gives angle -53.13 same as with the first version of the script.

Did you use helper parts whom all use the same x coordinate, placing the whole thing on the yz plane.
Reply
RE: Thinking about doing a LDCad 1.7 version
(2020-05-06, 5:32)Roland Melkert Wrote: It works for me, gives angle -53.13 same as with the first version of the script.

Did you use helper parts whom all use the same x coordinate, placing the whole thing on the yz plane.

Yes…didn't think of that, to be honest, but they happen to be correct. Don't remember for sure since I didn't save the test file, but trying it now works correctly.

Looks like it was the same group vs. submodel problem. I can recreate the problem by selecting just the first helper part, and the group; it calculates the angle using the two parts in the group as getRef(2) and getRef(3), ignoring the second helper part.

Easiest fix, obviously, is to use a helper part at the rotation center, since the hinge part unhelpfully has its origin elsewhere…
Reply
RE: Thinking about doing a LDCad 1.7 version
(2020-05-06, 16:42)N. W. Perry Wrote: Looks like it was the same group vs. submodel problem. I can recreate the problem by selecting just the first helper part, and the group; it calculates the angle using the two parts in the group as getRef(2) and getRef(3), ignoring the second helper part.

Ah I forgot about groups in my little test scenario, you can fix that by using getLineCount() / getLine() instead of the ref variants.
Reply
RE: Thinking about doing a LDCad 1.7 version
(2020-05-06, 19:18)Roland Melkert Wrote: Ah I forgot about groups in my little test scenario, you can fix that by using getLineCount() / getLine() instead of the ref variants.

Should it be a straight find-&-replace for that text? Doing this, it complained that getPos was a nil value.
Reply
RE: Thinking about doing a LDCad 1.7 version
(2020-05-06, 21:01)N. W. Perry Wrote: Should it be a straight find-&-replace for that text? Doing this, it complained that getPos was a nil value.

Sometimes I forget the rules of my own scripting api Smile

getRef does work with groups but it might have a different center, so in the end it shouldn't matter as long the group's center is also on the same x (or whatever plane coordinate) as the other items in the selection.

Otherwise it shouldn't even run the calculation as the first line stops the execution if there are less then 3 items in the selection.  This would be true if one of them were a group while those where excluded.
Reply
RE: Thinking about doing a LDCad 1.7 version
(2020-05-06, 21:31)Roland Melkert Wrote: Sometimes I forget the rules of my own scripting api Smile

getRef does work with groups but it might have a different center, so in the end it shouldn't matter as long the group's center is also on the same x (or whatever plane coordinate) as the other items in the selection.

Otherwise it shouldn't even run the calculation as the first line stops the execution if there are less then 3 items in the selection.  This would be true if one of them were a group while those where excluded.

Well, that's just it—it does seem to do the calculation, if I select only the first helper part, and the group. (The group contains two parts/refs: the hinge top, and the 2x4 plate.) This is when I get the not-quite-correct angle of 48.-something, I assume because it's using the origin of the hinge top as the B point, being the first part in the group. But the group center is set to where the hinge rotates, and it's properly planar and everything.

But when I change the group to a submodel, with the same rotation point set as its origin, everything works properly.
Reply
RE: Thinking about doing a LDCad 1.7 version
(2020-05-07, 2:45)N. W. Perry Wrote: I assume because it's using the origin of the hinge top as the B point, being the first part in the group. But the group center is set to where the hinge rotates, and it's properly planar and everything.
This sounds like a bug , getPos should return the group center not the main line center.

I'll look into it.
Reply
RE: Thinking about doing a LDCad 1.7 version
(2020-05-05, 20:54)Roland Melkert Wrote: It's a fairly simple one if you assume it's on the abs yz plane

Code:
function onRun()

  local sel=ldc.selection()
  if sel:getRefCount()<3 then
    return
  end

  local a=sel:getRef(1):getPos()
  local b=sel:getRef(2):getPos()
  local c=sel:getRef(3):getPos()

  a:setX(0)
  b:setX(0)
  c:setX(0)
  c:setY(b:getY())

  local ab=a:getLength(b)
  local bc=b:getLength(c)

  local bb1=ldc.vector(1,0,0):getSignedAngle(a-b, c-b)
  local bb2=math.deg(math.acos(bc/ab))

  local angle=-(bb1-bb2)
  ldc.setClipboardText(angle)

  ldc.dialog.runMessage(angle)
end

function register()

  local macro=ldc.macro('My macro')
  macro:setEvent('run', 'onRun')
end

register()

Could use some more cleanups and dummy proof checks though

It gave me the idea to add access to the relative grid in 1.7, so thanks for that

See, now that I see it written out, it makes perfect sense. :-)

This did indeed work, once I a) rotated the model into the YZ plane, and b) replaced the group I was rotating with a submodel (because the script is looking for refs).
Reply
RE: Thinking about doing a LDCad 1.7 version
(2020-05-05, 19:27)Orion Pobursky Wrote: You could, probably, do this now with a script. If I didn’t already have like 5 project plates spinning, I’d finally learn how to script in LDCad and eliminate the need for my spreadsheets.
This is, exactly, why I asked for the top "feature" making a better documentation of both the script language and the object model in LDCAD. Roland, can you think about this, please? At least put all scripts from this forum, as you post them time to time, to one place at your WWW site, with comments. Better if you document even more.

Esp. if you want to work on LDCAD 2.0 and expect we add more features to LDCAD 1.7 ourselves, using scripts. The documentation would be really helpful. The better the more helpful Wink
Reply
RE: Thinking about doing a LDCad 1.7 version
(2020-05-08, 20:05)Milan Vančura Wrote: This is, exactly, why I asked for the top "feature" making a better documentation of both the script language and the object model in LDCAD. Roland, can you think about this, please? At least put all scripts from this forum, as you post them time to time, to one place at your WWW site, with comments. Better if you document even more.

I know, but often when I start to work on documentation in about 5 minutes I'm like "Bored now" Smile

Adding features trough script is a 2.0 core feature, as I want to keep the binary compact and do everything else trough extensions.
Reply
RE: Thinking about doing a LDCad 1.7 version
(2020-01-13, 20:41)Roland Melkert Wrote: - !DATA support

Took some more work than expected but I have implemented basic support for embedded textures in 1.7

   

Next I will need to hide the DATA 'sub model' from the editor as it behaves as a empty model at the moment.

But I'm not yet sure how to handle the contents of data sections gui wise.

Any ideas on that are welcome.

I'm thinking to remove the whole "Change current session" menu and instead add a generic dialog from where you can save/add/change submodels/data content etc.

Only problem with that is when there is how to handle a mpd with just a single data section and nothing else (no editing area subject).
Reply
RE: Thinking about doing a LDCad 1.7 version
I have run into issues with a user who has used LDCad to create instructions with BUFEXCH commands, see: https://github.com/LasseD/buildinginstru.../issues/34

As you can see, the issue appears to be a lack of "0" prefixes in the buffer-exchange-specific regions, causing LDCad to output files that are not interpreted correctly in software that does not support Buffer Exchange commands. 

Can you please share the specification which you have used for the existing support, and are you aware of other commands in LDCad which might cause other software to render stuff incorrectly?
Reply
RE: Thinking about doing a LDCad 1.7 version
(2020-05-23, 12:53)Lasse Deleuran Wrote: I have run into issues with a user who has used LDCad to create instructions with BUFEXCH commands, see: https://github.com/LasseD/buildinginstru.../issues/34

As you can see, the issue appears to be a lack of "0" prefixes in the buffer-exchange-specific regions, causing LDCad to output files that are not interpreted correctly in software that does not support Buffer Exchange commands. 

Can you please share the specification which you have used for the existing support, and are you aware of other commands in LDCad which might cause other software to render stuff incorrectly?

I'm not sure I understand the problem, do you mean you expected the "0 " prefixes on the ghost lines to be added automatically ?

If so that's not part of the bufxchg spec.

0 GHOST  is a different mlcad meta, which it uses to draw parts transparently I believe.

It is just added as a prefix to lines which the user wants 'ghosted'.


I used MLCad's documentation to implement bufxchg
http://mlcad.lm-software.com/e_default.htm

It is basically a stack command, meaning you store the whole LDraw content at the STORE point and trow away the current content upon a RETRIEVE.

I did implement it as a hide flag in LDCad as I don't want to literately delete stuff Smile

The main trick is to loop backwards trough the LDraw lines when processing the commands, that way nested ones are automatically handled correctly.
Reply
RE: Thinking about doing a LDCad 1.7 version
(2020-05-23, 18:11)Roland Melkert Wrote: I'm not sure I understand the problem, do you mean you expected the "0 " prefixes on the ghost lines to be added automatically ?

If so that's not part of the bufxchg spec.

0 GHOST  is a different mlcad meta, which it uses to draw parts transparently I believe.

It is just added as a prefix to lines which the user wants 'ghosted'.


I used MLCad's documentation to implement bufxchg
http://mlcad.lm-software.com/e_default.htm

It is basically a stack command, meaning you store the whole LDraw content at the STORE point and trow away the current content upon a RETRIEVE.

I did implement it as a hide flag in LDCad as I don't want to literately delete stuff Smile

The main trick is to loop backwards trough the LDraw lines when processing the commands, that way nested ones are automatically handled correctly.

That explains the issue. The two commands go hand-in-hand to ensure compatibility with other LDraw software, such as LDView.

In the documentation you link to, the section with GHOST says (highlight mine):


Quote:Ghost commands are a special form of other commands. Any MLCad or Ldraw command can be a ghost command. To make a command to a ghost command simply put “0 GHOST” at the beginning of the line.
So what’s the deal with this type of command?
MLCad displays ghost commands only if the model containing the command is the main model. If the model is a sub-model of another or simply a part included into a model the ghost lines are simply ignored. They are useful in connection with the buffer exchange command and allow to show detailed assembly instructions of a part when it’s viewed by its own, but if it’s included as a part these steps will not be shown.
Without this ghost command you would see things between buffer exchange commands uncontrolled since buffer exchange commands are also ignored in sub-models.

And this is the issue with their models. LDCad outputs the stuff between SAVE and RETRIEVE without any modification, so other viewers will simply also render all the stuff in those sections.
Reply
RE: Thinking about doing a LDCad 1.7 version
(2020-05-23, 18:37)Lasse Deleuran Wrote: That explains the issue. The two commands go hand-in-hand to ensure compatibility with other LDraw software, such as LDView.

In the documentation you link to, the section with GHOST says (highlight mine):

And this is the issue with their models. LDCad outputs the stuff between SAVE and RETRIEVE without any modification, so other viewers will simply also render all the stuff in those sections.

Now I see, I  actually implement nested BUFXCHG meaning it will also work on submodels.

To this end I keep track of two visibility flags one for visibility as seen from the last step (submodel state) and one for the current step of the model you're working on.

This is a fairly easy fix and prevents littering all those GHOST meta's imho.

But if you want to use the ghost tag in your instructions you can use the newly added "toggle ghosted lines" macro of 1.6d, it's in the scripts/mlcad menu.
Reply
RE: Thinking about doing a LDCad 1.7 version
(2020-05-23, 19:10)Roland Melkert Wrote: Now I see, I  actually implement nested BUFXCHG meaning it will also work on submodels.

To this end I keep track of two visibility flags one for visibility as seen from the last step (submodel state) and one for the current step of the model you're working on.

This is a fairly easy fix and prevents littering all those GHOST meta's imho.

But if you want to use the ghost tag in your instructions you can use the newly added "toggle ghosted lines" macro of 1.6d, it's in the scripts/mlcad menu.
That makes sense. I am not fully versed in when stuff is ghosted or not in MLCad, but if you add the "0" prefix then that should help with how LDView shows the model.

I will make sure that both "0 " and "0 GHOST " prefixes are ignored when interpreting the BUFEXCHG commands in the Javascript library, so it should work together with the output from LDCad no matter the version.
Reply
RE: Thinking about doing a LDCad 1.7 version
Thought of this one some time ago but didn't get around to suggesting it…

Is it possible to display the length of flexible parts dynamically as I edit the part? Most of the time, this means in nested mode, whereas now you have to exit nested mode and highlight the whole part. (I wouldn't mind also if it displayed the greater precision used in the generated code.)

While I'm on the subject, I feel like there may be bugs in the length parameters of the path dialog. For example, if I set a length display offset, it vanishes next time I open the dialog. And if I set the unit to LDraw, the displayed length is some wild enormous number—but what it writes into the code is correct. Maybe this is a know issue, but if not I can go into more detail.
Reply
RE: Thinking about doing a LDCad 1.7 version
(2020-05-23, 16:55)N. W. Perry Wrote: Is it possible to display the length of flexible parts dynamically as I edit the part? Most of the time, this means in nested mode, whereas now you have to exit nested mode and highlight the whole part. (I wouldn't mind also if it displayed the greater precision used in the generated code.)

If you open the MPD contents group in the bin, you can inspect the length using the flexible part's bin cell hint.

And if you open the parts own editing session you can also get extra information by opening the information icon at the right bottom.

That said, it might be handy to have it somewhere more prominent while working with the control points.

Maybe add it to the coordinate panel when anything path related is selected ?


(2020-05-23, 16:55)N. W. Perry Wrote: While I'm on the subject, I feel like there may be bugs in the length parameters of the path dialog. For example, if I set a length display offset, it vanishes next time I open the dialog. And if I set the unit to LDraw, the displayed length is some wild enormous number—but what it writes into the code is correct. Maybe this is a know issue, but if not I can go into more detail.
Sounds like a bug, but I can't replicate it.

I assume you talking about these settings?

.png   props.png (Size: 5.79 KB / Downloads: 85)

Are you using 1.6d because I did change something concerning those settings in 1.6c (added the L option) so I may have broken something during that.
Reply
RE: Thinking about doing a LDCad 1.7 version
(2020-05-23, 22:31)Roland Melkert Wrote: If you open the MPD contents group in the bin, you can inspect the length using the flexible part's bin cell hint.

And if you open the parts own editing session you can also get extra information by opening the information icon at the right bottom.

That said, it might be handy to have it somewhere more prominent while working with the control points.

Maybe add it to the coordinate panel when anything path related is selected ?

Coordinate panel would be the perfect spot! I did know about the bin hint, but I'd forgotten about the document into icon. There's some helpful extra info in there, but as you say it requires switching to that part's editing session.

Quote:Sounds like a bug, but I can't replicate it.

I assume you talking about these settings?

Yes, but now I can't replicate it either. Huh Perhaps I was doing something wrong (like closing the dialog with ESC instead of ENTER).

But the other part is easy to replicate:
   

That's a bit of a funky number for LDU, no?

Quote:Are you using 1.6d because I did change something concerning those settings in 1.6c (added the L option) so I may have broken something during that.

Yes, 1.6d. And thanks for adding L, by the way—I use it all the time!
Reply
RE: Thinking about doing a LDCad 1.7 version
(2020-05-24, 2:48)N. W. Perry Wrote: But the other part is easy to replicate:

Yes that's a bug, it is trying to format a double like an integer. Big Grin

It's a presentation only issue, so no real corruption.
Reply
RE: Thinking about doing a LDCad 1.7 version
One other thing that I've thought of. When you hover over a part, status bar displays information about it. For example:

"Plate 1 x 2 (3023.dat) in Red (4,P) at 80; 117; -32"

But that info disappears once your mouse leaves the part even if that part is selected

I would find very useful if, when you have a part selected, the information would still be displayed in the status bar. And that you could configure a right click menu (perhaps in text file) that would open URLs. And Double click for a default URL!

In the example above, If I would right click on the status bar, a menu would pop up that would have the following options:

Open Part in:

Bricklink (default)
Brickset
LDraw Part Tracker

And the config text file for the menu could be perhaps something like this:

(entry name) : (URL with var);
"Bricklink" : "https://www.bricklink.com/v2/catalog/catalogitem.page?P="&%part%"&#T=C";
Brickset : "https://brickset.com/parts/design-"&%part%;
Ldraw Part Tracker : "https://www.ldraw.org/parts/official-part-lookup.html?folder=parts&partid="&%part%

Do you think that would be possible/useful?

Best regards,

Miguel
Reply
RE: Thinking about doing a LDCad 1.7 version
(2020-06-19, 22:08)Miguel Reizinho Wrote: I would find very useful if, when you have a part selected, the information would still be displayed in the status bar. And that you could configure a right click menu (perhaps in text file) that would open URLs. And Double click for a default URL!

In the example above, If I would right click on the status bar, a menu would pop up that would have the following options:

Open Part in:

Bricklink (default)
Brickset
LDraw Part Tracker
Great idea!
Better said, two ideas:

1. the first one is doable: do not clear the part description from status bar immediately after mouse cursor is out of the part. I'd add "think up how to display a complete description" because many times the description text is too long for the status bar
2. URLs, configurable - great idea! However, it'd need a transition from LDCAD part codes to BL ones, which is an ongoing project, AFAIK.
Reply
RE: Thinking about doing a LDCad 1.7 version
(2020-06-21, 20:50)Milan Vančura Wrote: Great idea!
Better said, two ideas:

1. the first one is doable: do not clear the part description from status bar immediately after mouse cursor is out of the part. I'd add "think up how to display a complete description" because many times the description text is too long for the status bar
2. URLs, configurable - great idea! However, it'd need a transition from LDCAD part codes to BL ones, which is an ongoing project, AFAIK.

Both hints and selection properties are better handled in my 2.0 plans.

1.7 is a '2.0 takes to long so lets do another 1.x to fast-track some fun stuff' version Smile  So I don't want to big changes to the way things generally work. That said I could add a simple option to not clear the hint bar when the mouse is on nothing.

The second point might be possible using a macro, but I'll have to look into that some more know for sure.
Reply
RE: Thinking about doing a LDCad 1.7 version
(2020-06-22, 17:02)Roland Melkert Wrote: Both hints and selection properties are better handled in my 2.0 plans.

1.7 is a '2.0 takes to long so lets do another 1.x to fast-track some fun stuff' version Smile  So I don't want to big changes to the way things generally work. That said I could add a simple option to not clear the hint bar when the mouse is on nothing.

The second point might be possible using a macro, but I'll have to look into that some more know for sure.

If it helps, stud.io has a "table" of parts conversion from LDRAW to Bricklink. Inside folder "C:\Program Files\Studio 2.0\data" there's a file named "StudioPartDefinition2.txt". It's a TAB delimited file with several columns with useful information including BL ItemNo and LDraw ItemNo
Reply
RE: Thinking about doing a LDCad 1.7 version
Many OMR models have generated parts (hoses, cables, bands, etc.) and I can see the bulk of the generated MPD files are from the generated fallback content. 

If the Web-viewer for OMR can auto-generate content based on the LDCad commands, then we can save a lot of disk space and a lot of network traffic, while still being able to generate fallback geometries when downloading from scripts. For this reason I would like to implement this functionality.

I seem to recall someone else was interested in the algorithms for generating the fallback geometries. Is this open sourced? If not, would it be a problem that the OMR viewer uses open source code for generating the fallback geometries?
Reply
RE: Thinking about doing a LDCad 1.7 version
(2020-06-26, 12:17)Lasse Deleuran Wrote: If the Web-viewer for OMR can auto-generate content based on the LDCad commands, then we can save a lot of disk space and a lot of network traffic, while still being able to generate fallback geometries when downloading from scripts. For this reason I would like to implement this functionality.

I seem to recall someone else was interested in the algorithms for generating the fallback geometries. Is this open sourced? If not, would it be a problem that the OMR viewer uses open source code for generating the fallback geometries?

The main used algorithm is bezier, second most used thing is interpolation of quaterions.

The meta's themselves are documented on my site and also on LDraw.org itself as it was proposed to become (the base of) a standard some time ago.

If you need some other details feel free to ask.
Reply
« Next Oldest | Next Newest »



Forum Jump:


Users browsing this thread: 3 Guest(s)