MOC methodology

[niknarjc]

Hey all just seeking some input. I have started disassembling some of my sets here and there to make modifications to them. Using the existing designs and functions to gather techniques for making my own MOCs. Redoing the suspensions, making lifting mechanisms, and changing the steering. I have toyed with the Lego Digital Designer but have not ever completed a design.

What are some of the methods y'all use to create your MOCs? Do you just build and the final product develops itself, or do you work out all the details before the build starts?

[MaxSupercars]

Someone loves to play with bricks and make development on the table by building bricks... someone make the computer model and build then... both methods are used...

The second is also used by big projects, where you need a thousand of bricks...

Max...

[D3K]

For models where I know there is going to be a lot of gears criss-crossing and working multiple functions, I find Lego CAD software to be pretty invaluable. Using different colours to keep track of where the different motions go when designing complex gearboxes etc is really a very helpful tool. Also, to keep things "in line", especially when thinking of the spacing between axles that need to be connected with gears and so on and so forth.

That being said, I usually find that there is some mistakes, some things that aren't properly braced, or some things that interfere with gears etc when I come to building things in physical bricks. Most of the Technic functions are inside the models, and I find it easier to build a second model, implementing changes that are needed while at the same time trying to keep the initial ideas intact. All the while using digital tools (LDcad mostly these days) to work out how to fix the problems and find doable solutions.

All things concidered, a MOC is rarely perfect in its first iteration

[Lipko]

Working out all details just in your head is close to impossible (or at least for me).

Anyways, I usually design with LDD and with real parts simultaneously (I usually start in LDD, by defining the sketchy boundaries/wheel positions etc). I usually design smaller modules in LDD and try it with real parts as soon as possible (such as front, or rear suspension, gearbox, some other mechanism).

I sometimes start with real parts and improve the design in LDD, sometimes the opposite, depending on where I get stuck (with real parts or in LDD). I usually have several versions of the design in LDD (I make backup copies even in case of small changes), and have 2 (very rarely 3) real builds simultaneously, if my part inventory lets me.

My rule of thumb is to never prototype with the final colors, because I surely won't have enough parts in the final color to build the final model. Having no parts to keep to at least one copy means the whole real build have to be precisely modelled in LDD in order to make the final build with the right colors.

I rarely design on squared paper too.

This all sound nice and all, but I still fail to use some proper design methodology, all of this is just random trial-and-error design. And it's pretty sad because it's very ineffective, and I graduated as a machine designer...

[Karle]

It was interesting to read the thoughts on how each of you go about your design process. What books would any of you recommend for a Lego reference library?

[Anio]

Here are a few tips / guide lines :

- take ideas from official sets. There are A LOT of ideas in Lego sets. Building techniques of course. But analysing how complex problems are solved in a simple way is even more interesting.

- do not necessarily try to reproduce a mechanism as it works in reality, but try to adapt it to the Lego elements.

- think critical. Where big parts (PF components, Technic panels) have to be located, where an hinge/articulation is necessary, etc.

- structure your build. If your model turns into a mess, optimise it. Make it simple.

- do not hesitate to do and redo. A trial and error process is unavoidable to achieve a good model.

- use real parts rather than 3D software when you lack experience. It will enable you to "feel" the bricks, and see/learn how they react.

- define your building standards, and stick to it.

[Victor Imaginator]

When i walking alone with headphones and music and beer and good mood - i just thinking about almost impossible things. Like - where i should hide just right now if nuclear bomb falls into the center of city... And some of this unreal thoughts leads me to MOC ideas. I don't have a time to realize all of it, but when i have a couple of hours, i just follow this dreams, and some of it come true. But i don't know how it will work for huge complex MOCs)

Edited July 22, 2015 by Victor Imaginator

[piterx]

Hey all just seeking some input. I have started disassembling some of my sets here and there to make modifications to them. Using the existing designs and functions to gather techniques for making my own MOCs. Redoing the suspensions, making lifting mechanisms, and changing the steering. I have toyed with the Lego Digital Designer but have not ever completed a design.

What are some of the methods y'all use to create your MOCs? Do you just build and the final product develops itself, or do you work out all the details before the build starts?

