hrontos

"finish" is valid only as a member of "texture". As I said, you do not have to modify pov file, create file with custom version of ldd_finishes.inc. As a good start copy ldd_finishes.inc to ldd_my_finishes.inc and make some modification. Check "Use custom finishes" and select the ldd_my_finishes.inc file.

ldd_finishes.inc contain definition of all finishes used by converted models. If you declare some of them directly in pov file, they will not be redefined by ldd_finishes.inc. This means, that you do not have to modify ldd_finishes.inc. You can even create a file with your custom finishes and select it directly in LDD2POVRay interface. Feel free to experiment. The approach you mentioned should be also possible (you miss the texture statement), but it will result in multi layer texture which will be even more slowly to render then the current ones.

This reminds me traditional animation. Small figure movement and photo, movement and photo. A lot of small work to do. My wife is a teacher and on some lessons about art they should be doing also traditional animations. I will share your tutorials with her, because they are good and for kids this Lego+digital might be interesting approach with much better results than traditional camera+figures+photo. Thank you for your work.

This is a question probably more towards POV-Ray's docs. LDD2POVRay is not using some features of POV-Ray, so there is probably no difference in Q9 to Q11 settings.

The present behaviour is just a simple consequence of two assumptions: 1. when output file name is empty, it is the same as input but with pov extension. 2. when output file name is not empty it is assumed that it was specified by user and it has to be honored as much as possible to avoid "fight with user". Therefore when new lxf is chosen, output path from existing output file name is preserved, but name is taken from new lxf file to prevent file overwrite. It looks like it is not very often used to render many files one by one, so nobody commented.

I am sorry, if you found my answer somehow offending. English is not my mother's language, so it is better not take each word literally. Peter Collins Publishing Ltd. Business Dictionary says about complain: "to say, that something is no good or does not work properly". You found it as a bug, which is normally considered in case of a software as not working properly, so I thought that it is suitable word. But I am once again sorry, if you found it offending. This should be avoided. When you save files in the same directory as includes, rendering will not work. As we spoke before, files in the same directory as pov file have higher priority and therefore POV-Ray will try to use them directly from disk and they are not readable for POV-Ray. They have to be accessed from \\.\LDDIncludes which is a connection to the virtual file system.

Actually it is probably more stable than it looks. These days tractor have huge counterweight from iron put in front to make front heavy and to prevent flipping to back when pulling large weight. This is just another way how to do it and save some iron. Moreover, good access to engine is presented as a big advantage on the wiki page.

Very nice replica of the original. Wouldn't this one also fit into running Model Team contest? Or is it too much functional for Model Team?

Very nice tutorial and clever designed characters. It is clearly visible, how much effort you invest into these tutorials. Thank you.

Converter tries to maintain the output path and changes only file name. There is no way to guess, if the output file name and it's location has some logic related to input file name. For the first file, converter offers the same directory as the input file name has. From that moment, it assumes that output path and file name was edited/entered/accepted by the user and so for following files only file name is changed directory is maintained. You complain that it should change also the path, because you want have lxf, pov and ini in one directory. Somebody else has lxfs in one directory and wants to have all povs and inis also in one directory. For him is better preset behavior. We can vote and what more people preffer, can be the default behavior This is behavior of POV-Ray. Include files are first taken from the directory where pov file is located, then from the Library_Path in give order (order of Library_Paths is displayed on the messages pane. So files in pov directory have higher priority than any other. Version specified in the pov file is not about version of POV-Ray being used. It is about selecting desired behavior of POV-Ray. POV-Ray actually requires that some version has to be specified. And so 3.6 was chosen. For example handling of background and sky sphere in combination with output transparency seems to be more logical than with 3.7 version settings.

Wow, this is aa completely different level of building a bike. It took me while to recognize, how big it is. Looks great, looking forward to see it in real bricks.

