robcat2075

R-E-S-P-E-C-T You can reduce clatter and excess liveliness in cloth by increasing the "Damping" values. This reduces the tendency of the particles to keep oscillating and reduces the effect that the motion of one particle has on neighboring particles.

update... I've added a render of the full cloth simulation in the top post so you can see how that is set up.

Those are good looking shots! You and I could form "The Unfinished Halloween Short Club".

It's like headlights for your wrists!

Thanks! It was a cookie cutter with alpha channel.

A brief test using SimCloth for Autumn leaves... YouTube version: BooH264.mov UPDATE... here is a shaded wireframe render of the full cloth simulation that takes place before the rendered portion above. Although "Show backfaces" is ON, the cloth patches only show their decal on one side in shaded mode. Not sure why. Boo Cloth Simulation.mov mp4 version: Boo Cloth Simulation.mp4 PRJ: OctoberSurprise.zip

Since it is already possible to force a key on a bone that includes constraint results, it should be feasible to include that power in "baking".

A quick test shows that IK relationships do indeed not bake correctly. A bug report may be in order.

I don't seem to have a Windows update regarding OpenGL waiting for me. Do you know what the update number was, by any chance?

It looks like Streak particles. I don't know why they would be there.

I think the shadow buffer represents only cast shadows. The shadowed side of an object is something different. If you want a hard black and white shading on the ball, set its color to white and set its "Diffuse Falloff" to 0. (The "Intensity" of the Klieg light must be 100%) If you want to eliminate the darkness from the ground, where it isn't illuminated by the Kleig light, set its Ambiance Color to white and set its Ambiance Intensity to 100. That should get you all white except for the shaded portion of the ball. Does that get you what you want?

Explain to me, "the sphere itself"?

I highly value your insight into these things so I'm curious as to when you think another contest might be ideal to run.... I can only speak for myself, but as one of several people who went right up to the deadline and still didn't get an entry done, I'm worn out right now and not ready for another one just yet. I do like the idea of contests with a subject. I think that encourages people to do something new rather than pull something off the shelf. That said, we've had so many "Christmas" and "Holiday" contests in the past that I think "Winter" is is a theme we've visited a bit too much already. I think it would be cool to see WIPs along the way and see progress on the forum rather than have everything just appear at once.

I'm glad to see there were so many good entries. I feel better knowing that I wouldn't have placed even if I had gotten my entry done.

I think it's a bit too soon.

Congratulations Kualrobi! That will be a fine mascot!

Send me a sample of the data that isn't working.

Well, that is creepy!

Every time this comes up I say "get me a copy of the file format you're trying to import and we can make a converter" but no one ever does that. There are only seven possible pieces of data in camera tracking... Camera position in XYZ space, Camera rotation on XYZ axis and maybe Camera lens focal length. Worst case, you have to convert units and trade one axis for another... spreadsheets are made for that. Jason, that person asking about importing camera tracking needs to be specific about what format his camera tracking is in. If he doesn't know then he's probably hasn't done any.

I seem to recall the Syntheyes (?) program produced A:M Camera animation from tracking live footage. In general, if we had a documented example of the camera motion format, it should be possible to make a spreadsheet to convert it to A:M motion.

I tested a few simple scenes... -It seems to create one image file per patch if you choose "Polygon", but two identical images per patch if you choose "Patch" -The images do not include shadows or AO, even if "shadows" is checked. -The images seem to be light information only and do not include surface colors or textures. Here's a problem with "baking" lighting I think... Each side of a patch can shade differently depending on which side the light hits, but an image on a patch appears on both sides. If that image is supposed to be the baked lighting which side does it represent? I suppose there could be a rule that only the normal-positive side's lighting gets baked and you'd have to make sure you have no single thickness patches visible to your camera

That option is not available to everyone. Only Alpha/Beta testers? The latest reports section most of us have access to is v18. You're right about that. If Elm wants to write the report now he could do it in v18 and I'll make a note to bring it to Steffen's attention, or... he can wait until v19 opens up since Steffen probably can't jump on it immediately anyway.

go to hash.com/reports You may need to get a password from Jason if you don't have one for AMReports already. For "Project" choose V19.0 For "Severity" choose "feature" Explain what you want, why you want it and point out what is already there in A:M

You can move the Kleig Light farther away so it lights your whole scene. We did that for TWO so we could use faster-rendering z-buffered shadows instead of ray-traced Sun lights. If you make its cone angle small and move it far away it will appear like the parallel rays of a Sun light.

I gave Matt's practical light version a try with a Material on a small grid in front of a light It does work. You'll need to set Transparency somewhere between 0 and 100% for the two Parameters of the Combiner and experiment with color combinations. If you want to use a colored light instead of a colored material, you will need to set the light color in the Chor You'll also need to set your Kleig light to Ray-Traced. Z-Buffered won't properly cast partial shadows through partially transparent objects. There probably is a small render time hit in having to use a Ray-traced light but it was fairly speedy none-the-less and this method doesn't lose the material's animation when the PRJ is saved.