The last post was all about controller ports, but didn't get into what a controller is, why you would want one, and how it fits into a light display. Now seems like a decent time to cover that and, more broadly, the various components which you can find in a moderately-sized display. So let's get into it!

To simplify things, you can think of a light display as equivalent to a person playing a piece of music on a piano. Or a person running a play in a sport. Or a person dancing. I play music, so I'm going to stick with the piano metaphor. With that in mind, let's start with the music.

Composition

At the very beginning, someone composes a song. The song can be simple, or it can be quite complex, but it will take into considerations the limitations of the player and of the instrument and may go through many iterations before it's just right.

This is the sequencing software used to generate the sequence which is later played; xLights is a common program and has been discussed here before. Taking into consideration the design of the layout, the number of lights, where they are placed, etc., you program them to make patterns animated over time, the end result being a file which can be passed to the next step.

Instructions

Once a song is composed, the composer writes down very detailed instructions on how to play the song, using a notation familiar to musicians; this is known as sheet music. From here, the sheet music can be distributed to musicians who wish to play the song themselves. They may change it a little based on their own interpretation of the song, add their own flair, modify it to match their capabilities and instrumet, but the general idea remains.

When you save a sequence in xLights, you end up with a sequence file which serves the same purpose. This can be distributed to other people who can then use it in their own display. Of course, you can modify the sequence based on differences in display, preferences of colors or timing of patterns, or because you felt like doing something different with the megatree, but the base sequence will remain.

Playing

Once a musician has the sheet music, she reads through it to get a better understanding of how to play. While reading it, her eyes and part of her brain are translating the notation which is written on the pages into sounds, intensity, patterns, and chords, and is also starting to get an idea on how to physically play it. When she decides to sit down at the piano, an additional part of her brain starts to tell her fingers, hands, and feet how to move in order to recreate that which is written on the page.

Just as there are two things going on in the brain, so there are two different components in a light display. The first component is a player, probably something like a Falcon Player, which translates the sequence file in the previous stage into some form of meaning. The second component, picks up that meaning and starts telling the lights how to flash. This component is called a controller, and the one I'm using is a Falcon F4V3. All the lights are plugged into the ports on this controller (or an extension board with differential receivers; kinda like having a brain in each shoulder as well as one in your head) and all the on/off/color change information for every light is distributed from this component.

Blood and Nerves

In order for our musician's fingers to move, her muscles need two things: commands on how much and when to flex or relax, and energy to power the muscle's movements. The commands are sent from her brain to her muscles by way of her nerves, and the energy is contained in blood moving through her blood vessels.

Both of these jobs are done by wires in our lighting display. The information about how to light up is sent via data or signal cables which end up connecting to the controller discussed above. For power, DC voltage is needed to make the pixels actually light up. In a smaller display, this can come from the same port in a controller, but is likely to come from a separate power distribution board, which we'll talk about next.

Power

In our musician's body, blood takes energy (in the form of glucose) and nutrients around the body, among other things preparing the muscles for activation by signals from the nerves. While many different parts of the body can affect the blood (lungs add oxygen, small intestine adds glucose and nutrients, etc.), the heart gets the credit for pumping the blood all around the body, distributing it to everywhere blood needs to be.

A power supply and, potentially, a power distribution board do the work of providing power to the lighting display. While there may only be a port or two used on a controller, we may have many distinct wires from the power distribution to the pixels due to the need to do power injection. The supply, distribution board, and wires are designed together to ensure that enough power gets to all the pixels which need it.

Instrument

Finally, we are at the point where the audience can appreciate the music our musician is playing. The fingers are controlling the piano, pressing down the correct keys as loud and for as long as the specifications say, creating music which comes out.

Of course, the last part of our lighting display is the most obvious one: the pixels themselves, arranged into shapes or outlines. Using the signal and power which are fed in, they light up different colors tens of times per second, enticing people to stop and watch, to oooo and ahhhh.

