hrontos

This may look like 4 times more pixels, but the default POV-Ray antialiasing uses 3x3 neighbouring pixels (can be more if you want). So it actually spawns extra rays for those 9 pixels to do the antialiasing and resulting time might be longer than using higher resolution without antialiasing. I think, speed of rendering using antialiasing actually strongly depends on how much antialising is really necessary, since POV-Ray is doing this extra tracing just when it detects a pixel that needs the antialiasing according to specified AA treshold. In case of higher resolution render without antialiasing POV-Ray has to do more even if not necessary.

I think your problem is that the ini section name [1280x1024 ....] does not correspond to what is defined in that section. The name of the section can be anything. Open the resolution ini file using the Tools menu and find the section named as your selected resolution and check the values of Width= and Height= statements. Make corrections if necessary. And start the rendering using the render menu (not the render button, to make sure ini is reloaded).

Shadows are results of tracing "shadow rays". There is nothing like that in nature, it's just technology used by POV-Ray. If object is transparent, it means, it is transparent also for those rays and it is not possible to cast shadow on fully transparent object or background. There are some techniques how to overcome this, one of them is described here.

HDR lighting itself does not have influence on performance. It works with radiosity and performance of radiosity does not directly depend on it. This means if you use HDR image or solid color sky sphere the radiosity sampling will take almost the same time. Radiosity itself is controlled by more than 10 parameters and it be like few hundreds of pixels per second to few pixels per minute. It does not make sense to go below 20 pixels per seconds. The will be no significant difference for us "amauter renderers". This performance is for i3@2.4GHz rendering using POV-Ray 3.7 utilizing all four available cores.

For LEGO rendering purposes not. MegaPOV has richer scene definition language. It supports hdr lighting which was not supported by POV-Ray before version 3.7. POV-Ray 3.7 support multi processing and that's the main benefit. HDR lighting is also supported.

It works in POV-Ray. Just add background { color rgbft 1 } to your scene and render with +ua option.

Yes, of course, you should start with one root group that will at the end contain whole model, all steps are actually a subgroups of that root or subgroups of other subgroups. Just like one building guide contains more submodels. Number of group levels seems to be unlimited, but building guide mode can handle only 3 levels, so when converting groups, the levels are flattened. It is still good to have number of group levels as high as needed and not only 3 since I hope LDD will support more in the future. Subgroup display can be rotated and LXF contains fields containing orientation of the sub group but LDD does not store the adjusted orientation there. If they will improve it, we will have easy place to store view for each building step. I manipulated the model file using xslt transformation, if you want, I can post it here. It can be executed either by msxsl.exe or any web browser. Or I will wrap it to some simple exe that will be just asking for a model file and add building instructions there. This assumes "forward" groups, not reverse order. But can be modified. Pure XSLT works also on Mac, exe only in Windows.

Yes, this approach is quite easy, but it has two problems. Grouping in LDD is kind of clumsy - when you make mistake, it is not easy to insert group between existing groups, so you have to plan carefully. As best approach seems to be not build the model but to disassemble it - this means that groups are in reverse order - you actually remove bricks from finished model. Using the hide tool you can simulate removal. Add bricks to group, select whole group and hide it. Continute with next bricks, create additional group and hide it. Transformation from groups to building steps is easy. Then comes the problems of correct view point selection, since LDD does not save the view when in building guide mode. There is no simple solution for this.

Technically it is not a big issue to convert either LXF or HTML building guide to Bricklink XML. The main problem and also most valuable part of the LDD Manager is the mapping database. It is not possible to convert LDD part IDs to bricklink part IDs without such database. If we have such database in XML, there will be no problem to convert it even with only usage of webbrowser.

We have tried only screensharing directly provided by Skype, but it's one directional, so it is really only for presentation purposes, remote assistance over Skype does not work.

I think this again the case Superkalle mentioned many times: in Extended mode TLG gives us all parts they have at certain moment of time, no matter how much unfinished they are. There many parts that should flex and cannot flex yet, I presume it will be added later.

No, unfortunately it is not. In case of LAs it was just modification of the position of parts of LA (LA consists of 4 parts), but in this case band is just one part, that needs the data for flex tool to be modeled by TLG to be able to change it's shape.