some good southern rock and pieces spreaded all over the desk are the only thing i really need... sometimes i use ldraw to check proportions before i start building but without pieces in my hands i wouldnt be able to do anything :P

[Rishab N]

I'm a very novice MOCcer and have always wondered this. Thanks for making this topic

[Graydingo]

Trial and error. Hours and hours of it. It's a crazy complex self made puzzle.

[Paul Boratko]

You can't go by digital designer because Technic parts are not all true and consistent with each other.. And even though it seems that a model should work, that may not always be the case... Unless like Lipko said, you are using both digital and real at the same time...

I build by trial and error...

[dr_spock]

A vision comes to me in a dream and then Trial and Error.

[Lipko]

So trial and error design is pretty common. It's somehow very different with real machines. You have a task, you sketch up many concept variants and/or do some benchmarking (look for existing solutions and check if there's an applicable one), you have materials to choose from and usually it's quite straightforward to design the parts needed to achieve those functions in under the given constrains (I'm talking more about special purpose machines than commercial machines, which require tons of optimizations and manufacturing itself is a huge beast).

With Lego, you have essentially one material (a pretty weak one), a limited set of parts, and that's it. No matter how simple a real life solution is, if there are simply no suitable parts to reproduce it.

A sequential gearbox is a pretty good example. After months of trial and error, something like 4 fundamentally different concepts and 15 final variants, I still couldn't come up with a reliable solution which is compact enough to fit in a 1:10...1:9 scale car, and doesn't rely on the driving ring sliding on a smooth 2L connector, which was considered an illegal technique last time I checked (I tried with the new 3L system, and the force it takes to engage the driving ring and the hysteresis (the point it gets into/out of neutral position is direction dependent) plus the backlash in Lego systems frequently resulted in both driving rings remained in non-neutral position).

In real life, you have a selector shaft with properly shaped grooves to guide the arms engaging the driving rings (1 shaft + 2 parts per speed); plus the ratcheting system which is basically some pins at the end of the selector shaft, and a special shaped part to grab the pins, plus a spring (2 parts).

Edited July 23, 2015 by Lipko

[aeh5040]

i just thinking about almost impossible things. Like - where i should hide just right now if nuclear bomb falls into the center of city... And some of this unreal thoughts leads me to MOC ideas.

I am looking forward to seeing Victor's life size working fallout shelter MOC...

Once I have the idea for a MOC, I usually start by trying to get the hardest / most complicated bit working. (E.g. a gear box, or an unusual mechanism.) I do lots and lots of trial and error, sometimes working on squared paper to get the layout clear.

The many possible uses of modern technic pieces always surprise me. Often when I'm stuck a particular point, I'll browse other people's MOCs, or even just sort through my own pieces, until I suddenly realize "that it is the perfect piece / combination for the job".

Edited July 23, 2015 by aeh5040

[Jurss]

I mainly work with real parts, by trial and error.

I start with MOCs main idea - mechanism or body shape, and then i build body on mechanism or mechanism inside body.

When i go to bed, or driving form home to work or back, i think, what to improve or hove to solve something in that thing, what i had built until that moment.

The many possible uses of modern technic pieces always surprise me. Often when I'm stuck a particular point, I'll browse other people's MOCs, or even just sort through my own pieces, until I suddenly realize "that it is the perfect piece / combination for the job".

+1 . Sometime i just see - o, i have also this thing :)

[Cumulonimbus]

As an industrial designer by profession, my MOC process is structured as a any other design process I undertake and consists of distinct phases:

- Ideation phase: exploring the possibilities of a MOC or MOD idea. I often sketch on paper for this, because it is the quickest way to “write down” thoughts and possibilities. I have dozens of pieces of papers laying around with half ideas and inspirational drawings which once will make it into a MOC/MOD (I hope). In this phase, I also search for reference material, such as photo's, technical drawings and videos of the real thing and think about what level of realism I would want and which aspect I would be happy to compromise.