Summary

Like a musician, our lighting display is very complicated, but with a fairly reasonable number of understandable components. Hopefully this has been a helpful view into what goes into a light display and helps take some of the mystery and scariness away.

Building props that will be powered by a controller like the Falcon F16 is as easy as attaching pixels to a structure, connecting that string to the controller, connecting the controller to power, and boom; you can do the test patterns on the controller!

Well, unless you want to use more than a certain number of pixels in the run, in which case you need to add more power somewhere along the line.

Um, also if you intend to power more pixels per port than the 5A fuse allows.

Or if you just have more pixels than the port can update per cycle.

Let's look at what's going on here.

Light displays like the ones we're building are fairly complicated electrical circuits, and like any circuit, there are limits to their capabilities. For the purposes of this post, we'll be looking at only one of these circuits, one string of lights coming from one port; let's call this a run.

Some of the things which limit a run are the same as with other circuits: fuse(s) on the circuit (there's usually one built into the board per port), wire gauge, and wire length. On the Falcon F16, the ports have a 5A fuse, so we can't pass more current than 5A through this run without blowing the fuse. Wire gauge and length is.... complicated, so we're going to ignore it for the time being.

For typical LEDs, the amperage of each RGB pixel is approx 60mA, or 0.06A. This suggests that we can run about 83 pixels on each port, after which point we risk blowing the fuse on the board.

This is where things start getting.... weird. If you plugged in a string of 83 pixels and put them to full white (100% brightness to each red, green, and blue pixel), you'll notice that they look fine... up until around pixel 50 or so, at which point, they start taking on a pinkish hue. Virtually nobody would consider the color the 83rd pixel is emitting "white".

The reason for this dimming is because of a phenomenon called voltage drop. As you go down the line, each pixel consumes a little bit of power, which reduces the amount available for each pixel further down the line. This is fine in the beginning as each pixel has more than enough power to work with; a 5V pixel will work fine down to about 4V, for example. After a certain threshold (somewhere around 50 pixels), the pixel is unable to fully power all three LEDs, and thus they each have a lower brightness. There's a bunch of charts and models you can look at to get a richer understanding, but all you need to know is that this is a thing.

So that's two limits: how many pixels a port can provide power to (83 or so) and how many pixels with good color rendering a port can drive (50 or so). Let's assume that neither of these is a problem. We'll just avoid physics and say that any number of pixels can be powered without melting the board, and further assume that voltage drop is not a thing. We still will have limits to how many pixels a single port can drive, but this time it's how many can be updated every frame.

"Frame" is an animation term, hearkening back to the French "framêz" which means I'm kidding I did literally zero research into the history of this terminology. I'm pretty sure it's from photography (a photograph is a frame contained by the borders of the photo) and then was adopted by movies, which are just 24 images per second being shown to you to give an illusion of moving pictures. In animation, particularly in computer animation, it's a moment which is frozen in time, where some controller or artist has defined exactly what the display should look like for that very brief moment.

This is how pixel displays work. Many times per second, the controller tells every single pixel what color it should be, waits until the next update time, then tells every single pixel what color it should be again. Frame rate simply means "how many frames are shown over time" and is typically measured in frames per second. Refresh rate is directly related to this, but it typically describes how much time elapses between each refresh (frame) of the display and is typically measured in milliseconds or thousandths of a second. Common frame rates are 20fps and 40fps; the former has a refresh rate of 50ms and the latter has a refresh rate of 25ms.

Back to ports. Each port can only update a certain number of pixels in a given refresh rate time period; this is due to each pixel taking a tiny bit of time to take its portion of the message and pass the rest down the line, the speed of light (how fast the signal moves through the wires to the next pixel), and built-in overhead on the controller to determine what the next frame is going to look like. My controller (Falcon F16V3) can update 1024 pixels per port every frame, but only when running in 20fps; if I want 40fps, I have to drop my pixel count to around 600 pixels since the controller won't be able to keep up.

Fortunately, we can solve for two of these three main limitations. We can't do anything about the maximum number of pixels a single port can update; that's physics and computers and stuff, and it's pretty damn impressive that a controller can update 600 different tiny microcomputers (which is what LED pixels really are) across my front yard 40 times every single second. However, we can fix the much more restrictive limits of 50 pixels and 83 pixels by using power injection, and we'll get into that with the next post.

One thing I've found very helpful when building props is to write down various notes about wiring. Sure, there are going to be some rules or guidelines you should follow (e.g. DC+ goes to DC+, how to manage power injection, etc), but what wire colors are, what connectors you use, whether the male plug is on the incoming side of the prop or on the outgoing, etc. are going to vary based upon your preferences, the types of components you buy, etc.

To add to the difficulty, sometimes this stuff is not very well documented. For example, for the pixel strands I bought there is no documentation as to whether the signal goes from the male plug to the female plug or vice versa; you have to figure it out on your own.

Thus, writing these things down is incredibly helpful. By doing some preliminary thinking and design work, you can simplify the process of wiring and reduce the possibility of bad wiring quite a lot.

You won't have to go back and figure out what you've already done in order to try and match it. It's annoying to have to get a fully wired and functional prop out of storage to figure out which direction the current is flowing, which direction the plugs should go, etc. Further, if you always use the same practice for wiring things up, your system is more flexible and open to changes without having to rebuild connectors, etc.

At a minimum, these are the things I would write down:

• Which wire colors carry what type of current. Do this for pixel strands, other prewired props which need to be connected, signal cables running from the controllers to the props, and power injection.
• What direction connectors face. I find it easiest to think of this as "incoming" and "outgoing", but it's also commonly referred to as "upstream" and "downstream" (controller/power source is always "outgoing" or "upstream"). As an example, if you buy the Ray Wu connectors, it's common to wire the female plug (holes instead of prongs) to the controller connectors which plug into the board. The direction doesn't matter as long as it's consistent.
• Which wires go to which connector poles. This is useful mainly for power injection wires, but it really depends on how in-depth you get with your wiring.

That's seems like very little, but do each of these for each of the wire types and it starts getting to be a bit of info. However, I promise that you will appreciate having this when you go months between building props and have completely forgotten which way everything goes.

For me, it ended up looking something like this:

As for that last bit about not connecting DC+ to signal cables? I'll get into that soon when I cover power injection.

In my post about model grouping, I mentioned that one can have nested groups of models. One might want to do that if there are several groups of one type of model, then another group which has all of that model. I found an issue with how this works and am going to put a big caveat on using nested groups.

For example, on my house, I'm planning to have five stars on my garage and five stars on my house. I would like to be have the option to control them separate to each other, so I have "Stars - Garage" and "Stars - House". However, I also want to control all the stars together, so I want "Stars - All"; that way any time I add a star, I just add it to one group (say, "Stars - House") and anything group that has that group nested (say, "Stars - All" or "House - All") will automatically know about that new model.

However, this has a limitation during sequencing. When you apply effects, there is a "Render Style" option. In this, the default is to use all of the models in the group as a broad canvas onto which to apply the effect.

However, you also have the option to tell it to apply the effect to each of the models under the group (one such value is "Per Model Default"). This is useful when you want to have, say, the same starburst effect on all the stars without having all the stars on the timeline individually and applying the effect to all of them. I touched on the differences in the model grouping post. The end result is the same as if you'd applied the effects individually, but the same exact effect will be used and kept in sync.

The limitation is this: if you have nested groups, the groups which are nested will be rendered as a group instead of the individual models. Here's an example using my "Stars - All" group (hey now, I'm an All Star...). For illustration purposes, I have both individual models and a nested group within this group so you can see the differences.

