This topic will be for LOTR models. A lot of parts is missing, but I think they will be completed.

Attached Files

  30210 - Frodo with cooking corner.mpd (Size: 3.08 KB / Downloads: 3)

My first shot at the Lego Mindstorms shooterbot base

Attached Files

  shooterbot_base.mpd (Size: 3.74 KB / Downloads: 3)

Question to the part experts:

Do the edge line main points (nearly) always share a point with normal triangle and quad points. Or do they often ''float' between normal geometry points?

I would like to know this in relation to the current library, not the latest authoring specs.

...with some 250 new shapes...

I'm working on updating the forum them to better sync with the main site. Progress can be seen in the New Theme Forum I set up. There are quite a few rendering errors as this is still very much a work in progress. Some error are just styles I haven't dealt with yet, some are browser specific. I will try to make it render properly on Webkit and Gecko based browsers since that's what I have on my Mac. IE users will prolly be fine as long as you're running version 8+.

Also, does anyone use the jump menu? If not I think I'm going to get rid of it.

What are the official rules for scaling studs along the y axis? Am I correct that it is acceptable for underside studs, but not top studs? Personally I find no problem with the scaling of type 2 studs, but I've seen others place hold votes on files containing scaled type 2 studs.

I am creating sets from dino island to render them, but have problem. There are bended nets. A long time ago i saw this tool. Net generator is xls file. But i do not understand how to use it. If some one can make net for this model.

Attached Files

  car(chain).ldr (Size: 7.36 KB / Downloads: 0)

Hi at all,

Does anyone know if it possible to convert a XML file generated by pictobrick to a LDR file ?
pictobrick's XML shows the bricks (plates) in any row as a sequence of parts, row for row.
Such a conversion must be easy but browsing around for hours I couldn't finding such a tool.

Thanks for any help,

Arthur Sigg

Hej guys,
I got a request from the German LUG 1000steine.de that some members would like to have the switches 2890 and 2889 as LDraw parts. As I don't have the part and the part is to complex for a photo based worked, I hope that here is someone who wants to accept this challenge. Thanks

/Max

Hi Y'all,

I hit a bottleneck in my performance optimization work with BrickSmith: LDraw parts have no concept of "level of detail."

If I open Datsville, I'm staring at 125,000,000 vertices. They aren't all necessary when drawing the entire model in an 800 x 600 window, but there isn't any meta-data to help me drop some of them.

This is half of the level-of-detail problem: for very low-resolution rendering of huge models, the parts are too detailed, burning GPU power. The flip side of this is that close up, the studs look like prisms and not cylinders because of the low vertex count.

This got me thinking: if parts (or sub-parts) had a level-of-detail scheme (with multiple versions of the parts for different resolutions) we could have our cake and eat it: for wide views a stud could be a cube or some other super-crude, super-cheap structure. At high res we could crank the vertex count, eliminating the need for viewers to do ad-hoc sub-part substitution.

Here's the question I have: how could/should a renderer decide _which_ level of detail to draw? I can think of a few heuristics:

- The levels of detail are arbitrary; the client program picks one based on current performance and context. In other words, when you say "export PNG" the highest level is always used. During rendering, the program steps down LOD one notch any time the framerate drops below 10 fps and cranks it up one notch any time it exceeds 30 fps.

- Levels of detail are based on scale. In other words, each level of detail specifies a range of pixels that an LDU covers. If the rendering scale is such that an LDU is less than "X" pixels, we go to the next LOD.

- (If LODs are based on scale, then we have to ask whether the cut-over points should be arbitrary or specified in the spec or library standards. There's a big technical win for programs if there aren't a million different cut-over points.)

Are the LODs advisory or required in their cut-over points (for programs that understand LOD)? Thoughts?

My hope with LOD is that with a little bit of work on a very small number of sub-parts, we could make a big difference. For examlpe, just by creating an octagon low-LOD stud, we could cut 90,112 vertices from every 32x32 baseplate - there are only 3 sub-parts that would need modification in this case. I think the strong factoring of the part library could be a big win here.

Cheers
Ben