[Software] JBrickBuilder - easy and Open Source LDraw builder in Java

[Mario Pascucci]

NB: starting from october, 2015, this software become unmaintained.

It will not receive updates nor bugfixes.

My time is limited and I lost any interest in this project.

Sorry.

------------------------

Hi all.

I'm pleased to announce:

JBrickBuilder

a LEGO builder in Java for LDraw part library.

JBrickBuilder at work.

Some feature:

• simple building, like LEGO® Digital Designer™
  
• Useful for small-to-medium models (up to 2000 parts with old low-profile PC, over 3500 parts with newer PC)
  
• In Java, fast and cross platform
  
• Requires OpenGL, but can use entry level video card.
  
• Use connection "snap" for easy building
  
• Uses standard LDraw library
  
• Update checks and notifications for program and connection database
  
• Can load DAT, LDR, MPD and some other LDraw-compliant file formats (LCD, L3B, ...)
  
• Can save in LDR and export to MPD, including all custom blocks and unofficial parts
  
• Support for flexible parts (experimental)
  
• Support for building steps and player (experimental)
  

Program is in beta, some functions are planned.

Current release: 0.4.1b (2015-06-12)

Program is on Sourceforge:

- Program

- Manual (english, PDF)

- Other information (connection model, development docs)

Short video with flexible part editing demo:

Please read the manual, program is easy to use, but some functions requires a bit of practice.

Thank you.

Mario

Edited December 7, 2015 by Mario Pascucci

[Calabar]

It looks great.

My wishlist for feature request is:

• easy way to get and add unofficial parts database.
  
• a better graphics, the image above seems a bit aliased.
  
• a screenshot mode, to create a single hight quality frame in order to get a good-looking screenshot.
  
• direct export for Bricklink wanted lists.
  
• Maybe an higher limit for parts, in order to recreate all the official sets? Ok, maybe this one could go beyond the purposes of the software.

[Mario Pascucci]

Hi Calabar,

thanks for your feedback.

• easy way to get and add unofficial parts database.
  

Planned. At the moment you can add any DAT/LDR/whatever LDraw file as a custom block, but its file must be in model folder. When you export your model as MPD, program will includes any external custom block/submodel/part in it.

• a better graphics, the image above seems a bit aliased.
  

My goal is to keep program hardware requirements very low. This release works fine in a Asus eeePC 900 (a netbook produced in 2008) booted with a Fedora Live. Antialiasing is a bit hungry on graphic hardware power. I can add it as an options.

• a screenshot mode, to create a single hight quality frame in order to get a good-looking screenshot.
  

See above reply. I can see if I can arrange a slightly better rendering only for a screenshot.

• direct export for Bricklink wanted lists.
  

Why duplicate the function of awesome BrickUtils? Just kidding. Exporting from LDraw to Bricklink requires half of the code of BrickUtils merged with JBrickBuilder. I think not worth it.

• Maybe an higher limit for parts, in order to recreate all the official sets? Ok, maybe this one could go beyond the purposes of the software.
  

Limit is the memory and the speed of your computer. Java is a bit memory-hungry, and to keep performance and usability I must use lots of optimization and caching. With default JVM configuration, over 2000 parts you can hit an "Out of memory" on a 2Gb Linux/OSX computer. Windows computers requires more system RAM: with default JVM, in a 2Gb PC you can hit an "out of memory" with less than 1500 parts.

Using low-details mode in JBrickBuilder can help to lower RAM load, but not expect miracles.

Planned/next items (in sparse order):

• undo
  
• autosave
  