This is using the Default rendering on the top-level group. As you can see, the explosion goes out from the middle of the group and passes through all the stars. Let's see what happens when we change the Render Style to Per Model Default.

That's interesting, right? As you can see, each of the stars on the left bursts within the star itself, while on the right, the burst renders across all five stars. That's because the stars on the left are added to the group individually, whereas the stars on the right are added to the group within a nested group.

So we come to the crux: I am going to go back and, in many cases, change my groups to hold only models. In the long run, it is going to be a bit more maintenance as I add new models, but hopefully that'll be only like once or twice a year. However, with things on which I intend to never use Per Model Default rendering (e.g. my EVERYTHING group), I'll just keep with the nested groups, because damn are they convenient!

My last post about sequencing went hard in the paint on the why but didn't really touch on the how. As you may recall, this blog is more of a record of what I did or am doing instead of a how-to. Thus, the lecture should be followed with lab work. So roll up your sleeves; we're gonna jump into sequencing!

First, choose a song. Any song will do, but it will be easier if it's a song with a regular beat that doesn't change tempo. I'm going with Get the Party Started by P!nk . Feel free to question my taste, but I like this song.

Download the mp3 to your computer, and please do this legally, especially if it's a holiday song. I'll have another post about directory organization soon, but really quick, inside my xlights directory, I have a directory called "songs" and, within that, a separate directory for each of the songs that I am sequencing; I put the song, videos, and save the sequences there. This may not be best practice; we'll find out later though, and it seems to work so far.

