hrontos

When I saw this for the first time, I did not wanted to bump into this older topic, but now I will take the oportunity to say how impressed I was. I like the boom design and the track extension function is something I have never seen before.

It's amazing how he managed to design the body to match the real one. Really nice. And the size of the model is impressive.

This tractor is really nice. I had few oportunities to see such in real life. I like how it "shakes" just like real one with the same engine. And even the forward movement is not so smooth with this engine - originals with similar engines have the same problem until they reach a certain speed. Very realistic engine and tractor.

My Technic challenge 2012 entries: Topic: Lego technic challenge 2012 - post 205 LDD file Topic: Lego technic challenge 2012 - post 269 LDD file Topic: Lego technic challenge 2012 - post 288 LDD file JunkstyleGio was a great help for me with this entry and I would like to thank him for that.

The connection you are trying to achieve is actually not a connection from the software point of view. It is treated only as bricks placed freely next to each other (no matter how tight). The only way to place it where you want, is to use scaffolding. This means, that you have to add some suitable bricks, that will really connect to both complex components. After successful placement you remove the helper bricks.

@Philo: that's exactly what I meant. I will write a small program that will take ldr and lxf with the same model having only two parts. One part has to be known in LDRAW..xml for the other the program will output new lines that should be added to LDRAW.xml. Rest will be task for the community, since I do not have the part to part code mapping and doing it from scratch will take me ages.

I wonder, if there is any interest to add the missing transformations? It looks like one possible solution to do it is to build the same two part model in LDD and in LDRAW. One known and one new part. By putting the new part in the same position relative to known part it is possible to automatically derive transformation needed for the new part. Without too many trial/error attempts for each part.

I am sorry Markus, I think, there is no simple solution. Actually, the problem is more complex than it seems. It is not engough to just map the part numbers. LDD parts have different origin point (central point) and different initial orientation than LDRAW parts. This means, that for each part you have find a transformation that properly recalculated LDD position of the part to LDRAW position. And this is timeconsuming and was done only for some parts.

Congratulations, well deserved. I like your alternative models.

This is really great work. It's very professional, that you paid attention not only to final look but also to building techniques and durability. I am not a fan of "display only" models so you really impressed me how you paid attention also to full function and playability. Supported.

Yes, I know. And that's why I am afraid that final product will not have some of these impressive details. I hope it will stay like this as much as possible.

According to the rules: Licensed ideas are OK, but note the following. You may submit models that require licenses, but be aware that we can't guarantee the production of your model if it is linked to a competitive licensor – this is where all the legal stuff becomes complicated. Minecraft was probably also licensed, so to suggest a licensed design is not a principle problem, it is only a bit more complicated. It is a beautifull model that deserves being supported. I only have some doubts about the model with all those beautiful details being too much fragile for a mass production. And a more robust design will probably mean a loss of details.

I don't think there is some direct relation between ability to solve mechanical puzzles and technic building. Technic building is more like chess playing and imagination. The more future steps are you able to plan and imagine the less reworking you will have. I am a software engineer. Typical for a software development is to work in cycles. Each cycle refines previous outputs of a previous cycle. This approach seems to be in a contradiction with technic building where you cannot build and then refine and much more planning is required. In sofware it is enough to avoid "closing some possibly usefull doors". Digital design sometimes helps to get faster results, because rebuilding is may be faster. Good technic builder should have good technical knowledge, so that he does not have to invent already invented constructions and principles and he should have also a bit out of box thinking to have creativity. I think it is completely ok to build and rebuild. Contradictions and problems in technic building are much more often than in a standard engineering, because parts are given and you cannot modify them. I also have some unfinished builds, but it looks like I have to "grow a bit" to finish them. So I tried some others in between just to get that nice success feeling. Without these simplier builds in between a man is just frustrated. And sometimes good idea comes on its own.

The only solution I have found until now was to use groups as building guide steps and then using a simple XLST transformation transform those groups into building guide steps. Such building guide is saved directly into model file and LDD will use it when you switch to building guide mode. But this building guide will be preserved by the LDD only until the model is not changed. When you make any minor change in the model, automatic building guide generator in LDD will be activated and your custom steps will be overwritten, so the XLST has to be run again.

This is really nice solution. Even there is that gear skipping risk under high torque it is still very nice and elegant. With PF Speed remote this approach can be used as some kind of multiplexer - one input and multiple outputs selected by the position of the speed remote.

I probably misunderstood something. The model is designed using the 9398 chassis, you can check the LXF file, it should be buildable from real bricks. Since there are some limitations given by the chassis, it is not perfect scale model of a real quad bike and some elements should be offset by 1 or 2 studs (like steering should be placed more backwards).

Thank you, I am glad you like it. I updated pictures with the latest version in the original post. There is also side by side picture with original crawler - just for a size comparison. LXF file you can find here. According to the LDD Manager, model is already buildable from existing parts (the only non-existing part is 3x3 T-Shape in blue color). I would like to thank to JunkstyleGio for the final footsteps and other usefull hints.

Both LDD LXF format and LDRAW LDR format contain only part IDs and positions. They are not like real 3D formats with complete 3D data. 3D data are stored in separate database. In case of LDD it is the db.lif file and in case of LDRAW it is the directory with the DAT files. This means, that you can convert LDR to LXF, but your changes in the custom DAT file will not be reflected at all since DAT file will not be merged into db.lif file. And it is not possible to add DAT file to db.lif and so no custom decorations in LDD are possible. Or may be I missed what you wanted to do?

@Jovel: you can find the lxf file here. Check also next posts, since there are some improvements.

Thank you. I wonder how it would look like with your tracks (or may be some simplified/smaller version), since quad bikes use tracks for the winter. I think this is true in that sense, that the later is creation submitted, the more likely the submission will look like something already submitted and somebody will complain.

I think they will not take these votes into account. They do not have other gallery implementation (without voting) or may be it is a kind of test. Or they take these votes as some clue what fans like. But real voting will start only after jury selects those 10 final models. But I may be completely wrong. Thank you, I also find the darker blue nicer in combination with the white. And more fits to police blue color. I presume they will add some stickers somewhere on the model, but it is good to have it colorfull also without stickers since many people do not like them.

I would like to share with you recent version of the quad bike. I would like to thank JunkstyleGio for this improved color scheme and his help with the footsteps (he made next version of the footsteps in the mean time, but I do not have renders yet). One antenna also will be removed and signal light on the end of antenna will be smaller (probably a 1x1 cone). Rear lights will be placed on the top of the rubber mud guards, bottom yellow tile with stripes will be removed, rear singal lights will be different. Comments and suggestions are always welcome. I just noticed I used two different blue colors. Which one is better?

Yes, I can run the render. Just position your model into desired position in LDD and specify resolution. Aspect ratio of the image has to be the same as aspect ratio of your screen. I will use only LDD level of detail, since full details would take quite long. For lighting I will use some HDR image (interior).

Well done, with the body the wheel angles look just like on real Dakar Tatra without load. Looking forward to see it "in the wild".

Shock absorbers range in this configuration may look small, but real life 8x8 vehicles (like those participating in Dakar rally) also have limited range. And I think, that in your scale, your range matches well the real ones. These "structural" issues are difficult to judge when building in LDD. That is probably the weakest issues in digital design.