aaver

No, don't think A:M calculates the rays wrong. You would most certainly see that in many other cases if it was indeed a bug. I will try to help you in your own thread, though.

This is more like what I originally had in mind. It's supposed to be a "smooth deformer". [attachmentid=11642] M03a.mov

I'm experimenting with some deform plug-ins and this is what came out from one of them. I'm not sure this is what I had expected, but it's interesting in some strange way. Useful? Probably not ;-) And Jim. Sorry for trashing your beautiful model :-o [attachmentid=11560] M02a.mov

Not bad at all for a Norwegian... ;-) Actually I'm impressed and I'm not saying this just because this is done in your first year with A:M. I think you are good, period.

Yes I agree, it's much easier to do this without expressions. The trick is to realize that the rpm is proportional to the slope of the absolute rotation angle. With that in mind, it shouldn't be too hard to control the rpm in your animations even if it would be even more convenient to have a pose slider doing it, was it possible.

Since you are multiplying the Z scale "function" with the ChorTime() you should expect this behavior. I also had this idea before I realized that setting the RPM with a slider is probably not possible in A:M (for reasons I have explained in an earlier post). What is happening is that when the sum of the derivative of your "function" and the derivate of ChorTime() is negative, the propeller will spin back wards. If you have a propeller spinning at different RPM:s but always in the same direction and plot the absolute angle over time you will never have mixed sign derivatives in your plot. Always positive or negative.

Yes of course it does and if that was your challenge, I misunderstood it. What I was trying to do was to control the actual angular velocity for the propeller with a pose slider and that I still think is very hard to do in A:M, but I might be wrong. Actually, I hope I'm wrong :-)

An example of this :-) [attachmentid=11008][attachmentid=11009] I've thought about that, but since the absolute rotation is a function of all previous RPM settings, i see no simple way to achieve this in A:M. You would need a Sum() or rather a Quadrature() function for this. It would be simple to have a plug-in calculate the quadrature of one channel and put the result in an other, but it would be much more awkward for the user. I'm not sure the average user will use a Quadrature() function enough for Hash to take the trouble. I'm almost sure it would be a waste... ;-) M01.mov Propeller01.zip

Great Paul!

Thanks for your comments! Every Most sprite fire I've seen, suffers from lack of detail in the most bright parts and I don't find that particularly realistic, except for very distant shots. I haven't got a clue on how to do anything about it, though. In this clip I certainly have more detail, but I'm not sure whether it looks like fire anymore... [attachmentid=10810] Fire04low.mov

Better or worse? [attachmentid=10789] Fire02Low.mov

Just a quick test using an animated sprite to make fire. I have already posted this on the Movie Forum, but I'd want as many as possible to comment on it. I realize it's not realistic, but what should be different? The goal is to make it hyper realistic...;-) [attachmentid=10770]Download the movie - Right click and Save Target As... - and set it to loop for best effect :-) This is the animated Sprite I used: [attachmentid=10680] [attachmentid=10678] Edit For some strange reason it didn't work to link to attachments in other posts (it worked in the preview...) Go here to look at the animation instead, but please post your comments in this thread.

Some great suggestions, Richard! Thanks, /Anders

This effect is of course cheating as always and it certainly has it's limitations, but I think it can handle some of your "requests" ;-) - the bucket is tipped over just a little bit: Shouldn't be a problem. This case is not fundamentally different from what I've done as long as the motion is moderate and the water stays inside the bucket. - the bucket is tipped right over onto its side: Will of course not work. Here you have to use a physics solver for a convincing result. If you are a great animator you can always key frame it. - the bucket is raised/lowered while also moving sideways: No problem. See the first case. - the level of liquid is changed (like someone is drinking the No problem. See the first case But download the project file and see which of the cases you think it handles convincingly. :-)

Cool, or maybe not... ;-) I guess the bucket is too thin. Thanks, Paul :-)

Now with ripples, but I'm not entirely happy with them. They are still too regular, I think. [attachmentid=10654] I've attached the project file for those who want to see how it's done. Everything is automated. Just reanimate the bucket and "Simulate Spring System". [attachmentid=10655] M03.mov WaterBucket.zip

Ken & Steve: Yes, there will be ripples. That's the texturing I was referring to ;-) I could do it with my external program and it would be easy to make it photo real, but since I'd like to offer this effect to the movie project, I might have to find an A:M way to do this. Definitely possible, but I will have to think some more. Phillip: Dynamic booleans would also do the trick. Here the water surface is a simple square patch attached to one bone with a dynamic constraint. The water suface outside the bucket is hidden by a material. Mark & Nathan: I'll upload the project file as soon as I'm at my office.

I've had this idea for a while, but never came around trying it out. With some texturing I think it could be rather convincing. What do you think? [attachmentid=10616] M01b.mov

"The rat pack" LOL and thanks I guess :-) While waiting for the plugin, I'd be happy to try to make the water displacements for the Oz movie fountains. If you think this sounds interesting, just make a simple test fountain, send the project file to me and I'll see what I can do.

I'd say, wait and hope for the best. Or rather, wait until you are ready with the whole bike and then see what is the difference. 15 s extra per frame may not be much to talk about. Only you know, though. How many frames do you plan to render? When is your deadline?

If you can live with using just bump maps (or better yet, normal maps), go with that. Displacement maps for that kind of high frequency geometry wont help you much, though. You say you want to get rid of all the extra patches because it gives you much longer render times. That's a bit surprising. Are you sure about that? What difference are you actually experiencing?

We Scandinavians are just a bit shy Sweden: aaver Alli daxx0r esse jimstein JoakimL Jocke_K Kaspar C. Korken leFred Mats MixePix Norway: agep Mr. Jaqe Morten Mtv65 ragtag Roughy Veehoy Denmark: A:M Dave Egopoe TempleTiger Finland: (not Scandinavia, but still our sister nation ) Haikalle Julli

..and yet another:

A little bit more cloud like I think, but there is still room for improvements:

..and the project file.. CloudTest03.zip