LDCad 1.6 Beta 1 (win+linux)

[Roland Melkert]

Hello all,

I'm very proud to, finally, present the first Beta version of LDCad 1.6

It has been the slowest development cycle so far and I still need to dot some I's and such concerning the scripting stuff. But I relalize not many people use that anyway so I pushed it to Beta 2 in order to get a version out before the holydays.

Version 1.6 introduces the following major features:
- Macro scripting
- Many script api extensions
- Mirroring
- Region select
- MPD tools
- POV-Ray export (including animations)
- full ROTSTEP and BUFEXCHG support.
- Hotkey configuration
- Layered groups (still a bit experimental though)

It also includes many small tweaks and extensions, like:
- non integer grid stepping
- extend header editing
- some visual changes
- improved GUI templates

Even the downloads are improved as all of them now include both the 32 and 64 bit versions. The windows setup will install the correct one based on your system. I've also tried to automate this for this Linux version (setup.sh) but it might need some tweaking on some systems (feedback/improvements are highly appreciated)

You can get the version of your choice here:
www.melkert.net/LDCad/download

The Linux version is still compiled with (fully updateded) Debian 7.5, as this seems to ensure maximal compatibility. If the Linux experts on this board think I should upgrade to 8.x for some valid reason please let me know.

Documentation update and extensions (like always) are pending

   

[Milan Vančura]

Thanks for Beta1, Roland!

I write longer summary later after more testing. Just first observations: "Alt" modifier of hotkeys works perfectly even in combinations with other modifiers, attaching a hotkey for (sub)menu works as well, I can finally hide the menu bar forever and save this space on my tiny monitor. Other/remaining problems: "+" problem in the Part bin is still there, the hotkey configuration menu does not warn you about a hotkey conflict, the amount of actions there starts being really long and hard for overview; for example even (sub)menu items are not prefixed with same text, like "MENU:" and/or grouped together.

Scripting: Please, can you summarize the extension of scripting API or send me your examples used for testing it? They do not need to be perfect and educational, I just need something to start with. You know, there will be a week between Christmas and the New Year, that's a good chance for me to have time for both LDCad and LPub3D.

This reminds me another question: LPub3D uses archives of LDraw library plus additional directories. Plus ldraw.ini file containing the configuration of that, optionally. I still do not know details but I want to ask you if LDCad knows to cooperate with LPub3D on this so I, the user, will touch the same LDraw library in both programs, including unofficial parts, shadow information etc.?

[Merlijn Wissink]

Great work Roland! Many thanks!
But, uhm, where exactly can I find the Pov-ray export? I looked everywhere but I can't find it...

[Merlijn Wissink]

Ok, so far it seems pretty unstable. Or at least, something's not right. I've had it crash multiple times now, when rotating a submodel.
I'm happily editing a model, then it suddenly randomly freezes when I rotate a submodel. Happened 4 times in a row now 

EDIT: Ok, it looks like it's really a bug, it's 100% reproduceable (on my machine at least). Every single time I put this specific submodel in the main model and I try to rotate it, it freezes
EDIT2: So... it looks like this bug happens when I (try to) rotate any submodel.

[TestOne]

Great work Roland! Many thanks!
But, uhm, where exactly can I find the Pov-ray export? I looked everywhere but I can't find it...

