The_Cook

A very quick question I'm sure someone in the Historic forums can answer quite quickly as I don't have the set in question. Is the baseplate in the recent Kingdoms Chess a thin blow molded piece of plastic like the 90's raised baseplates or is it injection molded from higher density plastic like the ones used in the Bionicle playsets circa 2009? Thanks in advance.

Raised baseplates? Are TLG still producing them? Can our set designs include them?

Let's take that question over the Definition Of Design Constraints thread.

The Haven Guard If we're still casting around for alternative names then the historical nickname for His/Her Majesties Tax collectors in the Cornish area was "The Revenue". It's worth remembering that most pirates were sailors from the west of England, they go "Arrr" because "Oooh-arr" is the west country farmers accent. "The Revenue" feels right in a European context, I'm not sure it translates to the caribbean context. Opinions? Does anyone know the slang name around the Carribean for the Tax Collectors?

I recommend doing test renderings to check scene setup at a smaller resolution and without AA enabled. They'll render significantly quicker. Radiosity increases rendering times significantly as do transparent surfaces; turn these off whilst your working on scene setup tasks such as camera and light placement and only enable them as you're getting closer to final renderings. Once you're happy with the setup then you can enable all the extra bits and leave POV-Ray running overnight. A lot of people don't actually understand what POV-Ray is doing and turn all the options on at once without realising the additional complexity (and hence increased render times) that they're incurring by doing so. It helps to read up a little bit about the ray-tracing process (even if you avoid the maths the concepts are simple enough to grasp) and understand why it's different from the polygon rendering that packages like MODO do. It's not that one is better than the other it's just that they're different techniques aimed at solving different rendering problems.

Having walked Hadrians Wall from Newcastle to Carlisle a couple of years back and spent a considerable amount of time looking over the ruins of the milecastles I can say that the MOCs are historically, even down to the placement of the interior buildings and steps up onto the wall. I'd love to know if it was modeled on a particular milecastle. A truly wonderful series of MOC capturing a very interesitng piece of history. Perhaps one of the remote posts where the wall skims the top of Hardcastle Crags next?

For me it was a tie between the West Brick Trading Company and The Treasure Fleet. I can see play opportunities in both: The West Brick Trading Company has the perennial cops/robbers storyline but played out between Smugglers and the Haven Guard (they were known as The Revenue men in England), lots of small boats, secret passages, prisons to lock up in and escape from, etc... The Treasure Fleet has the race storyline and I'm sure that we can invent numerous challenges and obstacles that both parties have to overcome. In the end I went for West Brick Trading Company, as I personally think there are more possibilities there that play into the Pirates main areas of concern, that of boats and harbours; whereas I feel the Treasure Fleet is going to want to tend more towards jungle locations in order to facilitate the race aspect of it; probably at the expense of boats.

Take out the glass floor. Glass is about 20 times more computationally expensive than solid materials and you've got a whole floor of it. The normal peturbation texture map on the glass isn't helping either; that's probably inreasing things by a significant factor. If you need a reflection use a mirrored surface, but avoid transparent surfaces.

Yes, too specific... However don't let that stop your experimentation, if you can create a tumblehome with legal connections then it might be relevant for any ship designs that occur in the wave. As well as legal connections I suggest that any experimentation considers robustness of design, accessibility for "play", uses a minimum number of bricks and is simple to construct; all of which are likely to be criteria that designs are assessed on.

In terms of legal connections, this presentation by Jamie Berard is a good starting point for understand what is and isn't a legal connection. http://bramlambrecht.com/tmp/jamieberard-brickstress-bf06.pdf

I would advocate sticking to the 7-8 rather than lots of concepts. If we do decide to go with lots of concepts then they will have to utilise the "library" of torso prints that have already been designed for the wave rather than seek to extend that "library"; essentially the additional sets should be proposing alternative play options. Whilst the 2008 Fantasy Era castle theme eventually built up a large number of minifig prints this was achieved over the course of 2, possibly 3, releases in successive years. Each wave had that average number of new torso's mention in the earlier post, typically 10. I can do the analysis on a year by year basis if necessary?