• flexible parts (I'm tinkering with some ideas...)
  
• better connection search algorithm for bigger models (and slow computers )
  
• ...
  

Mario

Edited February 13, 2015 by Mario Pascucci

[Calabar]

Hi Mario, yesterday I spent some minutes with the software, and I noticed:

• I've difficulties to rotate the scene. I mean, the scene don't rotate as I aspect it would do. Maybe I'm too much accustomed with LDD, or maybe these is something not intuitive in the rotation.
  
• It seems it is not possible to place an object where you want in relation to the main grid. For example, if I place the first object, I was able to place it at mid-height of the grill, I've not found the way to place it above or beneath the grid yx plane.
  Is there a way to fine move a brick using arrow keys with a chosen step? For example I could want to move a brick to the left with half brick step.
  
• Is there a way to move placed objects without clicking every time on the "move brick" button on the toolbar? It is very very uncomfortable.
  
• I tried to attach a tail to the small dragon figure (the one from the dragon knight series), and I didn't find a way to achieve that. It seems that there is no automatic snap, and I can't find a way to place it manually.
  
• I detached a toolbar from the main windows, and then I can't attach it again. A good placement of the toolbars can improve the user experience. Restart the model seems to fix the problem, but what if I would maintain the toolbar detached?
  PS: in the bottom-left I've now a large green "ready" icon that waste a lot of space (a whole thick line). Is there a way to hide it or place it where it don't bother?
  
• When I have to choose a part, I miss a list of thumbnails. A list of names often force me to select one by one many bricks (after a search) to find the one I want.
  

About what I asked above

• Thanks for planning the option for a better graphics. I think that if graphic setting are too low, it makes difficult to understand the scene and then build the models. It is not only a matter of aliasing, I think: LDD appears to have a better graphics even with low graphic settings and no antialiasing.
  PS: about performance, do you think that an executable instead than a jar file would help? Something like you did with LDDMC.
  
• About the screenshot mode, the idea is that if during the standard workflow you need a certain number of fps to maintain the scene fluid and the software usable, in the screenshot mode it is not important even if you spend even few seconds to generate the frame (a time that could be hundred times greater). The software could temporarily and internally increase the scene resolution and then downscale it, apply shadows, etc... Clearly the memory load could be a limit anyway.
  
• About exporting wanted lists... eheh yes, that's why I thought that integrate the function could be very easy, you already have written it! I love the function in Brickutiils (I asked for that indeed!), but having it integrated would be much more comfortable, expecially for unesperienced user.
  
• I understand the problem. I hope that in a good performance machine it will be possible to reach the 5-6000 parts limit in order to build any official set. Maybe the suggestion above about generating the exe file could help?
  

Thanks

Edited February 13, 2015 by Calabar

[Mario Pascucci]

• I've difficulties to rotate the scene. I mean, the scene don't rotate as I aspect it would do. Maybe I'm too much accustomed with LDD, or maybe these is something not intuitive in the rotation.
  

Rotation is a bit different from LDD where horizontal dragging rotates only on vertical axis. In JBB dragging rotates the "world" in the exact direction of dragging from current position. I made this different from LDD because of unexpected behavior when you are looking a model from top or bottom.

• It seems it is not possible to place an object where you want in relation to the main grid. For example, if I place the first object, I was able to place it at mid-height of the grill, I've not found the way to place it above or beneath the grid yx plane.
  Is there a way to fine move a brick using arrow keys with a chosen step? For example I could want to move a brick to the left with half brick step.
  

Main grid is where part geometric "origin" is placed. You move grid using buttons in left toolbar to set grid in position, then place your part. You can move grid even if you have a part moving under your cursor.

• Is there a way to move placed objects without clicking every time on the "move brick" button on the toolbar? It is very very uncomfortable.
  

Not at the moment.

• I tried to attach a tail to the small dragon figure (the one from the dragon knight series), and I didn't find a way to achieve that. It seems that there is no automatic snap, and I can't find a way to place it manually.
  

Automatic snap is based on connection database. Connection database lists over 500 part molding, out of over 4000 part in library. I'm adding parts to database every day, but it is a loooooooong work. Reply to this message with a list of needed parts and I can arrange an update for connection database.

• I detached a toolbar from the main windows, and then I can't attach it again. A good placement of the toolbars can improve the user experience. Restart the model seems to fix the problem, but what if I would maintain the toolbar detached?
  PS: in the bottom-left I've now a large green "ready" icon that waste a lot of space (a whole thick line). Is there a way to hide it or place it where it don't bother?
  

OK. User interface is a low priority task, I'm working on program core functions, like better connection algorithm and connection database. But I'll see what can I do.

• When I have to choose a part, I miss a list of thumbnails. A list of names often force me to select one by one many bricks (after a search) to find the one I want.
  

I know. I'm searching an enhancement for this, but at the moment I haven't found anything I like.

• Thanks for planning the option for a better graphics. I think that if graphic setting are too low, it makes difficult to understand the scene and then build the models. It is not only a matter of aliasing, I think: LDD appears to have a better graphics even with low graphic settings and no antialiasing.
  PS: about performance, do you think that an executable instead than a jar file would help? Something like you did with LDDMC.
  

LDD does not have to deal with Java and bytecode, so developers can use full power of C/C++.

LDDMC isn't my work. And Java converted to an executable is not Java. If you mean "like LDDMC", it uses an utility (like this or this) to create a complete installer (including Java virtual machine and libraries), but "inside" is pure Java, so no differences from a JAR, from performance point of view.

Java performance is an heavily discussed question, but there are limits you can't ignore.

• About the screenshot mode, the idea is that if during the standard workflow you need a certain number od fps to maintain the scene fluid and the software usable, in the screenshot mode it is not important even if you spend even few seconds to generate the frame (a time that could be hundred times greater). The software could temporarily and internally increase the scene resolution and then downscale it, apply shadows, etc... Clearly the memory load could be a limit anyway.
  

There are some tricks that most LDraw CAD/viewer uses:

• primitive substitution: when a part uses some LDraw primitives, program will uses a GLU-generated quadric, that appears a lot better on rendering. LDraw cylinder, cones, spheres are based on a 16-faces polygons, that are a deal with space and speed.
  
• better lighting and material reflection: using glMaterial and some lighting function you can render material appearance (shininess, reflection, ...).
  

These functions requires specific GL-system calls for every single part detail when applies. A GL-system call is really time consuming, so I must limit system calls. To give a figure: a 32x32 baseplate is rendered in BrickUtils using GL-system calls for every element (face): a single baseplate renders in two-three seconds. In JBB a baseplate requires only few calls and renders in 14msec. This is a result of a really heavy optimization of geometric structures and rendering engine. Using glMaterials will break this architecture and lead to a significant loss of speed.

There are some other strategy for better rendering, but needs higher hardware requirements and special software development (GL shading language and shaders) that is out of my skills, at the moment.

• About exporting wanted lists... eheh yes, that's why I thought that integrate the function could be very easy, you already have written it! I love the function in Brickutiils (I asked for that indeed!), but having it integrated would be much more comfortable, expecially for unesperienced user.
  

I have two options to include wanted list export:

• include only really basic function (no list editing, no "missing part" checking, no set/moc/lot list, ...): requires to create a fork of BrickUtils, with its own classes and libraries: over 4.000 rows of code
  
• include all function needed only to see and edit generated part list: requires some specific classes and checking for compatibility of BrickUtils and JBrickBuilder classes: 7.000 rows of code.
  

It is a lot of work, with duplication of code and classes. Nope, it is really over my time and capability... and it isn't my work, it's an hobby!

• I understand the problem. I hope that in a good performance machine it will be possible to reach the 5-6000 parts limit in order to build any official set. Mayve the suggestion above about generating the exe file could help?
  

Main problem is memory available for Java virtual machine. I was too conservative with number of parts: I loaded an ldr model of 10221 (super star destroyer, 3152 parts) and 21010 (robie house, 2276 parts) and program still works, but it is a bit slow (only 10-15 fps), with Java heap size grows at ~800Mb, used ~400Mb.

Keep in mind that program is in beta, development is at 40-50%.

Mario

[Superkalle]

Great project Mario.

I especially like that you've started to look at connectivity in the way you have. IMHO it's one of the most lacking features of the Ldraw platform, at least to attract a wider audience of users.

EDIT: There was an innitative a few years back, but I'm not sure what happened to it: http://www.ldraw.org...02-06-lcd.shtml

[Calabar]

I'll try to reply to the main points:

Rotation is a bit different from LDD [...]

That means there is nothing to do about that?

Maybe it will become easier with the use, but at the moment it is a pain to rotate the scene!

Reply to this message with a list of needed parts and I can arrange an update for connection database.

At the moment I've tried with few parts. So the present list is:

- 6028 Animal Dragon Tail

- 75174 Animal Dragon Body

The two parts don't connect each other.

I can imagine that similar connections don't work too (crocodiles, for example).

EDIT: it seems that mursten brick 2x1 u8001a bottom part can't connect to studs.

PS: it would be useful for reporting if I can copy brick's data from the search list.

LDDMC isn't my work. [...] If you mean "like LDDMC", it uses an utility to create a complete installer (including Java virtual machine and libraries), but "inside" is pure Java, so no differences from a JAR, from performance point of view.

Oh damn it seems I made a bit of a mess!

Anyway I mean to compile the java code and obtain an executable instead than the bytecode. If I'm not wrong, this should be a real executable, not something executed in a JVM. Years ago, in a java project I made, I remember I was able to create simple executables choosing the proper option in the compiler.

Obviously the result would not be cross-platform (but for that there is the jar file!).

This is a result of a really heavy optimization of geometric structures and rendering engine. Using glMaterials will break this architecture and lead to a significant loss of speed.

You mean that all the software would become slow if you add the code for this? Or would be slow only during the use of GL-system calls?

I mean, if I've to render a scene for a simple screenshot the speed is not really important, I can wait a bunch of seconds if the result is a good quality screenshot. Maybe that virtually increase resolution and downscale would be enough, maybe with some shadow.

I have two options to include wanted list export: [...]

A very basic function would be enough (with some options, for example choose if you want new or used parts).

What people could want is simply to create something and the buy the pieces. Editing could be done elsewhere.

Another chance could be an advanced export that requires brickutils in the same folder: the software automatically pass the data to brickutils and open it, so that you can access to more export feature from there. Maybe this could be achieved with few modifications to both JBrickBuilder and Brickutils.

Ah, another thing I miss in the previous post.

When I move an already placed brick, the brick is turned upside down. That's uncomfortable because I've to rotate properly the brick from the scratch, instead than simply move it.

Edited February 13, 2015 by Calabar

[legolijntje]

Great project Mario.

I especially like that you've started to look at connectivity in the way you have. IMHO it's one of the most lacking features of the Ldraw platform, at least to attract a wider audience of users.

EDIT: There was an innitative a few years back, but I'm not sure what happened to it: http://www.ldraw.org...02-06-lcd.shtml

Nothing really happened with that (as far as I know). At the moment, programmers have to develop their own way of adding connectivity into the editor.

Last days/weeks, there's a discussion going on in the LDraw forums (so, not here) about connectivity and if and how to include connection data into the LDraw library.

So, there may finally be some improvement in the future in that area. At least, I hope so

[Mario Pascucci]

Hi Calabar.

Your question in red.

That means there is nothing to do about that?

Maybe it will become easier with the use, but at the moment it is a pain to rotate the scene!

No, I didn't say that. It is question of practice, and there are buttons to reset view to help if you are lost. But if it is so difficult to rotate view, I can manage to add an option to do LDD-style rotation.

At the moment I've tried with few parts. So the present list is:

- 6028 Animal Dragon Tail

- 75174 Animal Dragon Body

The two parts don't connect each other.

I can imagine that similar connections don't work too (crocodiles, for example).

EDIT: it seems that mursten brick 2x1 u8001a bottom part can't connect to studs.

Database connection contains 500 parts, but there are over 5.000 parts in library. Autodetect works only on 10% of parts, so it is normal that there are many parts that don't connects, or connects wrong.

PS: it would be useful for reporting if I can copy brick's data from the search list.

Try a "ctrl-c" when a row is selected in part selection dialog. It should copy the whole text line.

Anyway I mean to compile the java code and obtain an executable instead than the bytecode.

There aren't free Java bytecode to native code, and results aren't so good. Java contains its own JIT compiler (Just in Time).

You mean that all the software would become slow if you add the code for this? Or would be slow only during the use of GL-system calls?

I mean, if I've to render a scene for a simple screenshot the speed is not really important, I can wait a bunch of seconds if the result is a good quality screenshot. Maybe that virtually increase resolution and downscale would be enough, maybe with some shadow.

No, I mean that I must totally redesign rendering code to use different approach (over 2.000 rows of code), and the resulting code will be painfully slow.

I tried to enable antialias: resulting screenshot is better and performance are not so impacted.

A very basic function would be enough (with some options, for example choose if you want new or used parts).

Export use generic "brick" list, that requires LDD, LDraw and Bricklink part handling classes. Part code translation requires code mapping database between LDraw<->Bricklink, and this code is in common with LDD<->Ldraw and LDD<->Bricklink translation code. Database requires updates, ... Still lot of code to modify and maintain. No way.

Another chance could be an advanced export that requires brickutils in the same folder: the software automatically pass the data to brickutils and open it, so that you can access to more export feature from there. Maybe this could be achieved with few modifications to both JBrickBuilder and Brickutils.

This can be a good fallback strategy. Probably does not requires big changes in BrickUtils.

Ah, another thing I miss in the previous post.

When I move an already placed brick, the brick is turned upside down. That's uncomfortable because I've to rotate properly the brick from the scratch, instead than simply move it.

Program maintain last rotation used for placing last part, it is intentional. If you placed previous brick "upside down", block will be "upside down". Use the button with grid and brush to "clean" grid alignment.

Thank you for feedback

[Mario Pascucci]

Great project Mario.

I especially like that you've started to look at connectivity in the way you have. IMHO it's one of the most lacking features of the Ldraw platform, at least to attract a wider audience of users.

EDIT: There was an innitative a few years back, but I'm not sure what happened to it: http://www.ldraw.org...02-06-lcd.shtml

Nothing really happened with that (as far as I know). At the moment, programmers have to develop their own way of adding connectivity into the editor.

Last days/weeks, there's a discussion going on in the LDraw forums (so, not here) about connectivity and if and how to include connection data into the LDraw library.

So, there may finally be some improvement in the future in that area. At least, I hope so

I'm involved in that discussion (I've started thread when I published my connection model development specifications and connection editor with source code, hoping it can helps other developers), and some ideas coming out to be really good, but at the moment no action was taken by LDraw people.

