Do we need another LDraw building program?

[Mario Pascucci]

Hi all.
I'm working on a simple builder in Java, derived from JLDraw Java viewer, but now I wonder if we really need yet another building software

My program will have a building mode with "autoconnect", i.e. new part will "snap" to nearest connection on line of sight (it is already done for studs, tubes, some technic pin and pegholes, but needs lots more work for other connections).

It is in Java, so we have "one version is good for all". Some drawbacks are the "rough" rendering (You must optimize a lot if you want some accettable speed in Java...), and probably the maximum size of a model, that will be in the order of 5k-10k parts (i'll not tested yet).

The coming of "MOC Builder" from Bricklink will make my program useless, I think.

So, I'm here to ask for your opinion: we need another building software? Please talk frankly and be direct: I'll survive to your criticism :-p ;-)

Thank you in advance.

[Orion Pobursky]

My feeling is the more choice the better it is. Bonus points for being open source

[Scott Wardlaw]

When I built my Java based builder a few years ago, I knew it would not be the best out there, but it gave me the experience in OpenGL I needed to take on new projects at work.

I'm glad to see so many Java developers that are interested in LDraw based programing. I'd really like to see more developers working together on one program.

Since MOC Builder is supposedly backed by Bricklink and is fairly well along, it seems to be a good choice.

If you're having fun and learning with your own project...keep going. If you want to help build the best LDraw program...join a team.

Best of luck,
Scott

[Michael Heidemann]

You are right, there are already some good builders for models in our LDraw Systems of Tools.

But as far as I can see there is only 1 (two if I count LDForge) application (MLCad) for designing the parts itself.

I think that it is far more complicate to write such an application and therefore the lack of alternatives.

If you like to do some work for the community - this would be a good choice IMHO.

[Steffen]

Hey, cool to see you around here!

If you want to hear my humble opinion on your question, then I'd answer like this:

yes, it is fun writing an LDRAW parser and creating some GUI application around it for editing, snapping, etc.
I myself feel the urge to do so from time to time again.
And when you do that, you learn a lot. You can design your parser to be a "real" parser like taught in the books
(tokenizer, parser, annotated syntax tree, cache, etc.) or make it a quick and dirty or simple solution.
And you learn a lot about OpenGL and or GUI libraries. Or WebGL. And interesting aspects like "efficiency" of
the program language you use.

So I would agree with the previous posters:
if you get fun or a learning from it, why not go on.
But I think the best community effort would be achieved if we would not have 100 small/incomplete editors,
but instead just 1 or 2 or 3, maybe written in different languages or using different approaches,
which are developed cooperatively. There is anyway so much work to do and so few people writing parts or software
that we should combine our efforts IMHO.

[Nicola]

Hi, i'm interested in a java based building program! Mind to share some more details? Such as what libraries are you using etc

Are the sources available yet? I'd love to peek inside

EDIT: i see you're a fellow italian, from romabrick right ?

[Mario Pascucci]

Hi Nicola.

Yes, I'm part of Romabrick people.

If you want, we can use email to talk (in italian... )

I haven't released any code (yet) but most of the work is derived from my Java viewer JLDraw, available from SourceForge:
https://sourceforge.net/projects/jldraw/