To create a new sequence, open xLights, navigate to the Sequencer tab, and click "New Sequence".  It's the yellow page lookin' icon in the upper left. You can also find it in the "File" menu, or using the keyboard shortcut ctrl+n (probably cmd+n on Mac, but I haven't installed xLights on my Mac yet);

First thing you'll get is a dialog asking if you want a "Musical Sequence" or an "Animation". The latter is just pretty light patterns which aren't set to music; you can totally do a show using this, use animations between sets, on holidays where there aren't as many songs, if you have only a few lights, etc. For this, we'll be syncing with music, so choose the "Musical Sequence" option. (Note; there are other tabs on this dialog; we're ignoring them as you don't need to play with them) You will be prompted to select a song; find the one you downloaded and open it.

Now you'll be asked to select either 40fps or 20fps for the framerate (the millisecond number in parenthesis are how many milliseconds each frame is allotted). Well, you can define the fps manually using the "Custom" button, but 40 and 20 are fine values; I wouldn't use Custom unless you have a reason.

40fps will give you smoother gradations and transitions between colors, along with being able to more closely time effects with the beat in the song. However, it comes at the cost of file sizes which are twice as large which can be a bad thing. From what I've heard, 20fps is a fine option unless you know that your hardware (pixel controllers, animation player, network gear) can handle the larger file sizes. One example is that, if you choose to use 40fps, you have a limit of 680 pixels per port on the Falcon controllers, as opposed to the possible 1024 which each port can handle at 20fps. I've spent many days (over a week?) diving into this and planning accordingly, so I'm choosing 40fps.

Finally, you are prompted to select which models you want included from the start, then you can either "Quick Start" or go through "More Options". For the models, you can always manage which models are visible/controllable in the sequencer after the fact; I generally choose to start with empty because it's easier to add a dozen or two groups/models than to remove three or four dozen models I'm not going to use individually.

I genuinely have no idea what is under "More Options"

... clicks through

Hmmm, import sequences from other programs (or xLights), edit the metadata, import timings. All stuff we're not going to super worry about for this sequence. Cool, so just click the "Quick Start" button.

Okay! Now we do something which everyone online says to do: as soon as you open a sequence, save it right away; the reaosn they say this is saving kicks off a rendering pass. It will do nothing in this case but save the sequence; however, it's good to have something to quick save to; thus save it (I save it right next to the music file in my songs directory).

Awesome, now we have a blank slate!

Coming up in the next few posts, we'll get into managing the models which we are going to control in the sequencing pane, set up timing tracks to better syncronize and lay out our effects, then start putting down some effects. Exciting stuff!

So, not long after I'd designed the layout I thought I'd be happy with in xLights, I went ahead and ordered the pixels. This can be an interesting task, so I'll walk through what I did.

Caveat: you can likely get them cheaper than I did, but I am fortunate enough to have wiggle room in my budget. I'll mention some things which other people say they have done, but I can't vouch for them, though they do sound reasonable.

Caveat 2: I'm not endorsing or sponsored by any of the vendors I'm linking to here. In fact, were it not for my desire to give credit where it's due, I probably wouldn't include links, just steal the pictures. I may or may not be using the products I share below; I don't know. I haven't gotten that far.

First thing to do is to decide how many pixels. On the rooflines and straight runs, I opted to do a 2" spacing which, judging by my existing attempt at pixel lighting, is fine. It's not excellent, but it's fine. When installing, I'm planning on using some mounting material which will allow me to go to 1" spacing if I desire, but that sounds a bit like overkill to me. A couple of examples are below. After I did all the calculations, I determined I'd need 2,116 pixels for the outlines.

I also used some retail props (the stars, arches, and spinners) to estimate the number of pixels for each of those. Of course, this is going to vary from place to place and what you want in yours, so do a bit of research (google "holiday coro", "christmas light rgb props" and the like), find some you want, and look at the pixel count (in quite a few cases, the vendor has custom models for xLights; there will be a future post about that). The props ended up taking 2,788 pixels.

Finally, there was the megatree. These are somewhat easy to calculate as long as you know how dense you want it. I want more of a beginner's megatree (well, I want a huge one, but I'm starting with a smaller one to see how it goes), so I'm allocating about 800 pixels for that (50 per string, 16 strings around the tree; this is a fairly common configuration).