There was some discussion on what purpose connection model must cover (only part snapping/connectivity, part structural info for moving/animation, other physical data for structural property/COG/stability), but I focused only on connectivity, so most people doesn't consider it worth.

Other program uses connection "snap" (SR3D Builder, LDCad), so my work is nothing new in that. The only difference is that my work is open and published.

Mario

[Calabar]

Thanks again for the answers.

Again, your quotes in italic dark red:

Try a "ctrl-c" when a row is selected in part selection dialog. It should copy the whole text line

I tried, but with no success. Maybe I've to try again!

EDIT: ok, I've found the problem. CTRL+C works, while the button on my mouse I use for "copy" (it is bind to CTRL+C) don't work.

There aren't free Java bytecode to native code, and results aren't so good. Java contains its own JIT compiler (Just in Time).

Oh, ok. I used a licensed computer programming tool, as a student. I was not aware there are not free software to do that.

I tried to enable antialias: resulting screenshot is better and performance are not so impacted.

That sounds good. What about providing a downscaling using an internal higher resolution? Is it feasible?

This can be a good fallback strategy. Probably does not requires big changes in BrickUtils.

Good for me too!

I hope to see it working soon.

Program maintain last rotation used for placing last part, it is intentional. If you placed previous brick "upside down", block will be "upside down". Use the button with grid and brush to "clean" grid alignment.

