Julian

For those of you who want to work on high-rise buildings, have you thought about doing variable numbers of floors? You could have one model for the ground floor, one model for a middle floor, and one model for the top floor or roof, and then constrain them together in the choreography with multiple instances of the middle floor model. Alternatively, the ground floor could be the base model, and all the floors above it can be action objects. You could make different actions to produce different numbers of floors.

Why does the alignment fall apart like that after a couple of bounces? Rounding errors?

That's the thing, I'm not using multipass, and the render settings are exactly the same in both versions. This camera has a 30 mm lens, so it's pretty wide angle already. I'd do that if I were animating the shot, but right now it's taking me 3 hours just to render one frame, and I think the total amount of time to render the layers separately is going to work out about the same.

You would need to add a decal containing three images: a bump map with black text on a white background to make the text look recessed, an ambiance map with white text on a black background to make it glow, and a color map with text in a lava pattern and an alpha channel that makes its background transparent.

For comparison, here's the rendering from 11.1i. The 12.0e rendering shows much sharper markings on the ship's hull, and the projection map for the cloud patterns on Jupiter is properly antialiased, but like I said, it takes over six times as long to render, and I don't know why.

This is an improved, higher resolution version of my 2nd place winning entry for the July 2004 Sci-Fi/Fantasy image contest. The original version can be seen here on A:M Stills. I've tried rendering this scene in both A:M version 11.1i and 12.0e. The rendering done in 12.0e, shown in this post, has much better quality image maps, but it took me over three hours to render it in 12.0e as opposed to 22 minutes in 11.1i. Can anything be done about that?

I'm glad people are still interested in this! Would this have something to do with the Mars image contest?

Are you using any Fresnel reflectivity on the paintwork? It might need some to sell the car paint look. You could also do what professional car photographers do and set up some light panels behind the camera to provide something to reflect. These would just be single rectangular patches with a gradient that goes from white at the top to black at the bottom.

Colin, what kind of material settings did you use for the paint job? Is there some kind of light box behind the camera that the body can reflect off of? Also, did you do anything special for the headlamps, or is it just chrome and refractions?

It looks like he switched to using raytraced shadows instead of Z-buffered.

If you want to avoid the particles falling upward as the plane descends, you have to make sure the velocity of the particles that make up the exhaust is greater than the downward velocity of the plane. (The units of particle velocity aren't labeled in the settings, but they're actually measured in cm/sec.) And if you're not using sprites, you should. You can use a pose slider to control the particle emission rate.

The moon seems to be receding away from the camera very slowly. Is this deliberate, or did you put in an extra keyframe?

You can find the files here in the Showcase forum.

Here you can download the star sphere model and associated files that I discussed in this thread in the WIP forum. Please read the README.htm file included in the archive. For the download, please see the Version 2 star sphere thread. (Earth not included.)

I've done one more animation test in which the camera zooms in and the stars shrink at the same rate. To try to save time, I rendered the stars with multipass and the TIE fighter with A-buffer antialiasing, and composited them together in After Effects. Here's one frame as the camera is zooming and panning simultaneously: (video removed) Immediately after this post, I'm going to make the star sphere model available to download in the Showcase forum.

Are you using 8-patch spheres or something denser to make the atoms? I'm not trying to toot my own horn here, but I once tried making a spacefilling model of a DNA molecule using 8-patch spheres for the atoms, and you can see looking at the hydrogens that the spheres aren't perfectly round:

It has a nice Chuck Jones look to it -- along the lines of "The White Seal" or "What's Opera, Doc?"

Does the raw material consist of molecules of ethyne gas? Did you use flocking to create the Brownian motion or something else? If the computer has 1 billion CPUs, does that mean each of the cubical units being assembled at the end is a transistor?

I thought there was something bothering me a tiny bit about the Man in Red getting kicked in the stomach too. I think I'd like to see them struggling on the ground for a few more frames before the kick happens. Also, I see the Man in Black's leg is stretched as he does the kick, but it returns to its normal length over two or three frames. Perhaps it would be better if it snapped back to its normal length instantly. Near the end, as the Man in Red is about to punch the Man in Black, the silhouette of his right arm as it draws back should be emphasized a bit more. The Man in Black knows he's about to get punched -- you might as well make it obvious for us too. Even so, this is an amazing piece of work and I love the job you've done on it. I'm anxious to see the finished product.