I'd second that question. I'm only seeing the 'original' set of legacy colours rather than the much larger palette that the above screenshots are showing. I do have all of the CMF decorations so brickset 1392 has been applied.

I couldn't face analysing the Castle lines this morning, but I have done so now. Castle Kingdoms - 74 minifigures total - 20 printed torsos, 6 printed legs, 6 printed skirts, 3 printed armour Castle Fantasy - 104 minifigures total - 18 printed torsos, 4 printed legs, 6 printed skirts, 3 printed armour considering that both lines ran for at least 2 release waves that's 10 printed torsos and 6 legs/skirts per wave; which tallies with the previous analysis. I couldn't analyse the heads for uniqueness, but there is significant overlap on the civilians between the two waves and even pirates; the dark green bar wench gets around a bit...

Minifigure statistics - taken from Brickset / Bricklink. I'm no Lego historian so some of what I consider to be new might actually be existing moulds from much older sets that I'm not as familiar with. A quick analysis of recent 1 wave themes - I ignored the recent Dino theme because the antagonists are the moulded dinosaurs rather than other minifigures. Pharaoh's Quest - 12 minifigures total - 8 printed torsos, 3 printed legs, 6 heads, 3 new headgear moulds all of which are printed and one of which has 3 printed variants, 1 wing mould. Monster Fighters - 20 minifigures total - 19 printed torsos, 10 printed legs, 2 printed skirts, 19 heads, 3 new headgear moulds, 1 (pair of) new arms Agents - 32 minifigures total - 9 printed torsos, 4 printed legs, I can't work out how many heads are new, some have been re-used in other themes. Looking at the last pirate wave: Pirates - 63 minifigures total - 11 printed torsos, 1 printed legs, 3 printed skirts, 1 printed mermaid tail. I can't work out how many heads are new, most of them have been re-used in other themes over the intervening years. I believe all the headgear is old, or remoulds of existing headgear. The key learning point here is that for a fairly limited number of torsos a lot of unique minifigures are obtained just through swapping heads and hats. This is especially true for themes that are not character orientated because they're army builders, eg. Pirates and Castle. We should probably limit ourselves to between 10-12 new printed torsos, 5-6 new printed legs or skirts. From those we should be able to build a large number of minifigures by swapping heads, hats and changing leg-colours.

Moulding seems unlikely since the costs of moulds are astronomical, especially for large parts. We could potentially get pieces 3d printed to illustrate concepts but that involves money and the war-chest here is running dry, we'll be lucky to get a rum tot, let alone the gold required for a new hull. TLG can always replicate our ideas, they have the experience and the ability; but I would expect them to completely re-engineer them from scratch first! They are the experts at understanding how plastic behaves and flexes in order to create that all familiar click as bricks go "in-system". I believe part design at TLG runs between 6months and 4years, larger or more complex parts typically take longer. I recall reading an interview with Mark Stafford about the new ball joints and him saying something like 4 years of development. I believe of the Technic part designers frequents Eurobricks, it might be possible to get some generalised information from him with regards to timescales although he is under contract so probably can't do more than generalise. So, whilst it's do-able, I think we have to say no new parts. Same rules as CUUSOO (or whatever they're callling it now!). Any new parts would detract from the viability of our proposals since they would incur significant additional expense.

Looking at the picture you posted earlier it looks like only one of the vertexes in each triangle are being displaced from the surface, the others remain on the surface itself. This is most obvious on the one that forms the bottom of the L; you can clearly see the left-hand end raised up, whilst the right-hand end is level with the surface. I'm not familiar with your software packages but my instincts would be telling me to: Look at the surface normals for the vertexes to check that they're facing the correct direction. Ordering of vertexes might be important in order to determine forward or backwards facing and the order that your package expects might not match what the original source provides.