I think, the point in this discussion is, if we want to stay only within legal boundaries or we would like to keep good relationship with TLG. If we want to stay only legal, go on, publish your findings or source and on next day we can expect that TLG will change the format. It must be clear to any programmer, that without any siginficant effort they can add some simple on the fly encryption without making any big change to the format itself. If we will try to keep also good relationship with TLG, we will ask them for permissions. You can probably create whatever application you want as long as you stay withing the boundaries defined by TLG. And from my point of view, this boundary starts by keeping the brick definition data unpublished. So you if you want to create mobile version of LDD or some building instruction generator, model animation - these solutions does not necesarily require publishing the brick data and have big chance to be approved by TLG. Conversion to other 3D formats might be an issue, since it is hard to find a format which works in the way similar to LDD (model file without geometry and primitives library containing the geometry).

I am not lawyer, but "allows reverse engineering for the purposes of interoperability" means, that you can reverse engineer for example Word to understand the doc format and to be able to read it or write. So you can reverse engineer LDD to understand LXF format or to be able to produce your own LXF files. Or if you are good, you can create LDD compatible bricks geometries. "Allows reverse engineering for the purposes of interoperability" does not give you right to use existing brick geometries from the LXF files for any purpose without approval of the TLG, since they are intelectual property of the TLG.

What happened to that web browser pane on the right side? It no longer appears after the update.

Yes, it behaves like that also for me and it can be even saved. This means, that it is not only some corruption of the brick geometry data during the rotation, it is corrupted transformation which is also saved to LXF and can be reloaded. And it actually resizes all parts attached to that chain link while rotating. I have never seen rotation circle without those green arrows on other bricks.

Really nice addition of bricks. Thank you for the 6573 Differential gear casing and 601948 Turntable. And for the fixed chain links.

How did you do that, I am not able to repeat it. Now matter how I rotate the parts, they keep the right size.

Luckily the LDD was designed with focus on kids, it is really not text-heavy, that why I treat this as a minor request. I just noticed that in the past the translation of LEGO software was simple, now it is more complicated. Since we do not know what will be added in future relases and if it can be kept as mostly icon based application, I would like to have the possiblity to have it translated without any significant effort from the TLG. The same applies to all the Mindstorms software.

Just minor wish, which probaly does not bother the AFOLs. Recently I have installed the old RIS2.0, because my son use it during ROBOLAB lessons and noticed, that at that time TLG put all language dependend strings into separate simple editable text file, so the whole software can be easily translated. I would like TLG to return to this approach in case of LDD5 and any other software. I do not expect, that TLG will translate it to all languages, but we can and younger kids can focus on the play and not on the English or German language. I don't think that creating new separate custom language file is violation of EULA. In case of LDD the language file is now packed in the assets.lif and repacking assets.lif would be a violation of EULA.

I agree, the bricks are the most important part of it and open source will not solve it. And as far a I know, LDD contains licensed code, so it is really very unlikely to become open source. So I hope, the development will continue (may be not at current speed). If it will come one day to question if it should continue, I vote for continue and if we have to help, I would like to. When I look at the list of various wanted features for the LDD5, I think most of them are now reduced to one basic common wish ...

It would be nice to have the LDD as open source, but I don't think it makes too much sense. I think, the biggest advantage of the LDD are the regularily added bricks, not the functionality. And when it will be open source, it will just suffer the same problems (mainly lack of the new bricks) as the other open source tools and may be they will be even bigger, since brick definition is more complex in the LDD than in other tools. But if the TLG will continue supplying at least the brick geometries they have, the rest of the brick definition can be added by future the LDD open source developers and it could be developed to a powerfull tool.

Man has to be slightly more optimistic, to see it as a future way of building LDD models. I mean, to apply 4 stickers on technic axle sounds at least strange, if not impossible. But may be, with faster processors in the future, it will recognize bricks without stickers. But even after that, it still somehow opposite of what I expect from LDD - and that is prototyping. LDD is good to test build before buying bricks and this way you have to have bricks before digital build. I have 4 years old daughter and as every kid, she likes to apply stickers and play such a simple computer games, so for kids of her age it is quite funny combination of computer and LEGO building game. And since some parental assistance is required to apply stickers correctly, it is not only building LEGO, but also building good parent/child relationship. It would be better to have it on PC with webcam and not only mobile version. The mobile screen is far too small for such target audience.

LDD comunicates with a webservice on standard http port 80.

I am not sure how build all those angles, if you made some calculation in advance on paper or something like that. I usually do it in tha way which is not natural with real bricks, but works easily with LDD. I mark a center of such circle. Put the a one stud brick (either 1x1 plate or 2x2 tile with stud in center) this serves as a center of rotation for hinge tool. Then I put leftmost and rightmost brick, connect them by beam accross center of rotation and rotate using hinge and by entering exact number of degrees (step is 360/number of angles - 22.5 for your largest circle). This way the result is easier to calculate and more accurate then specifying angles between neighbouring bricks (which is natural build order when working with real bricks).