Hi all.
My apologies in advance for this long message.
As you know, I'm working on a LDraw model editor. After your really useful replies to my concerns about yet another editor, I re-think my program to do a "multiple-personality" tool: model, part and connection editor. At first view it isn't a great problem, program is modular and uses a lot of high level libraries I coded to parse and efficiently render LDraw parts. So I started re-working program in this new "flavor".
So, in the purpose to contribute to LDraw community, here follows a list of things/features on I'm working (please take as a mere proposal):
Connections
I try to extract connection points from part itself, using primitives as marker to detect a connection point. I.e. if I read a part with "stud.dat" primitive, I add to part connection list a "stud-type" connection, oriented and placed using primitive matrix and placement. This is done for various stud and bottom tube type, technic axle, axlehole, pin, peghole, and program is able not only to detect it automatically, but it uses connection points to detect and "snap" new placing part to nearest "opposite" connection point.
Connection points are oriented, so you cannot connect a part in wrong way.
A drawback is that lots of parts does not use primitives that can be uniquely associated with a connection point. An example is a 1x1 brick (or plate or tile): it uses stud.dat for top stud (and program correctly detect "STUD" connection), but "box5.dat" primitive cannot be certainly detected as a connection site, because it is used in so many parts as a "main body".
So I started thinking a strategy for describe connections for parts where cannot be detected "safely". At the moment my strategy is:
- I look in a "connection database": if part isn't in DB, I call a procedure that "auto-detect" connections.
- if part is in DB, I read all connection from it.
Benefits are:
- if parts in library use official primitives, it is highly probable that new parts does not need a special connection description, because primitives "marks" connection points;
- does not needs any modification in part library
Drawbacks are:
- we need to manually edit connection points for parts where can't be auto-detected
- we need a new format for connection description.
At the moment, I chose XML for connection description (it is reasonably easy to read and write in many programming languages and has a structure that allows a quick check for "correctness", you can use something like "lint", an utility that verifies syntax). Strategy is: connections database is a folder where is one file for part, first time I load a part from library I search for file in this folder, if a file exists, I read it and put in a cache, else I call the "auto-detect connection" procedure and cache results.
An example of XML file for connection description is attached.
It is a minifig hand, that has three connection type: a "STUD" connection, for placing bricks or plate on top; a "CLIP" connection, to "grab" bar, utensil, handles; finally a "BAR" connection in "wrist", to attach hand on an arm.
File extension can be (to say...) CXML (for "connection markup language") or CML to comply with 3 char extension limit, I renamed in "txt" to allow attachment, but in fact it is a txt file.
Program
It is in Java, and, despite the "urban legends" that follows this language, it is "damn fast"™
It is (and will be) open source and free.
At the moment program is in "early alpha":
- it can read a model (DAT, LDR, MPD, L3B and so on) using a library I coded for read and parse LDraw files;
- it detect connection points from primitives
- it allows placing of new parts using a "snap" very similar to LEGO Digital Designer, with some minor differences
- does not checks for part collision (I have no idea how to do without a lot of heavy and complex geometric computation)
- it saves a flat LDR of edited model (no submodel, no MPD, but it is planned)
I'm working to merge my connection editor in model editor (it merely needs to add toolbars with specific functions and add some logic to program to handle/display/edit connections), and to add tools for editing part (place lines, triangle, quads, primitives, ...).
It is a lot of work, but I am confident that I can manage it, without hurry.
If you wish, I can post some screenshot to show program aspect and progress.
Meanwhile, I can help to detect and correct some library errors, you have only to ask
HTH.
Mario
My apologies in advance for this long message.
As you know, I'm working on a LDraw model editor. After your really useful replies to my concerns about yet another editor, I re-think my program to do a "multiple-personality" tool: model, part and connection editor. At first view it isn't a great problem, program is modular and uses a lot of high level libraries I coded to parse and efficiently render LDraw parts. So I started re-working program in this new "flavor".
So, in the purpose to contribute to LDraw community, here follows a list of things/features on I'm working (please take as a mere proposal):
Connections
I try to extract connection points from part itself, using primitives as marker to detect a connection point. I.e. if I read a part with "stud.dat" primitive, I add to part connection list a "stud-type" connection, oriented and placed using primitive matrix and placement. This is done for various stud and bottom tube type, technic axle, axlehole, pin, peghole, and program is able not only to detect it automatically, but it uses connection points to detect and "snap" new placing part to nearest "opposite" connection point.
Connection points are oriented, so you cannot connect a part in wrong way.
A drawback is that lots of parts does not use primitives that can be uniquely associated with a connection point. An example is a 1x1 brick (or plate or tile): it uses stud.dat for top stud (and program correctly detect "STUD" connection), but "box5.dat" primitive cannot be certainly detected as a connection site, because it is used in so many parts as a "main body".
So I started thinking a strategy for describe connections for parts where cannot be detected "safely". At the moment my strategy is:
- I look in a "connection database": if part isn't in DB, I call a procedure that "auto-detect" connections.
- if part is in DB, I read all connection from it.
Benefits are:
- if parts in library use official primitives, it is highly probable that new parts does not need a special connection description, because primitives "marks" connection points;
- does not needs any modification in part library
Drawbacks are:
- we need to manually edit connection points for parts where can't be auto-detected
- we need a new format for connection description.
At the moment, I chose XML for connection description (it is reasonably easy to read and write in many programming languages and has a structure that allows a quick check for "correctness", you can use something like "lint", an utility that verifies syntax). Strategy is: connections database is a folder where is one file for part, first time I load a part from library I search for file in this folder, if a file exists, I read it and put in a cache, else I call the "auto-detect connection" procedure and cache results.
An example of XML file for connection description is attached.
It is a minifig hand, that has three connection type: a "STUD" connection, for placing bricks or plate on top; a "CLIP" connection, to "grab" bar, utensil, handles; finally a "BAR" connection in "wrist", to attach hand on an arm.
File extension can be (to say...) CXML (for "connection markup language") or CML to comply with 3 char extension limit, I renamed in "txt" to allow attachment, but in fact it is a txt file.
Program
It is in Java, and, despite the "urban legends" that follows this language, it is "damn fast"™
It is (and will be) open source and free.
At the moment program is in "early alpha":
- it can read a model (DAT, LDR, MPD, L3B and so on) using a library I coded for read and parse LDraw files;
- it detect connection points from primitives
- it allows placing of new parts using a "snap" very similar to LEGO Digital Designer, with some minor differences
- does not checks for part collision (I have no idea how to do without a lot of heavy and complex geometric computation)
- it saves a flat LDR of edited model (no submodel, no MPD, but it is planned)
I'm working to merge my connection editor in model editor (it merely needs to add toolbars with specific functions and add some logic to program to handle/display/edit connections), and to add tools for editing part (place lines, triangle, quads, primitives, ...).
It is a lot of work, but I am confident that I can manage it, without hurry.
If you wish, I can post some screenshot to show program aspect and progress.
Meanwhile, I can help to detect and correct some library errors, you have only to ask
HTH.
Mario