I'm doing some try, and still I can't understand how the software manage it.

Take two bricks and place them one over the other. Now take the second brick and turn it upside down.

Then take the other brick, it will be turned too. I place it over the first reversed brick.

Until now, all seems regular (and it is not so bad... it is comfortable sometimes).

Now, if I move the second brick I placed, the software reverse it again (now the brick is "straight"), but the last brick I placed was reversed. This is strange, not what I expected.

Then I rotate the brick so that it rest on a side, with studs on the right hand. I move the other brick and it is rotated in the same way but... with studs on the left hand (and I never placed a brick that way).

There are other similar behaviour moving the bricks, it seems to me that the moving function arbitrarily reverse the moved brick.

Maybe a new feature request could be a button to chose the behaviour of the move brick button: use the last rotation or maintain the rotation of the brick you are moving. Both the possibilities could be very comfortable, depending on what you are doing.

Edited February 13, 2015 by Calabar

[Zerobricks]

I gave the program a quick try and its very good!

I couldnt find how to rotate a brick around a pin though and the UI interface might need some work, but I have to say I'm very impressed!

[Mario Pascucci]

Hi Calabar.

Your question in red.

That sounds good. What about providing a downscaling using an internal higher resolution? Is it feasible?

Yes, but it isn't so simple. It requires an "off-screen framebuffer" (a virtual "screen" not displayed), but it doubles memory requirements. It is too long to explain here: every 3D element is stored in graphic card memory, in a "context" belongs to framebuffer. To use a second "off-screen" framebuffer I need to reload all 3D elements in a second "context" belonging to off-screen framebuffer. Context can be shared, but there are lots of limits.

