LDraw.org Discussion Forums
LDCad 1.4b (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.4b (win+linux) (/thread-15371.html)

Pages: 1 2 3 4 5 6 7 8 9 10


Re: LDCad 1.4b (win+linux) - Philippe Hurbain - 2015-03-26

While reading basic editing documentation, a few things came up...

- I noticed a little glitch: after saving a new model, top right screen area is properly updated with file name, but LDCad main window title still says "[New file]"
- In move mode, what about pair of shortcut keys to move in direction perpendicular to editing plane? I thought to PgUp/PgDn but they are already used for step. Maybe ctrl+arrows? Now I understand that this is not only orthogonal to the editing plane but also to LDCad philosophy...

- Not related, but I found a subtle connectivity bug: the small technic panel connects to axle 2 with a 1 ldu offset, only at one end of the axle... See attached file.
- And another: Bionicle tooth 41669 snaps on axles with a 2 ldu offset.


Re: LDCad 1.4b Documentation - Roland Melkert - 2015-03-26

Thanks Philo,

I've applied all your changes and also added a short GUI template section to keep you busy Smile


Re: LDCad 1.4b Documentation incl (snap) metas - Roland Melkert - 2015-03-29

I've finished the technical documentation (for now) by adding info about:

donor and template files

LDCad meta lines

shadow library

The meta information includes all meta I've 'invented' for LDCad specific things over the years.

This includes the part snapping format used in the shadow library so if anyone wants to take a go on adding snap information to parts let me know Smile


Re: LDCad 1.4b Documentation incl (snap) metas - Philippe Hurbain - 2015-03-30

OK, I bit the bullet and tried to make/modify a few (attached).
- Creation of connectivity for 30374 Bar 4L Light Sabre Blade, 10050 Minifig Sword Uruk-Hai and 10053 Minifig Sword Small with Curved Blade (Bars with free ends, one end blocked, 2 ends blocked)
- Added top stud connectivity to 3820 minifig hand and 92244s01.dat Friends arm subpart
- Replaced inherited connectivity to 41669 Technic Tooth 1 x 3 with Axlehole (offset of axle hole primitive caused a 2 ldu offset of part when placed with a coarse grid, as reported here)
- Corrected axle connectivity of 11947 Technic Panel Fairing Smooth #22. Axle is blocked by a small ridge in the part, so "extension of axle" present in previous connectivity file was wrong. Removing it also cured the offset problem also mentionned here though I don't understand why it caused this problem.
- Created connectivity for unofficiel 4429 Figure Flask with Handle (stud tubes on bottom, tilted bars of handle).

Things that proved a bit harder than I initially expected:
- Restarting LDCad to be able to test a new definition is a bit painful. Maybe a "clear cache" option to force reload? (useless of course if reload time would be almost as long as restarting completely)
- I initially expected to be able to derive things more or less directly from LDraw part source, but connectivity cylinder extend at the opposite of LDraw cylinder, and orientation matrix needs to be normalized, both issues making things more difficult (especially the first one, annoying for a "directionnally challenged" guy like me Wink - What about giving the possibility to specify a negative lenth to compensate?


Re: LDCad 1.4b Documentation incl (snap) metas - Roland Melkert - 2015-03-30

Thanks I'll add them to the default csl.

did notice the minifig hand (3820) stud being a bit off though Smile, it should be:

Code:
0 !LDCAD SNAP_CYL [ID=studC] [gender=M] [caps=one] [secs=R 6 7.35] [pos=0 -0.0005 -9.6816] [ori=1 0 0 0 0.9681 -0.2504 0 0.2504 0.9681]


Philippe Hurbain Wrote:Things that proved a bit harder than I initially expected:
- Restarting LDCad to be able to test a new definition is a bit painful. Maybe a "clear cache" option to force reload? (useless of course if reload time would be almost as long as restarting completely)

Yes, I usually work in batches minimizing the need to restart, but with the more complicated parts now left it becomes a problem. This is the main reason I'm working on file reloading when changes are detected for LDraw files (and probably most of the other files like part bin groups etc).

Philippe Hurbain Wrote:- I initially expected to be able to derive things more or less directly from LDraw part source, but connectivity cylinder extend at the opposite of LDraw cylinder, and orientation matrix needs to be normalized, both issues making things more difficult (especially the first one, annoying for a "directionnally challenged" guy like me Wink - What about giving the possibility to specify a negative lenth to compensate?

I haven't had to do much normalizing so far but with the more complicated parts left without info this too becomes a time bottleneck. For this reason 1.5 will be able to edit the snap info inside the editor itself so you can use the normal editing tools and some new ones (like normalize) and more importantly see what you are doing Smile.

Normalizing the matrix isn't too hard though just tread the 9 ori numbers like 3 vectors and normalize those.


Re: LDCad 1.4b (win+linux) - Roland Melkert - 2015-03-30

Sorry I seem to have missed this post.

I could assign a key to moving along the editing plane dead axis, problem is there are indeed not many logical keys left. It could be solved by the planned (prob 1.6) key reassignment feature as you could then assign it to anything you want while being 'unbound' by default.

I'll also check if there's something else (bug like) at play concerning those offsets I seem to remember fixing a similar issue a while back but I don't know if this was in the 1.5 or earlier source.

Thanks for reporting.


Re: LDCad 1.4b (win+linux) - Owen Dive - 2015-04-01

Given the choice between limiting the input and changing to 128-bit precision, I would suggest limiting the input. If you change to 128-bit precision you're not fixing the problem, just moving it - I could still put in an angle to a bajillion decimal places and cause an overflow. Besides, who needs to specify an angle to that level of precision anyway? Unless I got my math wrong, a change in the 10th decimal place of an angle will result in a displacement of less than 0.01LDU on an arm of half a kilometer.

Sorry if this reply is too late and you've already written the code - not sure why it didn't occur to me on any of my previous readings of this thread!


Re: LDCad 1.4b Documentation incl (snap) metas - Philippe Hurbain - 2015-04-14

An attempt for adding connectivity to 9V train tracks... Bottom tubes connectivity of switch points not implemented.
I used oversized connectivity volumes to help snapping from a distance. Perhaps even not oversized enough!


Re: LDCad 1.4b Documentation incl (snap) metas - Roland Melkert - 2015-04-15

Philippe Hurbain Wrote:An attempt for adding connectivity to 9V train tracks... Bottom tubes connectivity of switch points not implemented. I used oversized connectivity volumes to help snapping from a distance. Perhaps even not oversized enough!

Minor bug: 2865s03.dat anti stud info uses a swapped x/z grid.

As for the over sized bounding box. LDCad does bb intersection tests on those to find the closest so it might help if you use a cylinder bounding instead of a box.

But like you already figured it won't snap if its too far away even if its the only thing. This is mainly to limit the number of tests (preventing to test e.g. whole datsvile while adding a single brick). Personally I also like it to fallback to grid placement when its out of reach in order to minimize having to turn snapping on and off while building second structures etc. I could add an option to change this behavior though.

Anyway having very large bounding boxes isn't 'misuse' as its the goal of the bounding property. So you could even use a cylinder with a radius of half the length of the rail Smile. Also the male and female info doesn't need to have the same dimensions ether just the same (rest) orientation.

1.5 introduces the shape property for SNAP_GEN meta's which will need to be the 'tight' bounding box and can optionally be used for matching, it will default to 'not used' though.

Again thanks for the tests/reports Philo.


Re: LDCad 1.4b Documentation incl (snap) metas - Philippe Hurbain - 2015-04-15

Thanks for your comments about switch points , I'll have a closer look when I am back home (travelling now...)
Just found a little issue: If you create a path flex part big enough (eg. my VEX track part), bounding box is large enough to prevent reaching the size handles when in 2D mode (you move the whole control point instead). And (an old one but I think I never told you), the size of the control point thing is imho too small and too thin, often quite difficult to select it...