I'll echo Mister Phes thoughts. All the points that you've raised are good and valid opinions but some of them we need to defer until a little later in the project. This is a decision for the design teams working on the whichever proposal(s) we take through to the next stage. So hold those thoughts and bring them back up again once we've got through voting and moved into the stage called "Determining The Sets". That echoes our thinking. The assumption that we're working on is that if TLG produced this they would produce it as a fully fledged wave therefore they would invest in new printing on torsos. This is one to defer until a bit later. At the same time, or shortly after the sets have been decided, there will be a phase of the project called "Determining A Deseign Aesthetic", which is working out the colour palette and any common design themes that the sets should incorporate, each faction within the theme would probably having it's own design aesthetic. I think we're in agreement. Agreed. It's main a note to the MOCers who use scattered bricks for effect, in TLG terms this isn't a legal build technique. These are the sort of things that we're trying to get straight here in this thread. It could be any of those mention, details we'll leave to the set designers. The key thing here is to remind them that there should be play functions within the sets because they are intended for children who will want to play with them. Again, bring this one up again when we're discussing the set details, question people on what the play functions are. I agree that it doesn't need to be deep, but it should be obvious; as you say figure it out from the instructions or a simple cartoon on the back of the box or instructions. A little bit of conflict and storyline will generate a lot of play even if there aren't obvious play features such as exploding hulls, or firing canons. By the time we've finished identifying the sets there should be a coherent overall storyline for the theme and individual stories for each of the sets. The storyline needs to be language independent, ie. it can be expressed in pictures, rather than written form because the product is international.

Next topic really ought to be "deterime the number of unique minifig designs within the series". I'll do some research on the old pirates waves and the same set of 1 wave series from more recent years to establish just how many unique minifig parts are actually produced per wave.

Yes, I have my own personal set of matrix math libraries from previous projects and a background in computer graphics. The concepts are the same it's just that it's bricks not triangles that are being placed.