- Proof of concept: a quick test of a working principle, mechanism geometry and/or proportions. Here, I always resort to bricks to get a feeling for friction and play in a mechanism and rigidity in a (sub)structure. I often build several solutions for the same problem simultaneously and compare then before choosing one or a combination of several.

- Concept phase: after selecting the best ideas and solutions for sub-problems, I start combining them in a concept. In this phase I use LDD extensively because there are no part-limitations and it is easy to copy-paste parts of a build to make iterations. The end result of this phase is a complete, functional, real life build, but often not in the correct colours yet and most of the time with a lot of room for improvement.

- The final step is a complete rebuild, were I reduce the number of parts, improve and simplify the structure, choose a color scheme (which sometimes requires ordering new parts). I go back and forth between LDD and real bricks here.

A final note: In my experience there are two approaches to design a Technic creation: inside-out or outside-in. For the first, I start with a mechanism I want to build, for example 3-axis airplane controls, and once I have a concept which is feasible, I design the rest of the vehicle around it. Here the scale of the vehicle is determined by some critical components which can’t be reduced is size of complexity (like a helicopter swashplate).

The second approach is outside-in, where the looks and scale of the model is leading for the structure and mechanisms inside. This is often how I MOD official sets: I want to keep the appearance of a TLG set, but radically change mechanisms or structures beneath.

[Victor Imaginator]

I used another method of generating ideas too - just connecting pieces in random order while i smoke at my kitchen, 5 minutes every hour.

[Lipko]

@Cumulonimbus:

Do you see fundamental differences (harder/easier) between designing Lego models and "real" machines?

Maybe I'm just not a good mechanical designer, but I find it harder in some points to design Lego models than real machines. These points are concept planning and detailed implementation (which are actually the two most main aspects of Lego design...).

Or maybe I'm just not patient enough to do proper planning.

(and I find Lego and real machine design both significantly harder than programming, maybe I took the wrong profession).

Edited July 23, 2015 by Lipko

[zver]

I don't use any lego CAD software. I use computer on my work and I want to have a rest from it while lego-building :)

Several years I've experimented with different 4x4 suspension types.

The development process was the following.

1. Thinking out the idea of front suspension mechanism.

2. Building a prototype of suspension and the chassis just to test how suspension works in practice.

3. Running some out-door test-drives.

4. Fixing wicked places and rebuilding the prototype.

Repeating steps 2-3 unless the prototype works good.

5. Building other model parts.

6. Final test on Lego Truck Trial competition :)

-

Some principles I follow:

- the good mechanism is the simple mechanism

- the less parts you use the better

- the mechanism strength should be enough for comfortable using model in it's scale environment

- don't copy other's solution. Catch the idea and make your own implementation

- keep in mind resistance of materials theory and mechanisms theory if you studied any

At last the best way of construction - is YOUR OWN way of construction.

Edited July 23, 2015 by zver

[Cumulonimbus]

@Cumulonimbus:

Do you see fundamental differences (harder/easier) between designing Lego models and "real" machines?

That is a good question, I would say that although the design process can be very similar, designing real machines is much more challenging, especially if that machine will be series produced: In real life you have (almost) limitless design freedom which makes it much more difficult to make good choices: materials and production processes, logistics, budget, market needs, patents, legislation, and many more aspect all have to be taken into account and can have a profound effect on the final design. In this perspective, the fact that you are bound to Lego parts (if you are a purist) really restrict the possibilities and in most cases this is a good thing, since you can focus on the looks or the functions without having to worry about all the other stuff.

On the other hand, if you simply look at the construction, the Lego parts do have considerable limitations. The huge design freedom in real life also means that there are many more options to solve any given problem. But you do need much more knowledge to be able to make good a decision in this ocean of possibilities.

I have a theory that experienced Lego builders have a “database” in their heads of Lego parts with their possible uses and a list of best practices how these parts can be combined to solve common problems, such as bracing a structure. This database is either consciously or subconsciously used constantly go back and forth between the possibilities of a part and the design problem at hand. That is the reason why it is important, as mentioned above, to keep looking how co-AFOLs and TLG designers solve design problems with these parts, so you can keep adding to your personal database. This is exactly why I love Lego, especially Technic. The constant “tension” between the restriction of the parts and the desire to build more complex/life like/compact, and the Eureka moment and the euphoric feeling when all piece of the puzzle fall together.

