robcat2075

Ease isn't really a part of TransistionToNext Action. Ease is the property of the action that determines how far through the action you are at the current frame. By default it always says 0% but automatically goes thru the action at that same speed as the keyframes in the action. But when you set ease values you can change that. If you set 0% at 1:00 and 50% at 5:00 and 100% at 6:00, the action will slowly play from the beginning to the halfway point from 1:00 to 5:00 then quickly play the last half from 5:00 to 6:00. You can set any % on any frame so you can make actions halt or reverse even. You could use ease to control what part of the action is on when the TransisitonToNextAction begins or what part of the next action the transistion is moving towards. No need for that. You already got me the mic. Thanks!

here's a brief look TransitionToNextActionH300.mov

I don't know enough about MAX to follow the interface, but it resembles what we do with combiners in A:M materials. I know we have those same noise patterns in A:M. Most of my recent material experiments make substantial use of combiners I haven't written my book on this subject yet. We don't yet have the ability to freely drag and rearrange nodes like in that interface (I presume it does that), but I've found moving nodes in a text editor helpful in the mean time. Procedural materials are somewhat un-intuitive to work with. The guy who did that demo knew what he was doing and what his options were. That will be key in A:M also.

in the PWS, on Post Effects>New>Post Effect on the new Post Effect >Change Type To > Hash Inc.>Tint "Tint" has a "style" preset for "Black and White"

Great render!

First, is "transition to next action" not enough for what you are trying to do?

did you enable "Show more than drivers" in the chor?

As i see it, the artifact is at the intersection of the sprite with the emitter. Only the portion of the sprite that is on the viewer's side of the emitter surface is visible. This is apparent by spinning around the model when a particle has a portion on both sides ( I deleted the back half of the sphere so i could see inside) We should be able to see the whole particle thru a 100% transparent surface, but we don't. It's getting clipped. Possible work around... make your sprites 100% transparent at the beginning of their life and fade them to 0% transparent after some point when they would have cleared the surface of the the emitter. Haven't tried this.

What's the effect you can't get? that's a pretty good result. You may have sold me on it.. Do you have a link for that? The ZT systems I found was just rack units.

I got cold feet and haven't built something yet. Let me know how it does that sounds like a good price although the general sense I get is that intel processors are way out ahead of AMD now. True. I'm just wondering what a 1-ray light is doing that z-buffered lights couldn't do. And 10 of them!

I think that's it. I guess you can't actually hit the render button while you're in the UV view. If you mean getting one of this peculiar cylindrical mapping method that probably needs some extra step that I haven't thought thru yet, but a screen capture woudl be key there too.

I'm going to say that's the problem.

What sort of lights are you using?

on the Action in the PWS and "Save as" I'm presuming you really mean an "Action" otherwise you'll need to describe the problem more.

fabulous info. Thanks, both of you!

BTW, you can use cylindrical mapping to simplify lots of unwrapping tasks. Works great with A:MPaint. Here's a link to a link... http://www.hash.com/forums/index.php?s=&am...st&p=319183

Why not use cylindrical mapping? No unwrapping needed. Perfect seam at the back. No stretched splines.

For the text app? Since it's an external app it's not really a feature request. I think there are people on the forum who could dash that out. I recall someone mentioning a text editor that could do math in its macros. Track that down and you'd be halfway there. Fixing NetRender? It probably wouldn't have any weight from me since I'm not a netRender owner. I have one core total. If it got done I'd never be able to test it. Knowing nothing about it, I'm going to guess it's a networking thing. NetRender can't distinguish between different renderslaves that are at the same network address, maybe. So maybe there's a way to trick them into appearing different? I'm just brainstorming. Someone with NetRender and knowledge of how it sees across the network would have to dig into it.

multiple instances. I realize this is not as convenient as if Netrender transparently handled multiple cores. I just see it as a shortcut to setting up multiple instance renders.

I'm sure it can be done. Submit it as a feature request, if you haven't already. In the meantime I can imagine someone making a simple text editing app that, given a Chor set to render all the frames, would spit out X copies with each set to a different frame range. Then you'd just have to load each copy on to a different core and set it rendering without having to dig into each one to reset the frame ranges. Lessee... -this app would search thru the .CHO file for the defined frame range, -extract the start_frame and end_frame numbers, -extract the number_of_cores to be used from a string embedded in the PRJ title then, in a loop, write number_of_cores copies with Copy_0.cho set to render start_frame to end_frame, step=number_of_cores Copy_1.cho set to render start_frame+1 to end_frame, step=number_of_cores Copy_2.cho set to render start_frame+2 to end_frame, step=number_of_cores and so on until number_of_cores .cho files had been written out. (alternatively each copy could be set to render contiguous ranges if that was preferred.) that would be a simple program to write, there's probably a text editor out there with sufficient macro ability to do it.

Read the user notes for each one carefully. I believe MMoP needs that you have 'd a path for it to operate on. I think Multiply needs you to select a plane.

Just to check, in you Options>folders panel, make sure the path for extensions is pointing to the folder your extensions are really in. This can get confused if you have more than one version of A:M installed.

Based on what Steffen has said in the release notes, OpenMP is only implemented for certain parts the modeler. It speeds up the "finding patches" maneuver, which is noticeably slow on very,very large models. This is the pause when you get when you edit CPs on a model of say, 10,000 patches or more. So far, OpenMP hasn't lent itself to speeding up Final rendering routines. Your best bet for making use of multiple cores is still running multiple instances. It makes almost 100% use of each additional core which is far superior to any single instance/multithread scheme in any software. If you have multi-core machines NetRender probably isn't your best choice to make the most of them.

It doesn't have to be warm and fuzzy, the reversal on the troll might be quite grim for him.

No, haven't tried it since there's no case in which I'd want field rendered footage these days. In most CG field rendering makes things crawl more rather than less. But I haven't tried it. Also i don't even have a way to properly play field rendered footage. I suppose I'd have to burn a DVD and play it on an NTSC set.