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: 526)

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
#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
(Yesterday, 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
(Yesterday, 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
« Next Oldest | Next Newest »



Forum Jump:


Users browsing this thread: 1 Guest(s)