Grand total: 5,704 pixels in my xLights configuration.

Now that I'd decided on a number, I started reading the forums (mainly auschristmaslighting.com, even though I'm not in Australia; it's incredibly useful) and found that the three most common vendors are eBay, Amazon, and Aliexpress. Amazon is reliable and fast, but relatively expensive. Aliexpress is reliable and relatively inexpensive, but can be slower, eBay can be quite a bit cheaper, but you're sacrificing the reliability. I opted for Aliexpress.

Now, on that forum, when it comes to purchases, Ray Wu's store will come up a lot. This is a highly used vendor in this hobby and they have a ton of supplies for pretty great prices. However, I wanted to see what else was available because Aliexpress is HUGE (plus roughly 30% of the cost would have been shipping, and being a Prime member for years, I've developed an allergy to paying for shipping).

I ended up buying from another vendor because I was able to get 1,000 pixel lots pretty inexpensively. I did find one vendor with free shipping, but paying for shipping ended up being cheaper when I bought the lots. A note on this a bit later. Any rate, the 6,000 lights were around $950, which is $0.16 per pixel; I understand that to be reasonable, though I have heard of others getting them for about half that. I placed my order on the 30th of Dec, and I received the first of two boxes today, Jan. 6 (I have a tracking number for the other box and it should be here soon). Not bad!

Oh, I totally didn't talk about voltage in this post. I should have. I will in the next post.

So, I'm happy with my pixels and can't wait to get a controller and some power supplies so I can start turning them on and stuff. I'm still trying to figure out what exactly to do for props and mounting, so that will have to come later. Full update when it happens, though.

Any rate, two things which came up as credible options. First off, apparently you can contact vendors on Aliexpress (Ray's name was brought up for this) and ask for a quote for the number of pixels you want. From what I understand (I heard this after I placed my order, so I didn't get an opportunity to find out, though I will probably purchase another thousand, or two so I may try then), he will often reduce or waive the shipping fee.

Since in my case, shipping would have been around $300, that savings is nothing to sniff at.