A very simple lxfml file of a light fitting, comprising of a Technic cross-hole brick with a stick with holder inserted into it, that in turn is holding an assembly element (palm tree top) with a 1x1 round and a dish. Feel free to cut-and-paste this into notepad, save it as light1.lxfml and load it into LDD to see what I mean. <?xml version="1.0" encoding="UTF-8" standalone="no" ?> <LXFML versionMajor="5" versionMinor="0" name="Light1"> <Meta> <Application name="LEGO Digital Designer" versionMajor="4" versionMinor="3"/> <Brand name="LDDExtended"/> <BrickSet version="1264"/> </Meta> <Cameras> <Camera refID="0" fieldOfView="80" distance="79.281982421875" transformation="0.030392518267035484,0,-0.99953794479370117,-0.93535268306732178,0.35257109999656677,-0.028440864756703377,0.3524080216884613,0.93578499555587769,0.010715517215430737,27.939624786376953,74.190887451171875,0.84954798221588135"/> </Cameras> <Bricks cameraRef="0"> <Brick refID="0" designID="3062"> <Part refID="0" designID="3062" materials="44,0" decoration="0"> <Bone refID="0" transformation="0.70710670948028564,0,0.7071068286895752,0,1,0,-0.7071068286895752,0,0.70710670948028564,-0.79999923706054688,1.5809999704360962,3.200000524520874"> </Bone> </Part> </Brick> <Brick refID="1" designID="2566"> <Part refID="1" designID="2566" materials="26"> <Bone refID="1" transformation="1,0,0,0,1,0,0,0,1,-0.79999935626983643,-0.1390000581741333,3.2000002861022949"> </Bone> </Part> </Brick> <Brick refID="2" designID="4740"> <Part refID="2" designID="4740" materials="26,0" decoration="0"> <Bone refID="2" transformation="0.7071068286895752,0,-0.70710670948028564,0,1,0,0.70710670948028564,0,0.7071068286895752,-0.7999987006187439,2.5409998893737793,3.1999998092651367"> </Bone> </Part> </Brick> <Brick refID="3" designID="48729"> <Part refID="3" designID="48729" materials="26"> <Bone refID="3" transformation="0.99999988079071045,0,0,0,0,1,0,-1,0,-0.79999971389770508,0.58100003004074097,2.0000002384185791"> </Bone> </Part> </Brick> <Brick refID="4" designID="32064"> <Part refID="4" designID="32064" materials="194"> <Bone refID="4" transformation="1,0,0,0,1,0,0,0,1,-1.2000000476837158,0.0010000000474974513,2"> </Bone> </Part> </Brick> </Bricks> <RigidSystems> <RigidSystem> <Rigid refID="0" transformation="0.70710670948028564,0,0.7071068286895752,0,1,0,-0.7071068286895752,0,0.70710670948028564,-0.79999923706054688,1.5809999704360962,3.200000524520874" boneRefs="0,1,2"/> <Rigid refID="1" transformation="0.99999988079071045,0,0,0,0,1,0,-1,0,-0.79999971389770508,0.58100003004074097,2.0000002384185791" boneRefs="3"/> <Rigid refID="2" transformation="1,0,0,0,1,0,0,0,1,-1.2000000476837158,0.0010000000474974513,2" boneRefs="4"/> <Joint type="hinge"> <RigidRef rigidRef="1" a="0,0,1" z="1,0,0" t="0,1.2000000476837158,-0.1600000411272049"/> <RigidRef rigidRef="0" a="0,-1,0" z="-1,0,0" t="0,-0.84000003337860107,0"/> </Joint> <Joint type="hinge"> <RigidRef rigidRef="1" a="0,1,0" z="1,0,0" t="0,0.39999991655349731,0"/> <RigidRef rigidRef="2" a="0,0,1" z="1,0,0" t="0.40000000596046448,0.57999998331069946,0.40000000596046448"/> </Joint> </RigidSystem> </RigidSystems> <GroupSystems> <GroupSystem> </GroupSystem> </GroupSystems> <BuildingInstructions> </BuildingInstructions> </LXFML> So, lets pick this simple lxfml file apart and see what we've got. The first line simply states that the file is XML and what version and encoding is being used. All fairly straightforward boilerplate stuff. Next we're into our first XML node that is unique to lxfml. Again there's nothing complex here the attributes are detailing the version and the name of the file the actual filename is "light1.lxfml" so it tends to match but doesn't need to. The next node in is the meta node with three child nodes. Application details which application created the file. In this case it was LDD but one assumes TLG have other non-public applications that they can use internally to create LXFML files. I'm fairly sure I've seen screenshots of apps that they use help them create the giant models such as the X-Wing or Bag-End. Brand. This actually seems to map to the mode that LDD was in, in this case I was using LDDExtended. Brickset. The version of the bricks database and models that is being used. Other on the forum track this more intently than me, I'm just using the latest version of LDD. [*]Camera node. Details of the camera. I'll admit that I've not investigated the transformation attribute in too much detail, it's obviously 12 double precision floating point values, but I don't know whether it's detailing where the camera is in worldspace or whether it's detailing how to get worldspace aligned to camera, one being the inverse transform of the other. [*]Bricks node. A list of bricks. I'm not sure what the camera node attribute is doing, I've just been defaulting it to the id of the one camera that was defined in the previous node. Brick node. The entry for a brick, where a brick can be made up of several parts. In this example all the bricks are plain simple bricks, but in the case of something like Minifigure Legs which count as a single brick that is made up of three parts, hips, left leg, right leg. refId is a unique identifier for every brick in the build, it appears to start counting upwards from 0. designId is the Part# number for the brick which you can see in the status bar at the bottom of LDD when you click on a placed brick. Part node. Again a unique identifier. My notes don't tell me whether this increments separately from the brick node, in this example they are the same but that might not be the case if you were using bricks made up of multiple parts. For all simple bricks the designId is the same Part# number from the brick. Materials is a comma separated list of colour numbers that represent the colours of the part. Most parts just take one colour, colour numbers can be found in the status bar at the bottom of LDD or others on this forum keep a complete list of all the possible colours above and beyond what LDD provides access to. Decoration is the decal applied to the part, eg. minifig faces. Again lists of the decoraitons are maintained by others on this forum. Only parts that could have decorations on them in real life are likely to be properly set up to accept decorations, all others will probably end up a bit of a mess. Bone node. Bone is a term dervied from computer graphics, in this particular instance it's easiest to consider that it's storing the information about the placement of the brick. Again the refId is a unique reference for this bone. Transformation contains 12 comma separated double precision floating point values that represent the first three columns of a 3d transformation matrix and are thus able to handle any linear transformation. It's something that you'll need to learn for yourself but the first 9 entries handle rotation, the last 3 are translation. It's worth noting that the origin of most bricks is at the bottom with the y-axis heading up through the center of a stud, this makes rotations around the axis of the stud slightly easier. Brick width is 0.8, brick height is 0.96 and plate height 0.32. This probably ties in with real world dimensions in some form, but I don't have the details to hand. The double precision floating point format can't necessary cope with precise decimal values as we might expect to see them, therefore you'll see slight deviations from the values given above, eg. -0.79999935626983643 instead of -0.8. Those 0.707 values are 45 degree rotations, they correspond to the sin or cosine of 45 degrees (or PI/4 in radians) and are part of the transformation. Transformations are in world coordinates. [*]RigidSystems. This node contains all the rigid systems, ie. groups of bricks that are stuck together and therefore rotate, and of the way in which these systems are joined together. RigidSystem. Another level of container, not sure why it's needed... Rigid. Each group of bricks gets it's own rigid system, each rigid system has a unique identifier. The transformation represents the orientation of the system within world coordinates. BoneRefs is a comma separated list of all the bones (and therefore parts) that are part of the system. Note that in hinge bricks the base part will be in one rigidsystem and the rocking part in another rigid system. Joint. The relationship between two rigid systems. I've seen both "hinge" for parts where the relationship is constrained to a rotation around a single axis, eg. hinges, turntables, minifig hands, etc... and "spherical" (I think that's the phrase, my notes are lacking because I've never needed to use it) for ball and socket joints where there are 3 full axis of manipulation. RigidRef. There needs to be 2 of these for each joint. The rigidRef attribute contains the identifier of on of the above rigid nodes. The a, z and t represent the axis of the rotation, a direction perpendicular to that from which rotation starts and the origin of the axis of rotation in the actual brick's frame of coordinates. These are all obtained from data within the bricks. Whilst lxfml is a public format that we can discuss and play with; TLG don't officially publish details of the xml format that describes the bricks and investigating that could be considered a violation of the EULA for LDD. [*]GroupSystems - I've not investiaged this [*]BuildingInstructions - Ive not investigated this In truth LDD might not use all of the features of the LXFML file format, eg. GroupSystems and BuildingInstructions, they might only be utilised by some of TLG's internal tools.Anyone wanting to understand and manipulate the format really does need to learn about 3d matrix transformations in computer graphics since it is a thorough understanding of them that will allow you to place bricks where you want them.Once you understand the format you can create entire models without ever actually placing a brick in LDD. Computer programs can be used to place all the bricks according to algorithms, my own work is this space has been to create an involute spiral as the basis of a Tower Of Babel, detail is then layered over procedurally.

