Nice. I was thinking of animating it, but at 0.5 secs/frame on my PC that would be a slide show. Those transforms are rather expensive.
–
Sjoerd C. de VriesFeb 17 '12 at 7:21

2

The slowness and behaviour of GeometricTransformation and related stuff is something that forces (presumably many) users to write their own fast transformation routines. I´d like to see direct fast transformations on 2D and 3D objects out of the box.
–
Yves KlettFeb 17 '12 at 8:18

3

I've never seen Mathematica but this is just stunning! What you all can do with so small pieces of code!
–
TomasFeb 17 '12 at 11:30

By now I imagine this question looks strange to new visitors. The original title was "30 days running and excellent statistics on Area 51, congratulations to all participants!", and was posted to celebrate the success of the then newly created Mathematica section. However, that was seen unfit by the moderators, so it underwent some changes.
–
DavidNov 6 '13 at 14:22

6 Answers
6

How can this code be improved, for example, by including shadows, raytracing or the effects of gravity to make it more realistic?

I felt that this question deserved an answer. The one I describe here is to create a set of confetti "agents" that respond in quasi-physical ways to external forces and "know" how they should be displayed.

It is handy, and a whole lot of fun, to do this in an extensible and easily modified way, because you're going to think of loads of improvements to make once the framework is in place. It helps to have well-documented code--there is less cognitive burden on you, the programmer, when modifying it--so I hope you won't mind that it's somewhat more verbose than usual.

By taking a top-down approach, this code practically writes itself. Start with the agents themselves, the confetti:

I have endowed a single "confetto" with information about how to draw it (symbols), its present location and momentum (location and momentum)--that is, its physical state--, and some internal state information (frame for the orientation and angular momentum for its rate of change: you will see the little pieces of paper rotate as they move). That should be enough for rich simulations. A simulation will proceed by applying update over time periods of short duration to update the state of each object. This will rely on two other methods: force to compute forces and display to draw an object in its current state.

Update calls rotate to change the orientation, so let's take care of that detail now:

(You can probably do this faster with quaternions, but this is good enough for a start.)

There are many ways to display a confetto, depending on what kind of object you would like it to be. For instance--this will be relatively fast and is useful for testing--just draw a point as a visual placeholder:

To emulate the other examples offered in this thread, and to show how the angular momentum works, let's view each object as a square. The frame attribute of a confetto determines its size and orientation. At the same time we draw these objects, we also draw their "shadows," provided they are in front of the coordinate planes. Here, then, is a fancier version of display:

Notice that none of this graphical work needs to get done except when we want to look at an object. Thus, we could create a long simulation (using update) but call display only at key times, or when interesting things happen. Separating the physics from the graphics is a good strategy.

Later on, to help the eye make sense of these shadows, we will want to have some fixed "walls" on which the shadows appear.

Update invokes a "force" function to change an object's momentum. Newtonian gravitation on a flat earth is especially simple:

gravity[location_, frame_, momentum_, time_] := {0, 0, -1}

In general, the forces applied to an object depend on its location, the time (for time-varying forces), the object's location, and the situations of all other objects. Handling the latter is complicated so I have not built it into this framework: only external forces are applied. Here is a more complex example of what we can still do despite this limitation:

Note, though, that the force on a confetto depends on its orientation and its momentum: this attempts a realistic simulation of what wind does to a small slip of paper.

You might like to write code for other kinds of forces. Can you blow one smoke ring through another and then turn it green? :-)

We're all set to go! Let's make some confetti. I will place them all at the same location with the same orientation at the outset, but endow them with randomly varying momenta and angular momenta so that they all do different things:

(You could anti-alias the graphics here if you like. I find that the computation takes too long, so I have left it out.) Through is a handy way to create combinations of forces: this gives you a manageable way to handle extremely complex combinations of additive forces.

That was a 30 second calculation, by the way: not fast, but not too shabby.

To keep the file size down, I have exported only some of these frames:

A little bird told me that the admonition "the more, the merrier" is quite applicable to the subject of confetti; I thus decided to see if I can do an animation with three confetti launchers instead of just one. I also wanted to experiment with Yves's enhancement of using confetti pieces with varying colors, so I added that enhancement in the following code as well:

Elaborating on Mr. Wizard´s answer, a quicker way to generate and render the polygons is to define your own roughshod transformation functions and use the multi-primitive syntax for Polygon together with random VertexColors. The resulting graphics is rendered way faster and is much more responsive to mouse interaction:

The inbuilt RotationMatrix command is very powerful, but for simple transformations using a dedicated function (which was derived as assumed above by simplifying the output of RotationMatrix[theta,{x,y,z}] is much faster. That is a handy feature of Mathematica: using a symbolic solution and whittling away the stuff you do not need to tune for performance.
–
Yves KlettFeb 17 '12 at 15:27

Mathematica is a registered trademark of Wolfram Research, Inc. While the mark is used herein with the limited permission of Wolfram Research, Stack Exchange and this site disclaim all affiliation therewith.