And of course trial and error is a huge part of any learning curve. Happy building!

EDIT and PS: The human mind seems to be at its most creative when faced with restrictions. The company I work for challenges us to come up with 20 different solutions for a critical design problem. The first 5 or 6 are easy, but after those it’s very hard to come up with novel solutions. However, once triggered, your mind really can come up with 20 solutions and the last one are often the most innovative.

Edited July 23, 2015 by Cumulonimbus

[Lipko]

Another problem for me might be the fact that I don't build other's MOCs. I only built Crowkillers' Vampire. And building others' MOCs (because they usually contain more advanced stuff than official sets) is a very important learning process. At least you will learn what's good enough, and that you might be over-engineering and over worrying your build.

Maybe if I would have built MOCs with sequential gearboxes, I would have learnt that if a gearbox works 90% of the time, than it's good enough (or not). Building the Vampire taught me that my models are rigid enough, and that the parts of my models (especially the body) are rigid and defined more than enough and that I could be more tolerant towards my models in regards with stiffness.

The reason I don't build others' MOCs is simply lack of time and parts.

Actually, MOC reviews would also help, so I woluld love to see more of them.

[Thirdwigg]

I use a very similar process as @Cumulonimbus.

• Idea: I pick something to model, or and idea that I want to work on. I make some sketches of placement of majors sections, and of ideas for difficult parts in a small notebook I keep with me (it's neat to look back on all the ideas I wrote down, and see how they were finalized).
  
• Proof of concept: I work in real bricks, and work out some tricky details early.
  
• Placement: I build a rough chassis in real bricks with all the hard parts placed, and then I start running axles, gears, and gearboxes.
  
• Rebuild: I then rebuild a second model coping the first, with better structures, correct colors, and necessary improvements. Sometimes a MOC takes two or three rebuilds.
  
• Finishing: here I work on visuals, and other final steps.
  

The note of building outside-in and inside-out is a great vocabulary for a building process, and I suspect many of us could fit into these two methods. I generally build outside-in as many of my MOCs are determined by a scale, but find inside-out very liberating. My ATS and Typhoon were built outside-in, and the OCTAN Air Racer and OCTAN F1 were built inside-out. I guess I use both styles, and find myself alternating between both in many of my MOCs depending on what I find more stimulating at the time.

I find LDraw/LDD tedious, though I could see how it would make my building more efficient.

[Graydingo]

-

Some principles I follow:

- the good mechanism is the simple mechanism

- the less parts you use the better

- the mechanism strength should be enough for comfortable using model in it's scale environment

- don't copy other's solution. Catch the idea and make your own implementation

- keep in mind resistance of materials theory and mechanisms theory if you studied any

At last the best way of construction - is YOUR OWN way of construction.

These are all gold.

[aeh5040]

@Cumulonimbus:

Do you see fundamental differences (harder/easier) between designing Lego models and "real" machines?

Another obvious difference is that it is WAY quicker to turn an idea into physical reality (at least a prototype mechanism) in Lego than any other medium I know (even other toys like Meccano). In particular, trying out a small variation can take only seconds. It means that hands-on trial-and-error design is a far more realistic option than elsewhere.

By the way, I am definitely in the inside-out camp.

[Blakbird]

Another obvious difference is that it is WAY quicker to turn an idea into physical reality (at least a prototype mechanism) in Lego than any other medium I know (even other toys like Meccano). In particular, trying out a small variation can take only seconds. It means that hands-on trial-and-error design is a far more realistic option than elsewhere.

This is exactly why LEGO is used as a medium in so many learning institutions. Particularly in robotics, the ability to quickly mock-up and test your idea is invaluable. For learning any mechanical prinicple, seeing it in practice is infinitely better than reading about it, and building and holding it with your own hands is better than seeing it. For example, I was aware of the basic principles of a differential for many years, but I didn't really thoroughly understand it until I saw my first LEGO version. In a few seconds of playing with it, the function becomes obvious.