I can probably help with this topic since I've been unpicking the schema myself and using code to generate mathematical shapes such as the following. It will take me a little while (perhaps a couple of days to refine my knowledge down into some posts). If you haven't already done so, get the details of the schema from this thread: LXF Schema

4:1 12:1 15:1 30:1 33:1 38:1

15: 2 12: 2 17: 2

Anyone that has been building Lego for any significant length of time will realise that sets designed by the The LEGO Group have a specific style of construction, to ensure that the builds can be replicated by children around the world, rather than the more free-form building practices of the wider MOC building community. If we are to create a new theme that the LEGO Group could potentially produce then we need to work to a set of design rules that emulate theirs. Rather than just impose a set of rules on the project the project management felt it important that all participants should understand how the design rules that they will have to work to have been determined. Collaborating as a group is the best way to achieve that and it allows everyone to see the decision making process in the open. It also keeps us honest, there's no point trying to cheat the rule and setting down rules that allow us to design sets with twice the number of minifigures than usual because the Lego Group would look at that proposal and turn us away. I'll get this topic going with a conversation that Admiral Blockbeard and I were having earlier so that you can see the sort of things that need discussing: Through individual research and group discussion we've established a reasonable outline for the target sizes and make-up of sets that The Lego Group have released in the past. The mix of set sizes seems to be consistent between the different single release themes so the project should try to match that mix.

Placeholder post for listing the Design Constraints as they are determined. This will be updated periodically as constraints are determined.