At the moment, program relies on some key libraries:
- LDraw part library and model handling. Reads and parse parts files from official or unofficial library (zipped or installed a folder), reads models, handles parts cache and connection points database (last is work in progress)
- LDraw 3D library. Highly optimized part/model renderer, handling of part moving, connection point "snap", model connection handling (adding and removing connection point according of part placement/removing).
- LDraw part database library. Used to search parts from description/keywords/name/id using full text search engine (H2 pure Java database with Lucene indexer. Yes, I'm using nuclear weapon to kill a mosquito...)

[Michael Horvath]

I would be happy with a version of MLCAD that isn't buggy and takes advantage of hardware acceleration. When it works, my preferred modeler is still MLCAD.

[Max Martin Richter]

Well, this might be work for simple brick stacking but it's more or less impossible to build complex technic models. When I used MLCad for building technic models I used autocad for drawing areas with angles for getting the right rotation values...

/Max

[Santeri Piippo]

And unfortunately MLCAD is closed source as well so all we can really do about it is to replace it. What is with all this closed sourcedness anyway in most programs I've seen here on LDraw? It seems a bit insulting to the open standard.

[Nicholas Zurn]

We could always use another open source building program or fork of an existing one. It is such a shame that everything seems to be so closed off.



What I really would like to see is an online editor and mobile apps (that are open source). Such a shame that mecabricks.com isn't LDraw compatible.

[Roland Melkert]

What is with all this closed sourcedness anyway in most programs I've seen here on LDraw?

Personally I find it very hard to just put it all out there, if you know what I mean.

Take LDCad for instance, I've been working on it for 3 years now it has grown to over 121,000 lines of c++ code it is not just 'some program' to me and thus hard to set free.

So in general it's probably because I'm a bit paranoid and or overprotective about my work.

[Nicholas Zurn]

Hope you never lose interest in it or pass away.

[Santeri Piippo]

If ever you cease to work on it though, it'll eventually just be another burden for us to get rid of, like MLCAD.

[Steffen]

Hey, I just wanted to say that I understand the closed-sourceness (please don't hit me everybody).
If you've shed some heartblood and put some magic into your code, you sometimes feel that
you do not want to open it publicly. You need to first put your mind to it. I find it perfectly legitimate
for a program author to decide like this and not being bashed for it. If somebody doesn't like
that approach, then he can always decide to not use that program Writing a closed-source
program is the good right of every free man OK, open source has other advantages,
so I am of course not argumenting against it. Both principles have their right of existence.

[Nicola]

What I really would like to see is an online editor and mobile apps (that are open source). Such a shame that mecabricks.com isn't LDraw compatible.

mecabricks is a great project.. it's a pity indeed.
Three.js has a nice simple editor, doesn't have much functionality but looks very well done. It could be a great starting points.. just saying

[Michael Horvath]

I think there is a lot of subpar open source software unfortunately. And with closed source software at least you get a better indication when a project is dead.

[Michael Horvath]

Forgot to mention that since I spend most of my time working on Datsville, an app written in Java is not going to work for me due to the additional overhead and slowness of that platform.

[Jason Smith]

What about MOC Builder as a open source program? http://forums.ldraw.org/showthread.php?tid=14349

[Mario Pascucci]

Hi all.

My work proceed, slowly, but constantly.
At the moment I have:
- an alpha-status model editor with auto-connection snap and basic editing: add, remove, load&save (only ldr)
- a connection editor tool (GUI, 3D), to edit connection file for parts where connection points can't be detected using primitives.

Programs still needs lot of work, mainly for user interface and interaction, but it is really simple to use and almost stable (for what I can see, but for a programmer his software is always stable, you know...). At least to create little to medium model.

Attached you can see the first model created with my LDraw editor.

I like to hear what you think about it.

[Roland Melkert]

Might be a bit late, but I wanted to respond to the original 'Do we need another LDraw building program?' question.

As the author of LDCad I also often wondered why even bother but in the end it's my hobby and it gives me the option to make something I personally like the best.

So, imho, you probably had a reason to start working on an editor in the first place that alone should be a good enough reason to do it.

Also not any single editor is ever going to satisfy every single user, so having a selection of editors can only be a good thing.

just my 2cts.

[Jakub Trznadel]

I love diversity. Every attempt to build something from scratch will introduce new ideas... even if it could be hard to match LDCad ( :-) ), it is always possible that ldcad will add new features inspired by another CAD.

At least it works for me: I check other viewers/animators to find out better ways of doing something.

I have tried 30056 model at my viewer (you can check it here). It seems to work perfectly. Good work

Regards,
Jakub

[Mario Pascucci]

Hi all.

After some hesitation and a lot of work, I'm pleased to announce the first public beta for:
JBrickBuilder
a LEGO builder in Java for LDraw part library.

Program is in beta and it is completed at 30-40%, so most functions are planned but absent in this release.

I use a connection database I built to allow "snapping" of parts when you move a brick near another. For some connection type program also align part with receiving part, so building winged or "snotted" model is not so difficult.

Connection database is in zip form and downloaded at first start. It is far from complete: it contains over 250 parts (decorated parts uses same connection of plain parts, so minifig torso is one part in connection database, but it is used for all 300 torso in library, so probably working parts are a lot more) and program is able to auto-detect connections for lots of parts (I checked 130 parts for now).

When connection does not work, you always fall back on "placing grid", a plane that use snap and orientation to place parts.

Program is on Sourceforge:
https://sourceforge.net/projects/jbrickbuilder/
with manual (englisg, PDF).

Mario

[Philippe Hurbain]

Seems to work pretty well, though I have not yet figured out how to move an existing part! (OK, I should read the manual... but it's a good evaluation of user interface to be able to do without... and I find no link to it?).

For some reason my standard brick bin is pretty empty (no scroll bar!), eg. 3005 1x1 is missing...??? Other categories seem OK.
Looks like connectivity is missing between a brick and a submodel (I kind of understand why...)

[Mario Pascucci]

Seems to work pretty well, though I have not yet figured out how to move an existing part! (OK, I should read the manual... but it's a good evaluation of user interface to be able to do without... and I find no link to it?).

Moving a placed brick is not implemented (yet).

Manual is here:
http://sourceforge.net/projects/jbrickbu...f/download
(SourceForge allow you to put all files under "Files" page, but offers link only for "executables"...

For some reason my standard brick bin is pretty empty (no scroll bar!), eg. 3005 1x1 is missing...??? Other categories seem OK.
Looks like connectivity is missing between a brick and a submodel (I kind of understand why...)

It works a bit different: it will fills when you use brick from "Add". It is as color toolbar: more brick you use, more will go in "last used".

Thank you for your feedback
Mario

[Philippe Hurbain]

Moving a placed brick is not implemented (yet).

A good reason After all it's v0.1...

(SourceForge allow you to put all files under "Files" page, but offers link only for "executables"...

Maybe you can add a link here?

It works a bit different: it will fills when you use brick from "Add". It is as color toolbar: more brick you use, more will go in "last used".

I meant when adding a brick for the first time, browsing the library. See attached screenshot (brick.jpg) showing all bricks available when I click on brick category. If I search for "brick" (second screenshot) things are no better, I get a few patterned 3005 but no plain one. The good old 2x4 is missing too. Both of them are nonetheless correctly displayed if I load a model containing them.

[Mario Pascucci]

I meant when adding a brick for the first time, browsing the library. See attached screenshot (brick.jpg) showing all bricks available when I click on brick category. If I search for "brick" (second screenshot) things are no better, I get a few patterned 3005 but no plain one. The good old 2x4 is missing too. Both of them are nonetheless correctly displayed if I load a model containing them.

Congratulations! You found a bug! (just kidding...)
Weird...
Do you use your installed library or you downloaded a fresh one via JBrickBuilder itself?

Anyway, to find a specific part by size, try to put in search text sizes (without "x"):
brick 1 1 (3005) (should be first result)
brick 2 4 (3001) (second result)
brick 2 2 (3003) (second result)

To find by design id try to append a "." or a "*":
3005.
3003*

Thanks for feedback

[Philippe Hurbain]

OK, clearly related with my library. I switched to complete.zip in preferences and restarted. Since nothing happened, I guessed the database needed to be updated, I deleted the db files, started again and this time, after db rebuilt I had all bricks. Switched back to my own library, missing bricks again...

[Jason Smith]

Hi all.

After some hesitation and a lot of work, I'm pleased to announce the first public beta for:
JBrickBuilder
a LEGO builder in Java for LDraw part library.

I like it, great work Mario!

I'm using it on Ubuntu 12.04LTS and the install went great. I modified the runme.sh file and deleted all the lines except the .jar and gave it the permissions to run as a pgm and that worked for me. I like how it simply downloaded everything it needed, worked out nice and smooth.

Maybe the option to use your own library before downloading the complete zip would save from an unneeded download and speed up the install some.

I like your instruction manual, it's thorough and written nicely.

I must be missing something though because I can't move a part once it is placed. I read through the manual but must have missed something. When I click on a part and attempt to drag it nothing happens.

Should JBrickBuilder have it's own thread or a title change now that it's released?

[Mario Pascucci]

I must be missing something though because I can't move a part once it is placed. I read through the manual but must have missed something. When I click on a part and attempt to drag it nothing happens.

Should JBrickBuilder have it's own thread or a title change now that it's released?

Hi Jason.
Moving a placed element is not implemented (yet).

Program is in early beta, so there is lot of space for improvements

I think that a dedicated thread is a good idea. This thread was to ask for opinions to be ignored -> just kidding

Thanks for your feedback
Mario

[Ben Supnik]

Hi Mario,

Is there a spec or white paper on how your connection format works? If so, could you please point me to it? If not, could you create a short write-up? (The XML you use looks pretty understandable, but I would like to know the whole schema.)

I am hoping to get the same info from MocBuilder...the MocBuilder connection data and code is slightly less comprehensible. :-)

cheers
ben

[Mario Pascucci]

Hi Ben.

A white paper/spec document for connections is planned, with release of a quick&dirty connection editor (it is what I used to generate connection database).

At the moment connection editor needs some work, I was more focused on model editor for release.

I think I can arrange a brief spec document with connection model and algorithm.

Mario

[Mario Pascucci]

Hi Ben.

I wrote a brief document on how my connection model works.
You can get here (PDF):
https://sourceforge.net/projects/jbrickb...nnections/

HTH
Mario

[Ben Supnik]

Thanks Mario! Having read the PDF, I have a few questions about edge cases:

1. Is it possible to specify -snapping-? Examples:
- A technic axle and axle hole requires that the rotation (around the axis of the axle) be a multiple of 90 degrees.
- The new* locking hinges require the angle multiplier between the two hinge parts to be 22.5 degrees.
2. Is it possible to specify a many-to-many connector relationship? Or is it expected that multiple connectors that are at the same location describe these interactions?

Example: given a hollow stud, it can connect with an anti-stud, but the center can also connect with _some_ types of bars (e.g. the light saber blade). That light saber blade can be attached to clips. The clips can attach to a plate with handles. But the plate with handles cannot be jammed into the hole in the top of the stud.

Thanks!
Ben


* That I call them new says something about my age. :-)

[Mario Pascucci]

Hi Ben.

1. Is it possible to specify -snapping-? Examples:
- A technic axle and axle hole requires that the rotation (around the axis of the axle) be a multiple of 90 degrees.
- The new* locking hinges require the angle multiplier between the two hinge parts to be 22.5 degrees.

In this first try, connection logic isn't that sophisticated. Giving axle example, we need to add some information to the connection to verify angle between axle "axis" and hole. We can assume that axlehole is oriented at the same angle of part where hole is, but there can be parts where axlehole is oriented in other direction. There are some parts where axlehole is "+" oriented and other where axlehole is "x" oriented, so we need to add "orientation" to the connection itself (to the axlehole and to the axle).
For locking hinge, I can add a step of 22.5 degree to the rotation step on popup menu. Anyway, it is up to user to check the correctness of part orientation in these examples.
Also, program doesn't use collision volumes at all, so cannot detect wrong part orientation (like an axle placed in "x" where axlehole is "+").

2. Is it possible to specify a many-to-many connector relationship? Or is it expected that multiple connectors that are at the same location describe these interactions?

To keep program and logic simple, I chose to place multiple connection type on the same coordinates. Using your example, the "open stud" has three connetion type, two coincident: a plain stud, a "clip" type for bar and a underside pin receiver (a "stud3.dat"), to allow connection of a brick 1x2 on a plate 1x2 with single stud open on top (jumper).

I chose to lower amount of mathematics and logic for every connection, because number of connections in a simple model it easily grows over thousands. A plain 2x8 plate has 39 connections, a 4x8 plate has 85 connections and so on...

On the other hand, I think that define too many conneciton type can be confusing.

There is space for lot of improvements, program needs lot of works.

Talking about age, I remember last set my parents bought before I entered in the "dark age", this:
http://www.bricklink.com/catalogItem.asp?S=810-3
It was forty years ago

[Ben Supnik]

Hi Mario,

Thanks for the detailed explanation. I've been researching connectivity for Bricksmith so I'm trying to understand what people are already doing and trying.

There are some parts where axlehole is "+" oriented and other where axlehole is "x" oriented, so we need to add "orientation" to the connection itself (to the axlehole and to the axle).

Right - I suppose that inherent in the connection type is the rule about alignment, e.g. which way the "+" sits in a default, untransformed connection.

To keep program and logic simple, I chose to place multiple connection type on the same coordinates. Using your example, the "open stud" has three connetion type, two coincident: a plain stud, a "clip" type for bar and a underside pin receiver (a "stud3.dat"), to allow connection of a brick 1x2 on a plate 1x2 with single stud open on top (jumper).

This is a really interesting approach to me, because it -greatly- simplifies the connection logic, in return for a moderate increase in the number of connections on a part. (With this system, the bar now has 3 connectors instead of 1, and the stud has two instead of 1.)

My original idea was many-to-many relationships, so a technic hole could match a pin or an axle or a friction pin. With your scheme, the technic hole now must be several types of connectors:
- Stud receiver
- Pin receiver
- Axle receiver
- Friction pin receiver (if friction isn't modeled)

The win here, I think, is that the _constraints_ of these different uses of the technic hole are different. So under your system:

- technic hole + axle = rotation + translation (2 DOF, defined by axis of axle)
- technic hole + pin = rotation (1 DOF, defined by axis of axle)
- technic hole + stud = locked (0 DOF, a rigid body)

My original design required knowing that various combinations of connectors had different constraints.

There is one 'annoyance', namely that -every- technic hole will then need a series of connectors. But I think the heavy use of primitives can take the sting out of this. A technic hole primitive could be marked with all needed connectors on the primitive level, or we could even develop new primitives, e.g. "connectors for standard technic hole" that puts down all technic hole connectors with a single sub-file.

I chose to lower amount of mathematics and logic for every connection, because number of connections in a simple model it easily grows over thousands. A plain 2x8 plate has 39 connections, a 4x8 plate has 85 connections and so on...

On the other hand, I think that define too many conneciton type can be confusing.

I've been assuming that the number of connectors is just going to get really really huge...put your model on a 48x48 base plate and you start with over 2000 connectors before you even add bricks. My airport model covers 171 baseplates, so even if a lot of them have studs missing for roads, there might be 40k studs without the bricks.

So programmers that want to handle large models are going to have to cope with huge numbers of connectors anyway, by careful caching and data structures that can be rapidly searched. In that context, more connectors (in a spatially localized way) is probably fine.

Similarly, the connection types could be potentially specified strictly as data from a smaller number of connection classes. E.g. a stud-antistud or friction pin + friction pin hole can all be of the category of 0-degree-of-freedom point connectors. We have 924 primitives (apparently based on a quick dir listing) in the library, so coping with a large, carefully managed data set is something the community is already doing.

cheers
Ben

[Mario Pascucci]

Hi Ben.

With your scheme, the technic hole now must be several types of connectors:
- Stud receiver
- Pin receiver
- Axle receiver
- Friction pin receiver (if friction isn't modeled)

Actually, I use an hybrid method:
- a Technic pinhole has two connection point (one per side) of type "PEGHOLE". This connector is directly coupled with a connector type "PIN" (there is a function called "opposite()" that gives the coupled connection type), but in program logic it accepts "STUD" and "AXLE" type connection if no direct coupling is available.
- Other connection with special handling are: AXLE (can connect with AXLEHOLE and PEGHOLE); STUD (can connect to R_STUD, a tube, or PEGHOLE); BAR (can connect with CLIP or AXLEHOLE). Of course, vice-versa is provided: PEGHOLE in STUD, AXLEHOLE in BAR and PEGHOLE in AXLE.

The win here, I think, is that the _constraints_ of these different uses of the technic hole are different.

In my analysis, DOF descends from family of connection: Vector, Rail or Point.
- Vector: 1 DOF, rotation on vector axis (stud can be connected to a pinhole in any angle around pinhole axis).
- Rail: 2 DOF, rotation on rail axis, translating along rail.
- Point: 2 (3?) DOF, rotating around x,y,z axis
Pinhole is type Rail for axle coupling and type Vector for pin and stud coupling.

Constraints rules are partially leaved to the user: not having collision volumes it is really hard to detect wrong connections.
I think LDD uses more and more sophisticated model. But I must take account of Java speed limits, and accept less complex models and methods.

So programmers that want to handle large models are going to have to cope with huge numbers of connectors anyway, by careful caching and data structures that can be rapidly searched. In that context, more connectors (in a spatially localized way) is probably fine.

In this phase I focused on create and test a logic that "works". No optimization is done for connection search, except store connections by type, so if you have a CLIP you have only to search on BAR type array.
I'm thinking on two optimization: spatial sorting (connection point ordered by X, Y and Z) and remove used (coupled) connection, but no code yet.
Some connection is lot more used than other:
- stud and stud receiver in bricks, plates and baseplate
- pinhole, axleholes, axle and pins in Technic models
so can be useful to heavily optimize only some connection types.

Anyway, if you want to take a look to source:
- in file "ConnectionType.java" in package it.romabrick.ldrawlib there is connection type listing
- in file "ConnectionPoint.java" in package it.romabrick.ldrawlib there is connection autodetecting from primitives
- in file "ConnectionHandler.java" in package it.romabrick.ldraw3d there is connection search and coupling logic

In few days I think I can release new version and the (really ugly but "it works™") connection editor.
At present I have
- 290 part connections files (not autodetected parts)
- 155 parts correctly autodetected (checked)



Ciao!
Mario

[Ben Supnik]

Actually, I use an hybrid method:
- a Technic pinhole has two connection point (one per side) of type "PEGHOLE". This connector is directly coupled with a connector type "PIN" (there is a function called "opposite()" that gives the coupled connection type), but in program logic it accepts "STUD" and "AXLE" type connection if no direct coupling is available.
- Other connection with special handling are: AXLE (can connect with AXLEHOLE and PEGHOLE); STUD (can connect to R_STUD, a tube, or PEGHOLE); BAR (can connect with CLIP or AXLEHOLE). Of course, vice-versa is provided: PEGHOLE in STUD, AXLEHOLE in BAR and PEGHOLE in AXLE.

I understand. One of my design goals for Bricksmith is to avoid having any knowledge of the -actual- connection types in the actual implementation; I only want to code their 'classes' (e.g. rail, vector, point). That way we won't need code mods and a new app to extend the connectivity data.

Constraints rules are partially leaved to the user: not having collision volumes it is really hard to detect wrong connections.
I think LDD uses more and more sophisticated model. But I must take account of Java speed limits, and accept less complex models and methods.

Right - from what I can tell, LDD has bounding boxes, connections, constraints, and some kind of solver that can try to figure out the affect on an entire model of 'pulling' on one of the hinges. The solver appears to simultaneously be very sophisticated and sometimes a bit stupid:
- If the model is complex, pulling on it can result in unusual motions, not what you'd expect from the physical model. I can't fault them; they probably don't have enough "physics" data to model the real model without a much more detailed set of annotations.
- Sometimes the solver gets stumped. The Ultra Agents HQ truck's hinges are a series of ball joints with friction; because the ball joints are all along the same axis, their three degrees of rotational freedom degenerate into a single hinge. The solver can't figure that out and decides the hinges are "stuck".

For what it's worth, even without bounding boxes, there are some useful modeling operations you can do only with constraints and connectivity, e.g. rotate a series of locked-together parts around a common hinge. One of my motivations for adding connectivity to Bricksmith is that it's really hard in Bricksmith to model shapes that work at angles off of a 90 degree grid.

So for example, if a radar dish is tilted 37 degrees by a 1x2 hinge, I want to be able to build the part "upright" and then simply pick the hinge and tip the whole thing over; with connectivity and constraints Bricksmith can figure out who rotates (all of the 0-DOF connections above the hinge form a rigid body) and how to rotate (around the hinge axis). Right now i have to make the selection by hand and enter the rotation numerically...very slow.

This 'constraints for editing' can be done even without bounding boxes and collision; in such a system i'm on my honor to not over-rotate the hinge past its natural limit. But I'm happy to do that and have the app take over the tedious data of selecting complete rigid bodies and finding out what they rotate around.

I'm thinking on two optimization: spatial sorting (connection point ordered by X, Y and Z) and remove used (coupled) connection, but no code yet.

For spatial sorting, I suggest my favorite pet spatial index: the R-Tree. :-)
http://en.wikipedia.org/wiki/R-tree
I use it in Bricksmith to index the vertices of a part before smoothing; this lets me find common edges very rapidly. It works in 3-d, it's good for point hit tests, nearest-entity-within-X queries, and (most importantly) finding all entities within a range.

cheers
Ben

[Mario Pascucci]

Hi Ben.

I understand. One of my design goals for Bricksmith is to avoid having any knowledge of the -actual- connection types in the actual implementation; I only want to code their 'classes' (e.g. rail, vector, point). That way we won't need code mods and a new app to extend the connectivity data.

This is a really good point. I'm tempted to rewrite the connection logic this way:
- a main configuration file that define connection types, main type and coupling (vector, rail or point)
- files for every part where connection aren't autodetected
- no special handling, but only one-to-one coupling
This allows to add new connection pairs (connector and receiver) only adding a row in main file.

For spatial sorting, I suggest my favorite pet spatial index: the R-Tree. :-)
http://en.wikipedia.org/wiki/R-tree

I didn't know. Awesome, it will be really useful, thank you!

Ciao!
Mario

[Christopher Hiller]

Hi,

First, let me apologize by posting into an old thread, but I couldn't find a more appropriate one.

I was searching around looking to see if I could run LDCad on my Mac. The LDCad site directed me to the forums, so here I am.

I might be able to get LDCad running on my Mac, with some fiddling. Running it natively would be a stretch, but running under XQuartz seems more likely.

But I can't, because I cannot access the source code.

There may to be a misconception or misunderstanding about open source software in the LDraw community. LDraw as a standard is open, and that's great, but it seems many of the projects are not, and that makes me sad.

I'm hoping to argue for licensing of more projects under open source here; I apologize if I'm about to offend anyone.



Making a project open source does not mean "setting it free". It does not mean anybody can come along and change it. It does not mean you lose control over your project. It's still your project, and you still own it. It has your name on the copyright.

All it really means is that others can contribute to your project. For example, would a Mac build of LDCad be appreciated? If not certainly by the author of LDCad (I'm assuming this is you), but certainly others in the community.

Why a binary for Mac has not been released, I do not know. If it's simply because the author doesn't have the time, resources, or test machine to get a Mac version running--please know that others _do_ have the time and resources, and they are happy to contribute.

I write a ton of code. It's all open source. I still own it, and nobody can screw with my projects without my say-so. That doesn't mean someone can't copy it and make it better if I start slacking off, though. Generally, this doesn't happen without very good reason. 95 out of 100 times, code someone else writes to improve your project will be presented to you, and you can choose to include it--or not.

If more authors opened their tools up, I think we'd see an influx of contributions. Many developers would rally around the best projects and make them even better.

Regarding LDCad specifically, I'm reading that the author is happy to release the source under an open-source license if he's not able to work on it any longer, for whatever reason. But there's no need to wait. What will happen is the project will be released into the wild without a proper maintainer, and there will be a vacuum where there were once ideas and visions. If you release it now, while you still have interest, it will help you ensure another maintainer--or team!--will take the reins if you no longer have the time or desire. People aren't going to crawl over each other to learn a completely unfamiliar codebase of a dead project!

So no, you won't have to relinquish control, but you will need to: collaborate, be responsive, and listen to ideas. If someone calls your code into question and you disagree, you must be prepared to defend your decision. If you've done code reviews, then you know there's a lot to learn from others. Even if the codebase is a complete mess, someone will help clean it up, because they like the project.

I don't know the reasons for not releasing LDCad under an OSS license. But if I'm lucky, I've addressed a concern or two. I'd love to contribute to a project like LDCad if I could. And there are many others like me...


Chris

[Roland Melkert]

Hi,

First, let me apologize by posting into an old thread, but I couldn't find a more appropriate one.

Hello and welcome to you too. There is no harm in starting a new one. Maybe an admin can split this one off?

I was searching around looking to see if I could run LDCad on my Mac. The LDCad site directed me to the forums, so here I am.

I might be able to get LDCad running on my Mac, with some fiddling. Running it natively would be a stretch, but running under XQuartz seems more likely.

But I can't, because I cannot access the source code.

I'm the author of LDCad and I've been asked about making it open source a number of times. In fact I'm starting to reconsider it as a result. But my greatest (silly) concerns are still in place, namely:

1: The source is less then clean as it is a write as I go project. (It's like building a house and start attaching extensions for which the foundation is not always appropriate.)

2: All comments and reminders etc are in dutch. The more obvious (to me) portions of the code don't have comments at all.

3: I'm very picky about the internals so from time to time I like to rewrite large portions of it, something which would be a nightmare when working with multiple people I'm guessing.

4: Some of the .cpp files are huge (e.g. the LDraw file handling classes file is over 11.000 lines alone. This is excluding the individual ldraw line handling which in total adds another 10.000 lines or so). I guess this is the result of me having a Delphi background

As a result of all this I'm not comfortable setting it 'free', and if I would there is still the issue of where as I'm not really a fan of sourceforge (anymore) and as I still prefer svn github isn't my first choice ether.

All it really means is that others can contribute to your project. For example, would a Mac build of LDCad be appreciated? If not certainly by the author of LDCad (I'm assuming this is you), but certainly others in the community.

Why a binary for Mac has not been released, I do not know. If it's simply because the author doesn't have the time, resources, or test machine to get a Mac version running--please know that others _do_ have the time and resources, and they are happy to contribute.

The main reason there is currently no mac version is indeed lack of a mac myself. I tried cross compiling several times but couldn't get it to work so far. I would also settle for a VM but Apple's licensing policies make that impossible.

A while back I considered getting a macbook as I'm not a big fan of windows 10 and could use a new laptop in the near future. If so a mac version will follow soon after

As for the source dependencies LDCad should be portable to anything supporting wxWidgets and has full OpenGL (not just ES) support. The only additional things needed are some low level calls I'm doing like:

Code:

#ifdef LDC_MSWIN
const bool TString::fileExistsCore(const lowLevelFileNameStr &fileName) {
  struct _stat statBuf;
  return _wstat(fileName.c_str(), &statBuf)==0;
};
#endif

#ifdef LDC_LINUX
const bool TString::fileExistsCore(const lowLevelFileNameStr &fileName) {
  struct stat statBuf;
  return stat(fileName.c_str(), &statBuf)==0;
};
#endif



#ifdef LDC_MSWIN
const bool TString::fileDeleteCore(const lowLevelFileNameStr &fileName) {
  return _wremove(fileName.c_str())==0;
};
#endif

#ifdef LDC_LINUX
const bool TString::fileDeleteCore(const lowLevelFileNameStr &fileName) {
  return remove(fileName.c_str())==0;
};
#endif

[Ben Supnik]

Hi Christopher,

BrickSmith is a Mac-native LDraw client:

http://bricksmith.sourceforge.net/

It's open source (MIT/X11) license. Allen Smith is the founder/main developer; I got him to add me as a SF contributor and worked on the GL code a bit. I haven't heard from Allen in a while, but maybe what I'm about to say will rouse him. :-)

So...
1. you can contribute to BrickSmith...Allen, as project founder, has some specific ideas for what he does and doesn't want in the project. If you find that what you want to do is not the same as what he wants, I suppose you could also...
2. fork it and go to town. Not quite as good as keeping all oars pulling in the same direction, but you might want to go in a legitimately different direction, and SF says the code is MIT/X11, so it's yours.
3. create your own Mac editor, leveraging bits of BrickSmith (or any other open code you can find) to solve problems.

I believe that one of the Java editors is already forked off of BrickSmith - when I went to browse the code there was clearly a 'port' of the ObjC from BrickSmith into Java.

Anyway, ping me if you want more info (bsupnik at gmail) - I don't think we have a functioning dev list right now - at most we've had three developers at once, so it was just email. I'm also one of the guys who was kicking around connectivity ideas...I'm happy to share my notes or start a new thread. (I begged off the standards board due to a lack of time - with the second child I've been stretched pretty thin.)

Cheers
Ben

[Ben Supnik]

Hi Roland,

Those reasons not to open source seemed like they didn't have to be deal-breakers. Your reasons sound to me a little bit like "we can't have guests over because the house is a mess." (My wife tells me that in real life that _is_ a thing. :-) :-)

But the thing about open source is: you put code out there and developers get to decide on their own whether the code is okay for them to work on - maybe they even _help_ you address some of the issues you're not happy with.

I think you have to answer two questions for yourself:
1. Could you codify what behavior and code style would be acceptable to you as contributions submitted by other users. (If so, you make the rules and if no one shows up, no harm done.)
2. Would you be unhappy if someone forked your code and made a similar program, taking it in a direction that you don't approve of. (If not, open source might not be a good choice, as you can't really stop this kind of thing.)

In the case of BrickSmith, Allen put down a rule: no C++! Since C++ is my primary development language, I had to ask the question: what do I care about more - building on top of his already very complete, enjoyable to use, functional program, or using my preferred language. I concluded that while not -my- preferred choice, working without C++* was still better than writing an editor from scratch (by a lot), so I worked on the project on his terms.

Cheers
Ben

* As a side note, I now think every C++ nerd should spend a few nights actually coding in pure C, just as a gentle reminder that the world won't end if you don't have templates. :-)

[Christopher Hiller]

Thanks for the info Ben!

It's been a few years since I've done Java, but I prefer it to C++.

Do you know if there's a Python editor anyone has written? Maybe using PyQt or something? I'm more comfortable in Python that either of those two.

I'd like to actually attempt a web-based CAD program (JS is my strongest language)... someday. I'm not sure what kind of graphics technologies I'd have to work with, because I'm generally inexperienced in that space.

My main issue with Bricksmith was having to change the perspective to move. I found this too difficult, and am using LeoCAD now instead.

Unfortunately, I'm much too busy with my own projects to devote time for actual code to anything... my contributions to any project would be of the "fix the build" or "reformat the code" variety.

[Roland Melkert]

I think you have to answer two questions for yourself:
1. Could you codify what behavior and code style would be acceptable to you as contributions submitted by other users. (If so, you make the rules and if no one shows up, no harm done.)
2. Would you be unhappy if someone forked your code and made a similar program, taking it in a direction that you don't approve of. (If not, open source might not be a good choice, as you can't really stop this kind of thing.)

Point 2 might actually be my greatest concern when I think about it. On the other hand my best 'pro' point currently is giving people the opportunity to compile themselves in order to support more platforms. Another thing holding me back is picking a license etc I just want to code

As a side note, I now think every C++ nerd should spend a few nights actually coding in pure C, just as a gentle reminder that the world won't end if you don't have templates. :-)

LDCad has some pure C, it is needed in order to use lua, but I couldn't help class wrap it asap Personally I limit template usage when using C++ anyway.

[Ben Supnik]

Hi Christopher,

I don't know about the state of other languages - there are a pile of things for Java and the web now - I've lost track.

My main issue with Bricksmith was having to change the perspective to move. I found this too difficult, and am using LeoCAD now instead.

I'm not sure what you mean by this. For drag & drop, movement is sensitive to perspective, but the quickest way (I find) to move pieces is keyboard nudging: arrows, with the shift key moving at 10x speed. For any given perspective, all three axes are available (option up/down gets you the "depth" axis for current perspective).

I mostly model modular buildings, usually with significantly higher brick count than I can afford in real life. One thing I like about BrickSmith is that I can put down a -lot- of bricks efficiently by a mix of:
- Duplicate and move existing bricks.
- Fully keyboard based location and rotation of bricks.
- Useful grids to work with.

BrickSmith's biggest weakness might be that it has no snapping/connectivity, so "off-grid" work is time consuming, nearing the point of being impractical. But if you want to build orthogonally it's very efficient for power users.

cheers
Ben

[Ben Supnik]

Point 2 might actually be my greatest concern when I think about it. On the other hand my best 'pro' point currently is giving people the opportunity to compile themselves in order to support more platforms. Another thing holding me back is picking a license etc I just want to code

That's tricky - it's not really "open" if you can't fork it. If you can live with forkability I'd suggest either MIT/X11 or GPL - that's the two big flavors of open license and everyone understands them. When you go find some more specific and tweaky license, it might fit your desires 10% better than one of the big licenses, but it's also more likely that other contributors aren't going to understand the fine print.

cheers
Ben