robcat2075

That's a good solution. thanks!

That's showin' those polygon guys how it's done.

I like those shoulders. Those look like thy would be easy to rig.

If i pass any arbitrarily shaped object through another surface (lets start with something as simple as a plane) how can i capture the shape of the intersection on that surface at any moment? For example, the intersection of this torus with the plane would be a couple of ovals. How could I capture that? I can sort of get the edges of the object as they pass thru the plane by putting an orthogonal camera very close to the plane... TorusThroughPlane.mov ... but it misses pixels and I'd really like to have the shapes filled, not just the outlines. I'm trying to find a way to better simulate the disturbance an object makes immediately around it as it sits in a liquid. Being able to have an image of the intersection of the object with the plane of the liquid would be a part of that.

Remember to send it to AMReports.

Put together a test PRJ with that top plate and someone might monkey with it.

what happens if you set multipass to one pass? And how about a regular render? Regular render has the same anti-aliasing power as 16 passes.

Wait a sec... the top one is not the first pass, it's on its third pass.

that last one is much more obvious. Presuming that's a regular Q render, something is odd.

If that's not AO noise perhaps it is dithering on the part of A:M to avoid obvious banding. I have to really crank levels on the image in Photoshop to see it.

Right Mouse Button

It will be easy! You can in the camera view, choose New>Rotoscope and choose and navigate to an image in the file dialog that comes up. You can also drag an image that you have already imported to your Images Folder to the camera view to make it a "Rotoscope" Welcome back to A:M!

Get out your old SSS projects and give them a test render and see if this change has created any side effects. So far, it looks the same to me, just faster!

Also... Jason Hess (thejobe) tells me he is slowly getting his segment rendered. Dhar Jabouri (dhar), tells me he has finished "the planning stage" and does intend to get something done for the project.

I am in the larval stage.

Actually it's supposed to be fixed in beta 4 already, try that if you were using v16

Coincidentally, I ran into that a few weeks ago, AMReported it and it's marked as fixed for the next release.

While pursuing an AMReport Steffen found a way to optimize the Sub-Surface Scattering code. My first simple test gives promising results: that's almost 60% more frames per minute. This change is in v17 beta 5 available now!

I agree. Fine looking models!

Defining color changes as a "percent" of the sprite's lifespan means you can later edit the lifespan of the sprite and not have to go back and adjust all the color keys to suit the new lifespan. When the sprites lifespan is 2 seconds, the color you have keyed at 50% will happen at 1 second. If you change the sprite's lifespan to 3 seconds the color you have keyed at 50% will now happen at 1 1/2 seconds.

Here's how to do color-changing sprites: Create a sprite material in the materials folder drop it on the emitter group of your model Put that model in a chor Have the Chor window open and visible. Back at the original sprite material in the PWS>Materials folder, expand Sprite System>Sprite Emitter Set "Life" to a time in seconds:frames Expand Color Method> Color Set Color Method to "Over Life" Switch the PWS timeline window to curve-editor view The units at the top will now be percent, not time scale that window until all 100% is visible keyframe some color setting at 0% (the start of the sprite's life) keyframe some color at 100% (the end of the sprite's life) keyframe anything inbetween. Because the color keyframes are mapped out over "1:40:00" as representing 100% you will need to switch back to the non-curve-editor view of the timeline and zoom back in to test scrub a few seconds in your chor. Notice in this test example I also set "Use Additive Color" to OFF, so that teh exact keyframed colors would be displayed on the sprites instead of their color values being "added" to the background. This keeps black (0,0,0) from being invisible. SpriteColorChange04.zip That certainly shouldn't happen since the particle settings should be the same text in the file whether it's a PC or Mac file.

Aha... you shouldn't key the color over life while the timeline is displaying frames. You have to switch to the curve editor to make it display the % on the timeline, meaning percent of the life. Internally A:M represents 100% as 1:40:00 and that's what you see if you don't switch to the curve editor. If you try to key a color at 5:00 on that you will really be keying it at some tiny portion of 100% Now, why does it create red when i try to key black...

but "5:00" should equal five seconds, not five frames. 0:05 should equal five frames.

In my initial investigation i seems that if i set the "life" of the sprite to 5:00 (i regard that as 5 seconds) it really only lives 5 frames. Do you get that?

Keyframing the color under "Color Method" will cause the sprite to change colors but it seems change much faster than the lifetime of the sprite