Fuchur

Here is a video-tutorial about it: Video-Tut: Snap-To-Surface in A:M See you *Fuchur*

still should not happen so i am not sure... how does the end result look? maybe it is a technik to avoid rendering pixels several times? *Fuchur*

What is your AO-Quality-Setting? that will create the noise. if you go to 85-100% you wont see that any more. Maybe you can even go lower. It can be set at the render-settings. See you *Fuchur*

...and the coolest thing: SSS never really worked for me... I used the final-rendering-dialog and rendered SSS with it and the group was the last in the list and so on and still I got a black rendering... but that changed with this update . See you *Fuchur*

Here it didn't, V17 beta 03 here Try beta 04. See you *Fuchur*

...and there is a wiki-entry in the english Wikipedia. See you *Fuchur*

Should work now... recently tested it and it did what it should. See you *Fuchur*

Very very sad... he was a great guy. Thank you very much for your words... most of us would not have known what happend otherwise. Deepest sympathy to you and your family... we will always think of Paul in a good way. *Fuchur*

Very very cool . See you *Fuchur*

Just received it . Seems like the toll station had a look at it and like that it needed a little longer. I cant watch it right now, but I am looking forward to see it this evening! See you *Fuchur*

Till now I didnt receive it... but I'll wait a little longer . See you *Fuchur*

Happy birthday!

Another update for the raven... See you *Fuchur*

Is it only connected to this scene or to all scenes? In case of all scenes you may want to reinstall A:M, to be sure. Make sure you copy your master0.lic-file to a save place, uninstall A:M and reinstall it again. Then copy the master0.lic-file to the folder. If this does not work, you may want to make a bug-report. Steffen is hunting the rotoscope-bug for some time now and while he solved many causes already, there may be other onces too... See you *Fuchur*

I don't recall needing to type "Web Subscription". When does that come up? I think at registration to the Community-window you get asked about that... I run into that a while back, but somehow I could solved it... anyway it may be a good subject for a A:M Report. See you *Fuchur*

Hi, you are really sure, that you didnt press the number lock-key by accident, right? That one is often causing this... I highly doubt it is a problem in A:M (I can't preclude it totally of course, but it would be something everybody should be experiencing at a very early stage and I cant believe that it has not been found before...) Do you have any Function-keys on your keyboard that may have been pressed (often a blue F or something like that) I cant test it with exel, but maybe it is cleve enough to see the right inputs anyway... See you *Fuchur*

I think what you may be experiencing/describing is that the dynamics look, playback differently in REAL-TIME, and scrubbing compared to the rendered version? Yes there is a difference. (ver16b 32 bit PC) However, I do not believe there is a difference in RENDERED imagery, whether the dynamics have been baked or not. The computation looks the same to me. It also doesn't seem to matter (in this small test) whether it is multipass ON or multipass off Your best bet is to bake your dynamics and then check the interactions, appearance of your animation in real time with the baked dynamics. Make your tweaks according to that. Then go to render. One of the biggest problems with OpenCL is, that different implementations result in different results. (only slightly, but for a rendering-application a difference of 0,0001 makes a huge difference, especially if this result is used to calculated further on. CPUs are not the same neighter, so baking is a better idea... what you do afterwards with the channels / keys is then your decission... See you *Fuchur*

Should be possible to do. Just set the ease-value to a different value so they start at different positions. Did you set "Has Stride Length" to on and did you set the step-width as described? See you *Fuchur*

Really cool See you *Fuchur*

Just bought one . I am very happy that they ship even to Germany... See you *Fuchur*

You can turn that inverse if you want. Have a look at the Option-Menu. The default behaviour is based on the fact, that it is meant to be an "alert"-feature, because you can easily mess things up heavily when you work with Animate-Button off (you change ALL the keyframes on any given time) while it is not that bad if you work with it on by accident (you will only mess up the keyframes at one time). Anyway since Jason had the same concerns, there is the option-menu-entry that can help you if you find it more logical the other way round. See you *Fuchur*

EXR has shadow-buffers and there is one with TGAs. It is normal that you get a black image with TGA. The buffer itfself is in the Alpha-Channel. See you *Fuchur*

Very nice look... somehow it looks like a painting too me... but a very realistic one! Love it! See you *Fuchur*

I am quite sure that "Set initial velocity to zero" cant work. Each particle gets some sort of property when it is created. If you change the initial properties, these will only effect new particles which are created, but the old once still remain in there state they were fired with. In general this is a good behaviour.... otherwise you could not make a nice transition, etc. But you dont want a transition... so this will very likely not work, but only hold the new once back from getting up at all. What you would need would be a lifetime-based velocity-value. I dont think there is one... It could however work with forces. If you set a force up and one downwards and the one poiniting down is set to 0, while the other one is set to 100 it should go up. Then you can activate the one pointing down (same power) and the particles should sooner or later come to an hold. But I doubt that they stop spinning around. (keep in mind too, that a force is an acceleration, that means: They will not stop immidelty if you slow them down from the other direction by just setting the same force-power. I'll test a little with the second solution to see if this can help. *Fuchur* Just tried it... it is too tricky to get the right settings with that. The other possibility I tried was to use Gravitional Force and set it too -100% after a certain time. (for the same time) but this is not working neighter. What exatly is it, what you are trying to do? - If you only need a static "cloud"-like particle-cloud you can just set the initial velocity and all the forces to 0 and move the emitter around like you need it. - If you need it to develope, but your camera is static, you can use a post-program to just stop the clouds at a specific frame (keep the last frame after the animation). - If you need it in A:M (3d-space) you can render the sequence out and use several layers to simulate a 3d-behaviour. ...etc. It highly depends on what you are after. See you *Fuchur*

I am quite sure that "Set initial velocity to zero" cant work. Each particle gets some sort of property when it is created. If you change the initial properties, these will only effect new particles which are created, but the old once still remain in there state they were fired with. In general this is a good behaviour.... otherwise you could not make a nice transition, etc. But you dont want a transition... so this will very likely not work, but only hold the new once back from getting up at all. What you would need would be a lifetime-based velocity-value. I dont think there is one... It could however work with forces. If you set a force up and one downwards and the one poiniting down is set to 0, while the other one is set to 100 it should go up. Then you can activate the one pointing down (same power) and the particles should sooner or later come to an hold. But I doubt that they stop spinning around. (keep in mind too, that a force is an acceleration, that means: They will not stop immidelty if you slow them down from the other direction by just setting the same force-power. I'll test a little with the second solution to see if this can help. *Fuchur*