LDraw.org Discussion Forums
LDCad 1.6 Beta 1 (win+linux) - Printable Version

+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: LDraw Programs (https://forums.ldraw.org/forum-7.html)
+--- Forum: LDraw Editors and Viewers (https://forums.ldraw.org/forum-11.html)
+--- Thread: LDCad 1.6 Beta 1 (win+linux) (/thread-21955.html)

Pages: 1 2 3 4 5 6


RE: LDCad 1.6 Beta 1 (win+linux) - Philippe Hurbain - 2017-01-31

(2017-01-30, 20:39)Roland Melkert Wrote:
(2017-01-30, 19:09)Philippe Hurbain Wrote: 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).


RE: LDCad 1.6 Beta 1 (win+linux) - Philippe Hurbain - 2017-01-31

(2017-01-30, 21:06)Roland Melkert Wrote:
(2017-01-30, 12:39)Philippe Hurbain Wrote: Yes, I'd like to see some BOM related examples Wink

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.


RE: LDCad 1.6 Beta 1 (win+linux) - Milan Vančura - 2017-02-01

(2017-01-30, 20:37)Roland Melkert Wrote:
(2017-01-30, 8:21)Milan Vančura Wrote: 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.


RE: LDCad 1.6 Beta 1 (win+linux) - Roland Melkert - 2017-02-03

(2017-01-30, 8:21)Milan Vančura Wrote: * 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?


RE: LDCad 1.6 Beta 1 (win+linux) - Milan Vančura - 2017-02-04

(2017-02-03, 21:18)Roland Melkert Wrote: 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.


RE: LDCad 1.6 Beta 1 (win+linux) - Roland Melkert - 2017-02-04

(2017-02-04, 21:42)Milan Vančura Wrote: 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.

(2017-02-04, 21:42)Milan Vančura Wrote: * 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.


(2017-02-04, 21:42)Milan Vančura Wrote: * 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


(2017-02-04, 21:42)Milan Vančura Wrote: * 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 Smile Currently no 'connected' information is used at all, this is something I very much would like for 2.0 though.


(2017-02-04, 21:42)Milan Vančura Wrote: 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 Smile


RE: LDCad 1.6 Beta 1 (win+linux) - Owen Dive - 2017-02-05

(2017-02-04, 22:42)Roland Melkert Wrote: That would be very nice indeed Smile 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!


RE: LDCad 1.6 Beta 1 (win+linux) - Milan Vančura - 2017-02-06

(2017-02-04, 22:42)Roland Melkert Wrote: 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 Smile



(2017-02-04, 22:42)Roland Melkert Wrote:
(2017-02-04, 21:42)Milan Vančura Wrote: * 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 Smile 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.

(2017-02-04, 22:42)Roland Melkert Wrote: 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 Smile

It's a nice idea. I cannot estimate how much work it is (see my fear at the beginning of this post Smile ) 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.


RE: LDCad 1.6 Beta 1 (win+linux) - Willy Tschager - 2017-02-08

Roland,

beta 1a is missing the minifig:


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

in the misc shortcuts.

w.


RE: LDCad 1.6 Beta 1 (win+linux) - Willy Tschager - 2017-02-08

Feature request of the day:

In addition to the category labels - https://forums.ldraw.org/thread-21693-post-23067.html#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.