Second credible option I've heard: group buys. If you are getting into the hobby, I would suggest finding a forum (or forums) to join, then seek out folks in your area. There are (were; thanks COVID) meetups all over the world at least a couple times a year, and there can be vendors at these meetups, instructional sessions, demos, etc. But one other thing which is not uncommon is arranging group buys in order to get large bulk discounts; if 10 (or 50) people pool their orders and go through one vendor, they're likely to get a savings on cost and on shipping; then the items are distributed at the meetup.

Any rate, that's the cut and dry of how I got my pixels. Next time, I'll go into pixel voltage and how to decide what strands will work for you.

Pull up a cup of your favorite beverage and get cozy with the sequencing tab, because as far as I can tell (with my ~2 weeks experience in the hobby) this is where you're likely to spend most of your time.

At a very basic level, sequencing is the act of making the lights you've defined change color and/or brightness in a pleasing pattern. This is probably what attracted you to the hobby in the first place; sure all that wiring of props and building of controllers is impressive, but at the end of the day, those aren't super impressive without the blinky flashy.

One thing to note: sequencing is an art form, and I'm not just speaking metaphorically. As a sequencer, you are taking a certain medium (usually music) and an instrument (thousands of lights which can turn colors on demand), and enhancing the experience in some way. Different people can take the same layout and same song and come up with completely different shows, each highlighting some aspect of the artist.

Another thing to note: sequencing takes LOTS of time and LOTS of practice. Just as with any art form, as you learn how to control the instrument, you will find new ways to express yourself. What may have been a simple color wash when you first started out may morph into a ripple effect on top of a video of the certain color with some sparkles thrown in. Experimentation with the various tools will lead to experience, but experimentation (and experience) takes time. There are ways around that, which I'll touch on near the end.