View > Editing views > OpenGL view export (Export current view's OpenGL rendering to a png file)
View > Editing views > POV-Ray view export (Export current view's scene to a POV-Ray file)

[Merlijn Wissink]

Great work Roland! Many thanks!
But, uhm, where exactly can I find the Pov-ray export? I looked everywhere but I can't find it...

View > Editing views > OpenGL view export (Export current view's OpenGL rendering to a png file)
View > Editing views > POV-Ray view export (Export current view's scene to a POV-Ray file)

Thanks! Seems a bit weird to put it under 'editing views' in my opinion. I expected it under file > export > POV-ray or something like that.
Anyway, gonna take a look at what it produces 

[Milan Vančura]

Ok, so far it seems pretty unstable. Or at least, something's not right. I've had it crash multiple times now, when rotating a submodel.

I may confirm there is a problem. But it is not a crash. When I start rotating a submodel in the main model LDCad starts taking about 260% CPU (two full cores plus 60% of the third one) and nothing visible happens for minutes. Then my patience was gone and I killed LDCad from cmdline. Both 32bit and 64bit versions are affected.
Moving the submodel is OK, rotation using hotkeys is also OK, I may reproduce this bug only when I rotate the submodel using the rotation pin.
Another bug, may be related: when I rotate the same submodel using hotkeys, some rounding errors must happen. For example the submodel is not at its original place after 8 rotations about 22.5 deg.

[Merlijn Wissink]

And apparently it's not only submodels. It happens with parts too now... 

[Roland Melkert]

And apparently it's not only submodels. It happens with parts too now... 

Are you both using Linux as I could only replicate it in the Linux version so far.

I'll try to fix this into a beta 1a asap.

The rounding thing might be harder to fix though

[Milan Vančura]

Are you both using Linux as I could only replicate it in the Linux version so far.
I'll try to fix this into a beta 1a asap.
The rounding thing might be harder to fix though

Yes, Linux. Debian Jessie (8.6), both 64bit and 32bit versions are affected by these two bugs.

For testing purposes, I do not need them fixed, I just reported them. I simply will use keyboard for rotations during the testing.

[Roland Melkert]

Are you both using Linux as I could only replicate it in the Linux version so far.
I'll try to fix this into a beta 1a asap.
The rounding thing might be harder to fix though

Yes, Linux. Debian Jessie (8.6), both 64bit and 32bit versions are affected by these two bugs.

For testing purposes, I do not need them fixed, I just reported them. I simply will use keyboard for rotations during the testing.

I've found the cause it's an array out of bounds thing concerning the editing pin disk's vertices. So it tries to render vertices from invalid memory. Windows doesn't seem to mind that sort of thing

[Merlijn Wissink]

Yes, Linux. Debian Jessie (8.6), both 64bit and 32bit versions are affected by these two bugs.

For testing purposes, I do not need them fixed, I just reported them. I simply will use keyboard for rotations during the testing.

I've found the cause its an array out of bounds thing concerning the editing pin disk's vertices. So it tries to render vertices from invalid memory. Windows doesn't seem to mind that sort of things

Well... I'm using Windows 10 Pro 64bit...

[Roland Melkert]

I've found the cause its an array out of bounds thing concerning the editing pin disk's vertices. So it tries to render vertices from invalid memory. Windows doesn't seem to mind that sort of things

Well... I'm using Windows 10 Pro 64bit...

Seems they improved on that then

I'm regretting adding the 22.5 deg stuff as these bugs are related to those last minute changes. Including the rounding problem mentioned above as rotations through the keyboard were still using integer degrees (22 instead of 22.5 for a single step).

You can get rounding problems using 1 deg steps too, but it should take  longer then only 8 rotations though.

I've fixed both issues and if nothing else comes up I'll release Beta 1a around midnight (CET).

ps Milan: I tried making a binary patch using rdiff (linux) for you to try but it gave a >7MB file so you might as well wait on the 1a version I think.

[Roland Melkert]

Other/remaining problems: "+" problem in the Part bin is still there, the hotkey configuration menu does not warn you about a hotkey conflict, the amount of actions there starts being really long and hard for overview; for example even (sub)menu items are not prefixed with same text, like "MENU:" and/or grouped together.

I haven't addressed the shift++ issue yet. I'll try to make the dialog a bit more user friendly in beta 2. You could also try editing the main.hkc file directly most variables are 'understandable' I think.

Scripting: Please, can you summarize the extension of scripting API or send me your examples used for testing it? They do not need to be perfect and educational, I just need something to start with. You know, there will be a week between Christmas and the New Year, that's a good chance for me to have time for both LDCad and LPub3D.

Beta 1 has the new scripts (seeded) folder which contains a couple of global scripts by default. The samples one uses some of the new api objects (especially the wall and circle macro ones).

I've attached the animation script I used to make the https://youtu.be/34Ypp7HF1Dc  animation. I made that mainly to test / code the new aniTools module.

This reminds me another question: LPub3D uses archives of LDraw library plus additional directories. Plus ldraw.ini file containing the configuration of that, optionally. I still do not know details but I want to ask you if LDCad knows to cooperate with LPub3D on this so I, the user, will touch the same LDraw library in both programs, including unofficial parts, shadow information etc.?

LPub3D seems to use normal zipped library files so you could point LDCad to the same ones (LDCad supports using zips as is too)

[Milan Vančura]

ps Milan: I tried making a binary patch using rdiff (linux) for you to try but it gave a >7MB file so you might as well wait on the 1a version I think.

Sure, Roland. No stress   As I wrote above, I do not need to have this fixed for testing. I do not want to stress you, I just described those bugs as well as I could.

[Roland Melkert]

As reported above Beta 1 has some problems concerning the editing pin and the new 22.5 deg rotate stepping.

I deemed these problems/bugs severe enough to do a update to Beta 1a only a day later.

It is highly recommended to upgrade to this version asap, sorry if you just upgraded.

ps Milan: I tried making a binary patch using rdiff (linux) for you to try but it gave a >7MB file so you might as well wait on the 1a version I think.

Sure, Roland. No stress  As I wrote above, I do not need to have this fixed for testing. I do not want to stress you, I just described those bugs as well as I could.

No stress, I just hate scratches on my brand new version

[Philippe Hurbain]

As reported above Beta 1 has some problems concerning the editing pin and the new 22.5 deg rotate stepping

Sorry to have pushed you to make this last minute change

[Roland Melkert]

Sorry to have pushed you to make this last minute change

Don't worry about it, the AV was more the result of me wanting to cleanup the pin disc rendering/interaction code in order to make it dynamic (the old one always used 360 segments, the new one takes the current stepping into account instead).

[TestOne]

Hi all, one question aout snap information:
I've seen that there are some parts with wrong or missing snap information in the shadow library (as an example part 3839b and related have misaligned snap information for the handles, whilst part 3839a is ok). With parts like 3839b it isn't a problem to correct the snap point, but with parts like 58247 which one is the best way to find the right snap position (for vertical stands)? Is the 102° rotation a standard in all minifig accessories (I desumed it from the rotation matrix of already corrected parts), or is there a better way to find the correct orientation?
How do you choose the best orietnation/placement for part snapping when the snap information is missing or wrong? By analyzing the part elements?

[Roland Melkert]

Hi all, one question aout snap information:
I've seen that there are some parts with wrong or missing snap information in the shadow library (as an example part 3839b and related have misaligned snap information for the handles, whilst part 3839a is ok). With parts like 3839b it isn't a problem to correct the snap point, but with parts like 58247 which one is the best way to find the right snap position (for vertical stands)? Is the 102° rotation a standard in all minifig accessories (I desumed it from the rotation matrix of already corrected parts), or is there a better way to find the correct orientation?
How do you choose the best orietnation/placement for part snapping when the snap information is missing or wrong? By analyzing the part elements?

3839b is indeed very wrong, 58247 is actually the way it is on purpose as I figured that part is mostly used with minifig hand clips. I will add the other cylinders for 58247 too.

As for finding the orientation of things, I usually try to find the used cyli reference by selecting them one by one in the source window combined with using 'o' in 2D mode.

The whole shadow editing thing is a bit limited as it is essentially 'hacked' in because LDCad was never designed to be a part editor.  It used to be only enabled in my debug builds as it isn't very user friendly to say the least

[TestOne]

Hi all, one question aout snap information:
I've seen that there are some parts with wrong or missing snap information in the shadow library (as an example part 3839b and related have misaligned snap information for the handles, whilst part 3839a is ok). With parts like 3839b it isn't a problem to correct the snap point, but with parts like 58247 which one is the best way to find the right snap position (for vertical stands)? Is the 102° rotation a standard in all minifig accessories (I desumed it from the rotation matrix of already corrected parts), or is there a better way to find the correct orientation?
How do you choose the best orietnation/placement for part snapping when the snap information is missing or wrong? By analyzing the part elements?

3839b is indeed very wrong, 58247 is actually the way it is on purpose as I figured that part is mostly used with minifig hand clips. I will add the other cylinders for 58247 too.

As for finding the orientation of things, I usually try to find the used cyli reference by selecting them one by one in the source window combined with using 'o' in 2D mode.

The whole shadow editing thing is a bit limited as it is essentially 'hacked' in because LDCad was never designed to be a part editor.  It used to be only enabled in my debug builds as it isn't very user friendly to say the least

Yes, indeed, I have alway s seen it handled by minifig, but then I found this set and wanted to replicate it: http://brickset.com/sets/SW911511-1/Jedi-Weapon-Stand

Anyway great suggestion, with your tip I was able to edit the snap info by myself and I'll be able to find the best match for other parts in the future.
Your experience is always very much appreciated, thank you

[Roland Melkert]

View > Editing views > OpenGL view export (Export current view's OpenGL rendering to a png file)
View > Editing views > POV-Ray view export (Export current view's scene to a POV-Ray file)

Thanks! Seems a bit weird to put it under 'editing views' in my opinion. I expected it under file > export > POV-ray or something like that.
Anyway, gonna take a look at what it produces 

Concerning the povray export, you might want to use the attached colors.pov (place in %appdata%/LDCad/povray/default) as I made some improvements in it in regards to transparent parts.

[Merlijn Wissink]

Thanks! Seems a bit weird to put it under 'editing views' in my opinion. I expected it under file > export > POV-ray or something like that.
Anyway, gonna take a look at what it produces 

Concerning the povray export, you might want to use the attached colors.pov (place in %appdata%/LDCad/povray/default) as I made some improvements in it in regards to transparent parts.

Cool! I've rendered a relatively big Technic model a couple of days ago using LDCad's export feature. The image is being used on the cover of the instructions. I was actually planning on using LDView together with LGEO, but I had to set it up from scratch (due to a forced Windows reinstall couple of months ago) and I couldn't get it to work. In the end, I thought 'hey! LDCad can export too!' and thus I used LDCad's export.

It looks quite good. Although, the whole lighting seems a bit low/dark to me and the parts look a little too shiny. Especially red bricks looked a little too dark, but again, that might've been the lighting. Other than that it looks pretty good.
I don't think I can share those images (yet) in public, but I could send you a PM if you'd like to see them.

I don't know if you were planning to take the exporter further or not, but it would be really cool if you'd make it like LDD-to-POV-Ray. A program like that is severely lacking the in the LDraw ecosystem. There are a lot of ways to export LDraw to POV-Ray, there are a lot of guides on how to make the POV-Ray render look better by manually editing stuff, but there's no in between.

If you don't know LDD-to-POV-Ray, here are some example images of what LDD-to-Pov-Ray can do.

I know that would be a lot of work, but it also would be really cool and useful. 

[Roland Melkert]

It looks quite good. Although, the whole lighting seems a bit low/dark to me and the parts look a little too shiny. Especially red bricks looked a little too dark, but again, that might've been the lighting. Other than that it looks pretty good.
I don't think I can share those images (yet) in public, but I could send you a PM if you'd like to see them.

Currently it uses a single parallel light simular to the OpenGL one used inside the editor. You can add more (shadow less ones) by using an include file or by editing the .pov file afterwards. I do plan to make it more configurable from inside LDCad in a future version though.

I don't know if you were planning to take the exporter further or not, but it would be really cool if you'd make it like LDD-to-POV-Ray. A program like that is severely lacking the in the LDraw ecosystem. There are a lot of ways to export LDraw to POV-Ray, there are a lot of guides on how to make the POV-Ray render look better by manually editing stuff, but there's no in between.

I'm still tweaking the defaults and some improvements are planned to help with choosing the zoom etc. I'm also thinking abuot adding LGEO support but that system is so fragmented at the moment that I first have to (re)familiarize with it myself.

If you don't know LDD-to-POV-Ray, here are some example images of what LDD-to-Pov-Ray can do.

That looks very extensive, my previous exporter (inside LD4DStudio) had more options but I felt no one was using that. So with this one I choose to outsource most things to the .pov files inside the %appdata% folder that way advanced users can make custom settings while the other users have a 'simple' dialog.

[Roland Melkert]

I've processed the new LDraw 2016-01 parts.

Luckily most parts were variants of existing ones so I only needed to create 80+ new shadow files.

This means the all parts in the sorted branch (except the alias, colored and obsolete subbranches) should once again have snap and mirroring info.

the seedfile is here:
http://www.melkert.net/action/download/shadow.sf

place it in the seeds folder (usually C:\Program Files (x86)\LDcad\seeds) while LDCad is closed.



ps: why can't I attach a .sf file?, it's just a renamed zip file. extension based security isn't really secure.

[Orion Pobursky]

ps: why can't I attach a .sf file?, it's just a renamed zip file. extension based security isn't really secure.

Fixed.

There more to the attachment limitations than just security like size limits. Also, the backend checks to make sure that the file you upload really is of the type you say it is.

[Roland Melkert]

Fixed.

Thanks

[Merlijn Wissink]

So, the first beta version of 'Rebrickable V3' is online.
And... It has an LDCad parts bin export for parts lists. 

I haven't tried it yet, so I don't know the quality of the export, but it'll certainly be a nice easy quick-start if you need any set's .pbg file.

[Roland Melkert]

If anyone has some pending issues/problems with the 1a version please let me know.

Because I'm at the final stages of Beta 2 (the binary is finished, I'm just working on a scripting oriented test project)

I ask because I would like Beta 2 to be the last beta followed by the final version with minimal additional changes.

[Philippe Hurbain]

If anyone has some pending issues/problems with the 1a version please let me know.

Because I'm at the final stages of Beta 2 (the binary is finished, I'm just working on a scripting oriented test project)

I ask because I would like Beta 2 to be the last beta followed by the final version with minimal additional changes.

Works really fine for me. But I just got a little blitch, tried a POV export, and POV chokes on this line:

#macro ldrawTexPearl(ldCode, pngIdx)    
 ldrawBuildTex(ldrawPigment(getColorIndex(ldCode), -1, -1), ldrawPearlNor, ldraPearlFin, pngIdx)
#end

(uninitialized identifier)

[Roland Melkert]

tried a POV export, and POV chokes on this line:

#macro ldrawTexPearl(ldCode, pngIdx)    
 ldrawBuildTex(ldrawPigment(getColorIndex(ldCode), -1, -1), ldrawPearlNor, ldraPearlFin, pngIdx)
#end

(uninitialized identifier)

I noticed that one awhile back, it's a typo

You can fix it by editing the povray/defaults/colors.pov file

ldrawBuildTex(ldrawPigment(getColorIndex(ldCode), -1, -1), ldrawPearlNor, ldrawPearlFin, pngIdx)

or use the attached file, it has some other changes/tweaks

[Milan Vančura]

If anyone has some pending issues/problems with the 1a version please let me know.

Hello Roland, this is on my list:

bug: LDCad exits with exitcode 255 and without any message on the screen if it found the lock file (after previous segfaulted LDCad run).

of course, you may ask about that segfault. Unfortunately, I cannot reproduce that and there was not even any special action I did in LDCad before the crash. It was pure (bad) surprise.

features:

* as I wrote earlier, I wish the hotkey settings window checking if the same hotkey is not already assigned in the same "category" (how to call it? I mean that some "same" hotkeys are not in conflict, the same hotkey does actionA in partbin subwindow and actionB in the main edit window).

* for the same reason, I'd like to have actions in the hotkey settings winow sorted by those "categories"

* actions for calling (sub)menus have long ("poetic" ) names now and are spread among other actions. I'd like to have them together and clearly named: "Menu: File", "Menu: View -> Editing views" and so.

documentation:

* new scripting extensions/objects documented, of course. Including example scripts, the best

probably too big features for this release phase...:

* object "snap object" accessible from scripts and visible (like after pressing F11) and selectable by user. To be able to write a script making triangles without asking the user for adding extra axles etc. Also for setting the part rotation point etc.

[Philippe Hurbain]

Ah - Should have seen the typo! Works better now, but not with your attached color.pov: it contains the very same typo ;D

[Philippe Hurbain]

...and a future feature wish...
Would be nice if view export (both OpenGL and POV) offered better framing ability. Currently it's pretty much a guess work, requiring several iterations. What about a frame overlay on 3D view, along with possibility to pan/rotate/zoom view?

[Philippe Hurbain]

* new scripting extensions/objects documented, of course. Including example scripts, the best

Yes, I'd like to see some BOM related examples

[Philippe Hurbain]

Something I almost forgot to report (I wanted to be able to reproduce it reliably but couldn't): sometimes, if I try to shutdown Windows with LDCad running, I get a LDCad crash. Occured at least three times, on two different machines (both with Win7/64b). Nothing in log.

[Roland Melkert]

...and a future feature wish...
Would be nice if view export (both OpenGL and POV) offered better framing ability. Currently it's pretty much a guess work, requiring several iterations. What about a frame overlay on 3D view, along with possibility to pan/rotate/zoom view?

I attached the wrong one (hadn't regenerated the .sf files), attached is the correct one. Changes mostly concern transparent parts.

As for the framing stuff, I was hoping to do something like you mention in Beta 2 but I kinda forgot about it I see if I can do something small but very helpful.

[Roland Melkert]

bug: LDCad exits with exitcode 255 and without any message on the screen if it found the lock file (after previous segfaulted LDCad run).

Did it crash while working or could it be similar to the Windows shutdown bug Philo mentions below? Do you mean the single instance/ipc lock file(s) in /tmp or ~ ?

* as I wrote earlier, I wish the hotkey settings window checking if the same hotkey is not already assigned in the same "category" (how to call it? I mean that some "same" hotkeys are not in conflict, the same hotkey does actionA in partbin subwindow and actionB in the main edit window).

* for the same reason, I'd like to have actions in the hotkey settings winow sorted by those "categories"

* actions for calling (sub)menus have long ("poetic" ) names now and are spread among other actions. I'd like to have them together and clearly named: "Menu: File", "Menu: View -> Editing views" and so.

They are currently sorted in processing order, I figured that makes the most sense as keys belonging together will be in order. The problem with the "menu: file -> *" approach is 'actions' can be used in multiple places. Maybe I should add an extra column with a short subgroup name e.g. 'gen editing', 'grouping', etc.

I did make one improvement in Beta 2 you asked for though, key sampling

* new scripting extensions/objects documented, of course. Including example scripts, the best

API reference will be updated once I completed them in their final state (which it probably is with Beta 2).

* object "snap object" accessible from scripts and visible (like after pressing F11) and selectable by user. To be able to write a script making triangles without asking the user for adding extra axles etc. Also for setting the part rotation point etc.

I've been thinking about accessing snap info through script, it isn't even that intrusive to existing code I think even so if you only need position and rotation (not any of the other connection type depended properties.)

[Roland Melkert]

Something I almost forgot to report (I wanted to be able to reproduce it reliably but couldn't): sometimes, if I try to shutdown Windows with LDCad running, I get a LDCad crash. Occured at least three times, on two different machines (both with Win7/64b). Nothing in log.

Did it have changes causing the shutdown to report 'program is not responding' etc or would it otherwise close without any dialogs.

[Roland Melkert]

* new scripting extensions/objects documented, of course. Including example scripts, the best

Yes, I'd like to see some BOM related examples

You mean actually generating a HTML or something with the used parts list?

[Philippe Hurbain]

Something I almost forgot to report (I wanted to be able to reproduce it reliably but couldn't): sometimes, if I try to shutdown Windows with LDCad running, I get a LDCad crash. Occured at least three times, on two different machines (both with Win7/64b). Nothing in log.

Did it have changes causing the shutdown to report 'program is not responding' etc or would it otherwise close without any dialogs.

File saved, etc. Got it again this morning, but I failed stopping Windows shutdown in order get some useful information. Tried again several times , LDCad closed gracefully. The session was as simple as open LDCad, load a file (no modification), shutdown Windows -> crash (trying to access a wrong location, that's all I had time to see).

[Philippe Hurbain]

Yes, I'd like to see some BOM related examples

You mean actually generating a HTML or something with the used parts list?

Yes, something like this... Bill of materials per model, possibly per submodel, ideally with a thumbnail generation for each part.

[Milan Vančura]

bug: LDCad exits with exitcode 255 and without any message on the screen if it found the lock file (after previous segfaulted LDCad run).

Did it crash while working or could it be similar to the Windows shutdown bug Philo mentions below? Do you mean the single instance/ipc lock file(s) in /tmp or ~ ?

It crashed during working and unexpectedly - I didn't do anything special. In fact, I was in the middle of moving the mouse pointer when LDCad crashed. That's why I cannot reproduce that any longer - I have no clue.
However, the problem with exitcode 255 can be simulated without any previous crash. All you need to do is to run LDCad and then run the second one. It ends almost immediately (with exitcode 255) and tries to bring the window of the first LDCad instance to the foreground. But if it is not possible, for example because the first LDCad window is on another virtual screen, all you can see is a very fast blink, something like the very first window with LDCad welcome message and credentials, immediately disappearing back again and that's all. The second LDCad instance exits with exitcode 255 with no visible action. I had to run it in strace to see what happened.

[Roland Melkert]

* object "snap object" accessible from scripts and visible (like after pressing F11) and selectable by user. To be able to write a script making triangles without asking the user for adding extra axles etc. Also for setting the part rotation point etc.

You are right this is to big a change for 1.6, but i'm in the mid of adding basic snap info access. However now I'm thinking it might be completely useless without a way to choose the actual wanted one.

For example the simple 2x4 birck has 16 snap info objects. Being able to access those 16 data points might be handy for some others things though.



Currently I'm working on this (the luaCB_* functions will become available inside lua without the luaCB_ prefix).

Code:

 class TLuaSnapInfo : public TLuaUserData {
   private:
     typedef TLuaUserData inherited;

     static const int posOriCore(lua_State *luaState, const bool doPos, const bool doOri); //override

   protected:
     virtual void boolParamIO(bool &value, const int index, const bool doGet, TLuaWrapper *lua); //override
     virtual void strParamIO(TString &value, const int index, const bool doGet, TLuaWrapper *lua); //override

   public:
     TLuaSnapInfo() : inherited() {}

     static const char *ldcSubModName;
     static const char *luaTypeName;
     static const luaL_Reg subModFuncs[];
     static const luaL_Reg objFuncs[];
     static void ldcLibReg(lua_State *luaState) { basic_ldcLibReg(luaState, ldcSubModName, subModFuncs, luaTypeName, objFuncs); }

     static int luaCB_gc(lua_State *luaState) { return basic_gc(luaState, luaTypeName); }
     static int luaCB_toString(lua_State *luaState) { return basic_toString(luaState, luaTypeName); }

     static int luaCB_new(lua_State *luaState);
     static int luaCB_clone(lua_State *luaState) { return basic_clone(luaState, luaTypeName); };

     static int luaCB_isCYL(lua_State *luaState) { return singleBoolParamIO(luaState, luaTypeName, 0, true); }
     static int luaCB_isCLP(lua_State *luaState) { return singleBoolParamIO(luaState, luaTypeName, 1, true); }
     static int luaCB_isFGR(lua_State *luaState) { return singleBoolParamIO(luaState, luaTypeName, 2, true); }
     static int luaCB_isGEN(lua_State *luaState) { return singleBoolParamIO(luaState, luaTypeName, 3, true); }

     static int luaCB_getID(lua_State *luaState) { return singleStrParamIO(luaState, luaTypeName, 0, true); }
     static int luaCB_getGroup(lua_State *luaState) { return singleStrParamIO(luaState, luaTypeName, 1, true); }

     static int luaCB_isMale(lua_State *luaState) { return singleBoolParamIO(luaState, luaTypeName, 4, true); }
     static int luaCB_isFemale(lua_State *luaState) { return singleBoolParamIO(luaState, luaTypeName, 5, true); }

     static int luaCB_getPosOri(lua_State *luaState) { return posOriCore(luaState, true, true); }
     static int luaCB_getPos(lua_State *luaState) { return posOriCore(luaState, true, false); }
     static int luaCB_getOri(lua_State *luaState) { return posOriCore(luaState, false, true); }

     virtual TLuaUserData *clone() const { return new TLuaSnapInfo(*this); } //override
     virtual const char *getLuaTypeName() const { return luaTypeName; } //override
 };

So do you think it's worth including anyway?
Any idea on additional stuff needed to make this usable?

[Milan Vančura]

So do you think it's worth including anyway?
Any idea on additional stuff needed to make this usable?

Thanks for starting your work on this, Roland! I think it would be better to release 1.7_Alpha1 with this feature (as soon as possible) so we all can test the new interface, send you a feedback and you can decide freely what/how to change or improve.

What I see now:

* those test functions (isCYL etc.) are four only, where is, for example, isAxle?
* I do not see any functions to get a part this snap object is a part of and vice versa - a list of part's snap objects
* for future, it would be nice to have a function connected_snaps() returning a list of snap objects "snapped" to this one

About your question: I'm not sure what do you mean about those 16 snap objects of a brick 2x4. Too many of them? Or how to use them? I believe it is really usable to have a way how to display them and be able to select one (or more). For example, imagine a brick 1x6: with this feature, it would be - finally! - possible to put it in the non-right angle, like using Pythagorian triangle 3,4,5. It's a common technique in a real LEGO building (i.e. putting a house on a terrain in another angle than 90 deg) but hard to do in LDCad without calculating the angle manually. And many other examples.

[Roland Melkert]

Thanks for starting your work on this, Roland! I think it would be better to release 1.7_Alpha1 with this feature (as soon as possible) so we all can test the new interface, send you a feedback and you can decide freely what/how to change or improve.

I've completed these basic functions and will keep them for 1.6 but like you say the rest is best kept for the next version (ether 2.0 or 1.7) as it really needs more gui access and extended snap info.

* those test functions (isCYL etc.) are four only, where is, for example, isAxle?

These objects are mappings to the internal data which results from the shadow meta info (SNAP_CYL, SNAP_FGR, SNAP_CLP, SNAP_GEN). LDCad doesn't know what an 'axle' is it only matches the shape info. You can however in the meta assign group and id names to metas which will be preserved into the flattened data. The generic meta for axles (p/axle.dat) does this through its id=axle property. I've made those id and group properties available in the lua interface.

* I do not see any functions to get a part this snap object is a part of and vice versa - a list of part's snap objects

You access them through a subfile object, like so:

Code:

function runTest()
 local sf=ldc.partBin():getWorkPart()
 local cnt=sf:getSnapInfoCount()
 
 print(sf:getSnapInfoCount())
 
 for i=1,cnt do
   local snap=sf:getSnapInfo(i)
   print('id='..snap:getID()..' gen='..snap:getGender()..' kind='..snap:getKind()..' len=', snap:getLength(), ' r=', snap:getRadius(), ' posOri=', snap:getPosOri())
 end
end

which for "32016.dat" would output:

Code:

3
id=connhole gen=F kind=CYL len=20.0 r=8.0 posOri=0 0 0 0 -1 0 1 0 0 0 0 1
id= gen=F kind=CYL len=20.0 r=6.0 posOri=0 0 -30 1 0 0 0 0 1 0 -1 0
id= gen=F kind=CYL len=20.0 r=6.0 posOri=0 -11.481 27.716 1 0 0 0 -0.383 -0.924 0 0.924 -0.383

* for future, it would be nice to have a function connected_snaps() returning a list of snap objects "snapped" to this one

That would be very nice indeed Currently no 'connected' information is used at all, this is something I very much would like for 2.0 though.

About your question: I'm not sure what do you mean about those 16 snap objects of a brick 2x4. Too many of them? Or how to use them? I believe it is really usable to have a way how to display them and be able to select one (or more). For example, imagine a brick 1x6: with this feature, it would be - finally! - possible to put it in the non-right angle, like using Pythagorian triangle 3,4,5. It's a common technique in a real LEGO building (i.e. putting a house on a terrain in another angle than 90 deg) but hard to do in LDCad without calculating the angle manually. And many other examples.

The problem I'm thinking of here; there is currently no simple way of determining which of those 16 snap info points you want to use in your scripts for things like triangle placements etc. It will need a GUI component to be really useful.

But then again once I make snap info selection available in the main GUI you might not need these things through script anymore.

Which is way I'm considering going the blender way and make all high level editing stuff script based while keeping the LDCad (2.0) binary limited to low level operations and rendering only. That's just something I'm considering though, nothing is set in stone

[Owen Dive]

That would be very nice indeed Currently no 'connected' information is used at all, this is something I very much would like for 2.0 though.

Yes, a "Select things that are connected to this piece" would be very helpful!

[Milan Vančura]

I've completed these basic functions and will keep them for 1.6 but like you say the rest is best kept for the next version (ether 2.0 or 1.7) as it really needs more gui access and extended snap info.

Good! Also thanks for your explanation about accessing the snap objects of the part. But yes, you are right this scripting interface is not so usable until there is a GUI allowing the user to select the wanted snap point manually - and then Lua function to get the part this snap point is in will be also needed. So I hope for a release of 1.7 soon, in usual time since 1.6 as you released previous versions. That "2.0" makes me nervous a little bit, it looks like years of development before anything is ready to use

* for future, it would be nice to have a function connected_snaps() returning a list of snap objects "snapped" to this one

That would be very nice indeed Currently no 'connected' information is used at all, this is something I very much would like for 2.0 though.

I think there are two slightly different problems: one is to have a complete graph of connected parts in the model, as SR3D knew, including a type of a connection (hinges, axles in holes, gears...). This is really complicated, I can imagine. However, just asking "which snap point is 'snapped' to this specific ONE" is much easier problem and you already have a (very fast) function in LDCad, it is used every time you place new piece to the model or move so part(s) in the model. I mean to use that in the scripts. For example to find the bend point automatically.

Which is way I'm considering going the blender way and make all high level editing stuff script based while keeping the LDCad (2.0) binary limited to low level operations and rendering only. That's just something I'm considering though, nothing is set in stone

It's a nice idea. I cannot estimate how much work it is (see my fear at the beginning of this post ) but it is definitely promising. Every time I see these ideas of yours my dreams start, from simple macros up to the instructions maker integrated in LDCad.

[Willy Tschager]

Roland,

beta 1a is missing the minifig:


  Minifig.ldr (Size: 1.13 KB / Downloads: 3)

in the misc shortcuts.

w.

[Willy Tschager]

Feature request of the day:

In addition to the category labels - https://forums.ldraw.org/thread-21693-po...l#pid23067 I wish there was a special category that loads in the background the category of the selected part in the working area. To be more precise. Given you have selected a horse in the working area, the special tap would load the animal category in the background. If I would I could just jump form the plates, bricks, ... tap to that special tap with no need to go upwards.

w.