LDD2POVRay files contain camera definition based on variables, so you can use them to position also your plane. So you actually do not need gradient background. At least not in terms of POV-Ray's background. And you will probably not achieve smooth transition between two planes - background and floor. There will be always a line visible.

Yes, of course such feature should be possible. It is a patience training. If you will complete this training, you have a big chance to hold on also the long rendering times.

Check this sample.

On the real Tatra angles are really not that big as seen on the models. A swing upwards is limited by the rubber stop to 7°. A swing downwards is limited by the stop in the axle final drive housing to 12°.

Yes, you can have it as an option. According to official webpage, it looks like all military versions have the reduction in wheels, in versions for mining or construction industry it is optional.

For me, there is nothing strange that a company offers the same thing or service at different prices. Price is the only way to force a customer to buy it the way preferred by the company. If customer service is dedicated to help customers with their issues, it is normal, that company wants their customer service stuff to be busy by talking to customers and helping them and not packing bricks. If pick a brick is the service optimized for packing, they are packing and parts from them can be cheaper. I can imagine, that customer service is actually forwarding the request to the pick a brick and since they do the forwarding for the customer, they charge extra price. Of course, they can say go and get it from the pick a brick. But some customer just do not want to do it that way and want one contact point for all services and are willing to pay more money for that comfort. It is normal to see an e-shop selling goods which offers a pick-up service in their traditional stores (from bricks and concrete, not e-shop). And the price in the traditional store is higher than the one on the e-shop. Sometimes, I just make an order and go immediately after confirmation of availability to pick it up. And they give me the goods right from the shelf. The same goods without the e-shop order would be 10% more expensive. That's their way how to optimize store stocks. So that's why I am not surprised, that TLG is doing something similar from whatever reason.

May be the TLG prices reflect the price of the service. They accept, that you order a few parts from customer service, but they want the larger quantities to be ordered via pick a brick. Why they have two services for virtually the same, that is another question.

That's what I like about the idea. Return to center solutions are quite common, but many of them are based on stalling the motor.

I am sorry if there is a misunderstanding. I do not suggest to buy M motor. You asked why to built something like this, when you can buy original servo. I wanted to point out, that it is usefull for those who have M motor, which is quite common. I also wanted to make people more think about how to built some something than where to buy something. I will not return to this "buy or build" discussion since this is not very on topic.

It is again not about buying M motor. Servo is a part that is less common, because it is relatively new. So for a person with only M motor these solutions and ideas are useful. For AFOLs it is quite typical, to say I will buy, I will order from Bricklink etc. For kids it is more about original purpose of the Lego - which is building. AFOL will sit at computer, order a servo and wait a week to be delivered. Kid, TFOL or a student with a limited budget will spend that time building alternative solutions using available parts. I just prefer the second approach. Many nice ideas came exactly from the ability to make a compromise and use what was available. To the original idea: it is really nice attempt to recreate the servo behavior. The shaking motion can be probably reduces exactly as Zblj suggested.

An to complete the "why unaligned" question: older versions had them aligned by using differently size gears. Newer version prefer symmetric axles, so "unaligned" was a solution to the problem how to make left and right half-axles identical. They are shifted by 51mm and there is a difference between versions: Tatra with reduction in wheels has right half-axles shifted forward. The models without reduction in wheels have left side half-axles shifted forwards. This because half axle rotation direction is different when there is a reduction in wheels.

Let me think. May be because Lego is about building and not buying? According to your attitude why to bother to build anything when you can buy a perfect high-peformance RC or beautiful display models?

No, you cannot, but you can find that strange material ID in the converted POV file and delete whole part. POV-Ray will not complain.

@Bricksandparts: he is asking for some good png files that he could use in LDD2POV. These images does not have to be somehow technically specific, they just have to be nice minifig decorations from Classic Space. May be somebody made some custom for his custom minifigures. Or drawn images based on real minifig print. He is asking where he could find such png/jpg files.