So, what eats the time? "I'm only doing a show for a four minute song; how long could it take?" Of course, this answer varies. On the pragmatic side, it will take as much time as you give it. Using model grouping, and timing tracks (which I'll cover later; tldr they highlight the beats/measures/bars/notes of a song), it's not impossible to have a show sequenced for a song within ten minutes. However, this display is going to be very broad strokes; think doing a paint-by-number with a roller. This will work, and if you have a lot of lights, it may be impressive, but it won't necessarily be good or remarkable.

For a well-designed, good show you'll have to get into details, and adding details is going to take time. Going back to the paint-by-numbers analogy, we started with the "just use a paint roller" analogy. To get into the details, we start using finer and finer brushes. Maybe your first stab is like slopping patches of paint where they're supposed to go, but the picture is more recognizable than the starting state. Spend more time with a small brush, pay attention to the lines, and the picture is fully realized. Go even further, adding details which weren't specifically called for, and the painting starts coming alive.

The same concept applies to sequencing. It's really simple and fast to make all the lights flash patterns in time with the music; there's even a function in xLights which will just fill in a sequence for you. However, if you want the various elements to do different things, in sync with other elements, but complementing each other while using a pleasing color palette, changing that palette in order to emphasize the mood of the music... well, that will take some doing. There's a lot of fiddling with various different effects to make them just right, to have them hit the timing marks perfectly, to get just the right color combinations. The challenge comes in trying to not get too perfect, which is basically impossible.

However, the payoff is when you get everything together and it looks amazing. Put aside the little errors that you find, because every artist is their own worst critic. This is a very uncommon art form, and it is going to wow people, regardless of how perfect (or not) the show is. Enjoy the final result, the fruits of your labor, and come up with ideas for your next sequence, the next song. After all, there's always next year!

At the end of the day, if you get 100 people looking at your light show, a very small handful are going to want to look at, or even be capable of appreciating, the symmetrical way in which you spliced all the wires, the fact that you were able to save at least three solder points on each of the stars because of the clever way you did the power injection, etc. However everyone will be able to see, and came by to see, the show; the lights turning colors, fading in and out, turning on and off, in sync with music, they will enjoy it, and you will make their lives a bit better.

They want the same as you: the blinky flashy.

With the next post, we'll go back to our regularly scheduled programming, not this philosophy crap. I promise.

In one of my previous posts, I briefly mentioned groups when discussing building the models of lights. I wanted to go a bit deeper on this topic now because I think this is a super amazing thing for people who are lazy like I am.

First off, what is grouping? At a high level, the name is right there on the tin: you are grouping your models together with the intention of using them as a single model. Let me give you a simple example.

I'm going to apply a simple Butterfly effect to the stars on my roof in two different modes: individually, and as a group. First, let's see what this effect looks like when we put it on the individual models.

You get the same effect copied to each of the stars. Makes sense, right?

Now, let's see what it looks like if we group the models and then apply the effect to the group.

Much different, right? The effect has exactly the same settings in both cases, it's just been applied to different models.

Why would I want to do this? Well, when you apply an effect to a group, it has a more cohesive impact on the display. If you don't want to do a great deal of manual manipulation, using groups can drastically cut the complexity (and amount of time) of a sequence. Also, quite often you want all of a type of model to do the same thing at the same time. A very simple example of this would be to have all the stars blinking on the beat.

Now that we've covered the high-level what and why, let's get into the how. Open up xLights and go to the Layout tab. I'm assuming that you've added some models already, but if you haven't, you can go through some of my previous posts to get basic info on how to do this.

I'm going to show you how I put the stars above into a group. First, I highlight the models in the model list on the left. It doesn't matter what order you select them in as everything ends up alphabetical anyway, and you can move things around in the sequencer when we get there.

Right clicking on the selected models will bring up a context menu; since we're creating a new group, we'll choose "Create Group from Selections". If you're adding to a group, then you can use "Add Selections to Existing Group", but I'm not so we're not.

It'll ask you to enter a name for your group; you can put whatever you want, as long as it doesn't conflict with the name of an existing group or model.

And now you have a new group! I named mine "House Stars" because I'm creative like that. By default, groups will be at the top of the model list, before any individual models. Also, by default the model list is in alphabetical order, so it'll go A-Z groups, then A-Z models. Keep this in mind if you want to have certain models or groups easily accessible; I've seen people keep commonly-accessed ones at the top by using numbers instead of letters.

If you click on the arrow/carat icon to the left of the group name, it will expand and show all the models within. You may have noticed that on my stars, there is a carat on the models themselves; these are custom models which have models inside of them. We'll get into that a bit more in the next couple of posts.

If you select the group name, the info panel will have a whole host of new options and selections; I've only just started scratching the surface of this stuff, but the tl;dr is that you can tell the group how to behave as a model.

The default is to do the behavior I highlighted above; make it seem as if an effect is using all of the models as a single model. However, if you wanted to retain the individual model behavior (say, have a starbust on each model) but not have to apply the same effect to each model individually, you can control that here.

Another interesting thing about grouping is that you can add groups to groups. Coming from a software engineering background, I never like to do the same thing twice. Say I add a new star to my roof stars. Also assume I have several groups which contain my roof stars: Roof Stars, Stars, and Everything (all real groups in my setup). If I make up each of these groups with individual models, I have to remember to add the new star to each of those groups, and I guarantee I will forget to do that.

Enter nested groups. Just as you added models by selecting them, right clicking, and either creating or adding to a group, you can do the same things with groups. By doing this, you can easily build up groups which are automatically updated as you add models to the subgroups contained within.

If I add a Star11 to House Stars, any effect I have on House Stars, Stars, or EVERYTHING will start incorporating the new element the next time I render; same with any other groups I may have which include House Stars.

To summarize, combining models into groups can make your sequences far less complex, give you a quick route to an impressive display, and provide automatic updating capabilities. Thus, using groups is a very powerful tool and allows you to build more and more impressive sequences, removing much of the frustration you may experience using individual models.