Beveling means rounding off the corners, like the primitives in the A:M library which were designed by Yves Poissant. He has a detailed explanation and tutorials on his site: http://www.ypoart.com/tutorials/bevels-intro.htm Also, if you're trying to achieve realism, I'd suggest that you try to find pictures of real-life weapons and use them as rotoscopes to base your model on.

The thing that needs to be kept in mind is that the formula I derived: s = 2R tan [atan (17.5 / f) / W] shouldn't be used as an exact measure of the size you want to set the stars at. For instance, plugging in the values R = 10000 m, f = 35 mm and W = 640 gives me the value s = 14.49 meters. However, because I made the star size vary randomly between 50% and 150% of the median, it would actually look better if you set the star size to 12 meters instead, which is what I did in my previous examples.

Aw, don't feel bad about it. I feel pretty stupid and lonely myself for getting sidetracked for a month working on something that may be too complicated for most people to use. I made a little mistake on the math in the expression in my previous post. The 2 is in the wrong place, but considering how much smaller the stars are compared to the distance to them, the error only affects the sixth decimal place and beyond, so it has no real effect. Attached is a proof that shows how to determine how big the stars need to be. I'm probably going to include this graphic in the documentation when I release this project, because it's crucial to the understanding of how the star sphere works. Assume that the camera is located at the origin, inside a star sphere of radius R meters. The camera's focal length is f millimeters, and it is set to render an image whose largest dimension is W pixels. We want to solve for the diameter s of a star which will occupy one pixel in the render. Let angle A be the angle of the camera's field of view, and angle C be the angle subtended by the star.

I've had no luck with using an expression to automate the star size. The size of the stars is controlled by a pose slider that I called "Median star size in meters". I set the keyframes up so that the percentage of the pose reflects the original size of the stars -- i.e., the stars were 15 m in diameter before I randomized the size, and the default position of the slider is 15%. Right now, the slider goes between 5 m and 30 m, but I think I'll reset the minimum down to 0 since I do actually have keyframes at 0. Anyway, in the choregraphy I tried to set the position of the pose slider equal to this expression: 0.9*10000*Tan((2*ATan(17.5/..|..|..|Shortcut to Camera1.Focal Length))/Max(..|..|..|Shortcut to Camera1.Output Options.Resolution.Width, ..|..|..|Shortcut to Camera1.Output Options.Resolution.Height)) ...but trying to apply the expression causes A:M to crash. (The 0.9 at the beginning is a fudge factor to make the stars a little dimmer, and I left it there instead of saying "9000*..." to make it easier to make adjustments.) I'm going to give up on trying to automate the process, and I'll just leave it up to the user to keyframe the pose slider at the same time that the camera's focal length changes.

Here's an animation test where I'm trying to focus on motion blur. In case you're wondering, the TIE fighter is a 3DS prop that I downloaded from scifi3d.theforce.net. With the default A-buffer antialiasing, the motion blur is confined to a narrow band of stars in the middle of the picture. This is something I've observed on previous versions of A:M, and I don't know why it happens. Is there something that the Hash team can do to improve the default motion blur routines, or do we have to use multipass if we want better results? With 3x3 multipass, all the stars are motion blurred, but they look a little too aliased to me: So I went with 4x4 multipass, and it does look good, but these three seconds of footage took me nearly 5 hours to render. This is one frame: And here's the full scene: (video removed) Right at the end of the scene, when the camera is moving slowly, you can see the stars shimmering, and I'll have to try to find a way around that. Maybe I'll have to make the stars bigger, or increase the number of passes. What really seems to be holding up the rendering time is the TIE fighter itself, especially in the middle when it's close to the screen. I could try to render the TIE fighter in A-buffer with no background and an alpha channel, render just the starfield with multipass, and then composite them together.