I'm doing some try, and still I can't understand how the software manage it.

Take two bricks and place them one over the other. Now take the second brick and turn it upside down.

Then take the other brick, it will be turned too. I place it over the first reversed brick.

Until now, all seems regular (and it is not so bad... it is comfortable sometimes).

Now, if I move the second brick I placed, the software reverse it again (now the brick is "straight"), but the last brick I placed was reversed. This is strange, not what I expected.

Program maintain last transformation matrix: when you moved a brick and turn it "upside down", program stores a transformation matrix that say "rotate on X axis by 180 degree". From this moment on, every part you "take" will be rotated by 180 degree on X axis starting from current position, not from "default" position. So, if you have an upside-down brick, program will turn again upside down, or original position.

Maybe a new feature request could be a button to chose the behaviour of the move brick button: use the last rotation or maintain the rotation of the brick you are moving. Both the possibilities could be very comfortable, depending on what you are doing.

Or, maybe an indicator when transformation matrix isn't "zero", so you can use "brush-button" to clear to default. Anyway, if you see part rotating in an unexpected position, you can use the "brush-matrix" button even when you have a part or block moving under cursor.

Mario

I gave the program a quick try and its very good!

I couldnt find how to rotate a brick around a pin though and the UI interface might need some work, but I have to say I'm very impressed!

