Mario Pascucci

Hi Philo. Cause my really limited time and my loss of interest in this project, I do not maintain anymore this software. Sorry.

It's a bit complex to explain. Connection database is splitted in two categories: connection that working with autodetection and connection that needs a description file (XML) in connection database. Program logic is: 1- if there is a connection description file GOTO 3 2- do connection autodetect - GOTO END 3- read connection description from file - GOTO END 4- END So connection autodetect can be perfect, almost working, totally broken, giving the way it works. To see if a part has correct autodetection, I use a program to see "visually" how and what connections are autodetected. If connections are perfectly detected, I mark that part to become "verified" in part list (cyan background). If connection autodetect is broken for a part, a file with correct connections is needed, so I design connections and write a file. In part list these parts are marked with green background. Parts with white backround are "not verified", or, I've not checked if autodetect works. So program do *always* autodetection for these parts, but probably autodetected connections are wrong or (in best case) incomplete. More informations: http://sourceforge.net/projects/jbrickbuilder/files/jbrickbuilder/connections/jbrickbuilder-connection-manual-en.pdf/download http://sourceforge.net/projects/jbrickbuilder/files/jbrickbuilder/jbrickbuilder-manual-en.pdf/download

If part is in database then is "working and verified". Not in database->not verified, probably not working.

Hi all. New release with experimental building step editor and player. I'm not completely sure that it is the best interface and controls for building step editing, but consider it as a first try to a visual approach. Also, 1260 parts in connection database. See top post for links and details.

Quite impressive! Really a good work

@agadoijo I don't know the exact reason. It is outside my code, it is an error related to OpenGL Java library JOGL: https://jogamp.org/bugzilla/show_bug.cgi?id=1150 I tried a workaround, but I can't test if it works. I uploaded a modified version to sourceforge with 0.2.1.1 version number, so try to download again. It is a minor patch, so users that doesn't experiment same problem don't need any upgrade. Let me know if this solve the problem. Thanks for feedback Mario

Hi all. New release with: - experimental flexible parts support (axel, rigid hose, pneumatic hose, string with stud ends, ribbed hose 7mm dia). - Cut/copy/paste - Undo/redo - 850 verified parts in connection database A short screencast video on flexible parts editor: See top post for links and details.

@bublible Catalog function in Brickutils is only one of the functions, and not the main goal. But if you want to know if you can build your MOC, designed with LDD or LDraw, using the parts of (to say) two Town Hall, and with program reporting what parts you need to buy on BrickLink, a little catalog is needed, don't you? :D BrickUtils can read digital models (LDD or LDraw), import set inventory, order inventory and store inventory generated by BrickLink, checks your MOC against these inventories, list missing parts, export a "wanted list mass upload" file to buy bricks on BrickLink. @backbencher Sounds as you have some network configuration that prevent BrickUtils to get files from Internet. What to check: -Windows firewall (BrickUtils must access Internet to do his work) -If you connect through a proxy, Java needs some configuration to use it. BrickUtils does not handle proxy itself. -sometime SourceForge.net is under heavy load, BrickUtils gets all its files from there, so downloads fails.

I quickly look into file, and I have bad news for you: - file starts with (hexadecimal notation) 0xef 0xbb 0xbf, that is an UTF-8 Byte order mark - fourth and fifth byte are "PK" signature of a normal ZIP file - but lots of bytes inside ZIP was replaced by a sequence of three bytes 0xef 0xbf 0xbd that is an UTF character called "replacement character" used to replace an unknown or unrepresentable character in UTF-8 coding (a black diamond with question mark inside). - almost 20% of your file was replaced by this three-byte sequence. So, briefly (and sadly), your file is gone .

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!

It could be a nice thing. If you need more details, look to my development documents, or ask freely Mario

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

Forget that. There is a bug in JBrickBuilder triggered by last changes to normal calculation... Sorry for "barking up the wrong tree"...

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

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

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 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

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

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

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. 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. Not at the moment. 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. 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. I know. I'm searching an enhancement for this, but at the moment I haven't found anything I like. 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. 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. 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! 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

Hi Calabar, thanks for your feedback. 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. 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. See above reply. I can see if I can arrange a slightly better rendering only for a screenshot. 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. 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

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

21110 - Research Institute (Ideas - 2014) File MPD. Created with JBrickBuilder. Errors: All torso prints wrong Minifig faces print wrong missing sky map print Dino tail wrong (part not in library) Astronomer hair wrong (part not in library) Magnifying glass part #10830c01 not in library (replacement used)

Hi all! A new BrickUtils relesase is out! It is version 0.2.1.0 New features: - a powerful export function using templates: user can define his own document format and export wanted lists. It uses Apache Velocity Template engine. - new program release check at startup - improvements and bugfixes. Enjoy!

Mh. List id 3077 seems too little to me. Are you sure it is the real id? (not the name you give to the list, but the numeric ID that BL gives to your list). As you can see, list id is on the left (a six digit number).

8060 - Typhoon Turbo Sub (Atlantis - 2010) File MPD. Errors: missing stickers missing all prints Wrong competition cannon type missing helmet and air tanks part missing helmet visor shark head missing Made with JBrickBuilder