Thank you!

Program logic is a bit different from LDD:

• In LDD you place parts THEN rotate around a selected axis (and too often LDD rotate what he want, not you )
  
• In JBB you rotate part THEN place in position. After that, you can align placing grid to rotated part and all subsequent part added will have exactly the same orientation. Or select all parts that you want to rotate, select angle stepping, and rotate only parts you want.
  

Mario

[Nachapon Lego]

Great Job! It's good to have one more lego building software!

I tried Max setting: AF 16x + AA 32x CSAA + AA trans 8x(supersample) on Nvidia Geforce GTX 660M.

-Some line still not AA well and become dashed line. Maybe an option to chang line width can fix this?

-Only Lisa of Simpsons heads draw correct lighting. Maybe it is a parts bug?

JBrickBuilder by Nachapon S., on Flickr

Edited February 14, 2015 by bbqqq

[Mario Pascucci]

Great Job! It's good to have one more lego building software!

I tried Max setting: AF 16x + AA 32x CSAA + AA trans 8x(supersample) on Nvidia Geforce GTX 660M.

-Some line still not AA well and become dashed line. Maybe an option to chang line width can fix this?

-Only Lisa of Simpsons heads draw correct lighting. Maybe it is a parts bug?

Thank you bbqqq!

Next release will look better: program will have a new setting for antialias. General settings like you do works on full scene antialias, but program does not enable antialias for primitives, so lines appears aliased.

Yes, some parts appears to have incorrect winding (used to define surface normals for lighting).

Mario

[Lasse D]

Looks great. I can't wait to try this out!

It sounds like a lot of work to create the snap database. Something similar was done for SR3D, and of course LDD.

I have been working on a system for "crowdsourcing" connections based on the LDraw parts library with all data being open source. With your experience in the field, do you think such a project would be feasible?

[Philo]

Yes, some parts appears to have incorrect winding (used to define surface normals for lighting).

That's strange, these parts are BFC-OK (I just verified again Homer's head)

[Mario Pascucci]

It sounds like a lot of work to create the snap database. Something similar was done for SR3D, and of course LDD.

I have been working on a system for "crowdsourcing" connections based on the LDraw parts library with all data being open source. With your experience in the field, do you think such a project would be feasible?

Hi Lasse D.

I don't know. Surely, connection database is a huge work, and LDraw people haven't chose any strategy, best practice nor guidelines for that.

There was some discussion days ago, but nothing was coming out.

Crowdsourcing requires a quality control team, and a process to verify connection submitted before accept a new definition in database, so we need some kind of organization. But this is exactly how the LDraw people work, so I don't think it is a good idea a duplicate of LDraw organization. The best choice (IMHO) is that LDraw starts some work on connectivity database, inside his own organization.

Mario

[Mario Pascucci]

That's strange, these parts are BFC-OK (I just verified again Homer's head)

Forget that. There is a bug in JBrickBuilder triggered by last changes to normal calculation...

Sorry for "barking up the wrong tree"...

Edited February 17, 2015 by Mario Pascucci

[Lasse D]

Hi Lasse D.

I don't know. Surely, connection database is a huge work, and LDraw people haven't chose any strategy, best practice nor guidelines for that.

There was some discussion days ago, but nothing was coming out.

Crowdsourcing requires a quality control team, and a process to verify connection submitted before accept a new definition in database, so we need some kind of organization. But this is exactly how the LDraw people work, so I don't think it is a good idea a duplicate of LDraw organization. The best choice (IMHO) is that LDraw starts some work on connectivity database, inside his own organization.

Mario

Thanks for the links Mario. I have learned a lot reading the discussion at the LDraw forum. I'm planning on creating a database where users can submit connectivity in the same way as users submit models to Rebrickable. The aim is to be able to import/export connectivity in the four (five?) standards there currently are while using it to construct building instructions like LDD. I have 3 small projects that need to be finished first, but I will look into this once they are done.

[Mario Pascucci]

Hi people.

Some progress update before next release:

- added antialias settings (disabled by default). Appeareance is really good, but requires a bit more graphic power. Below you can see the difference:

No AA

With AA

- improved memory usage and general performance. I tested with a LDraw model of 10221 Super Star Destroyer on a Core2 Duo E5700 @2.9GHz (a 2011 desktop PC) with ATI HD5450 (a 2010 entry-level card). This is the result:

(sorry for graphic-intesive page )

- new connectivity search algoritm, using spatial index structures and ray-to-bounding-box collision. Speed is over ten time with models with over 2000 parts and grows very slow with model complexity.

New JBrickBulder release coming in few days.

Mario

[Calabar]

Great work and, again, thanks!

[Mario Pascucci]

Thanks for the links Mario. I have learned a lot reading the discussion at the LDraw forum. I'm planning on creating a database where users can submit connectivity in the same way as users submit models to Rebrickable. The aim is to be able to import/export connectivity in the four (five?) standards there currently are while using it to construct building instructions like LDD. I have 3 small projects that need to be finished first, but I will look into this once they are done.

It could be a nice thing.

If you need more details, look to my development documents, or ask freely

Mario

[Mario Pascucci]

HI all.

New release with:

- antialias (disabled by default)

- spatial index for connections

- lots of bug fixed

- 50 new part conneciton in database

- 12 new autodetected connection by primitives

Enjoy!

[BondemandClausen]

Seems like sourceforge are having some problems at the moment. It is not possible to download you program right now.

Edited February 23, 2015 by BondemandClausen