Fuchur

That is a known bug with a workaround... something like CMD + Q or CMD + C if I am not wrong. Anyway: Since Apple has changed much with the Maverik-Update, it is a little bit unknown what will happen in the future. If they leave many libraries behind (like they did with Maverick) it may become very hard to get A:M to work on the Mac any longer on OS 11.0 and above. The Windows-version is however working much better. See you *Fuchur* I just got a 1/yr subscription to A:M for Mac. I hope I will be allow to run it on windows instead. Yes you will be. Ask Jason (support[-a-t-]hash[-d-o-t-]com) if A:M will stop working (it is not said till now that it will happen), but again: Maverick has just recently been released, so you may have a year of the mac version too. See you *Fuchur*

Happy Birthday, have a great day! See you *Fuchur*

That is a known bug with a workaround... something like CMD + Q or CMD + C if I am not wrong. Anyway: Since Apple has changed much with the Maverik-Update, it is a little bit unknown what will happen in the future. If they leave many libraries behind (like they did with Maverick) it may become very hard to get A:M to work on the Mac any longer on OS 11.0 and above. The Windows-version is however working much better. See you *Fuchur*

You can get sharp cubes too using the primitiv wizard. ( > plugins > wizards > primitiv). Since A:M is not really a boxmodeller but a spline/patchbased one. Like that primitives are not that important. The idea behind round edges is that these are harder to create and like this are more needed. See u *Fuchur*

Oh, you are still using A:M v11? That was a quite good version, but since I think v13 to 15 it should be much better than that . I am not even sure if it had the possibility to render to EXR (I think that was added in v13) and you will not find the Post-production module that was mentioned above and so on See you *Fuchur*

No you are really not the only one who has a stable A:M . A:M is really very stable these days... I have worked with it since 2000 and there had been times it was quite a bit buggier (big cudos to Steffen ). Anyway: I have learned the hard way, that it is a good idea to be careful with any software. Sooner or later A:M will crash, like XSI did for me, like 3ds did for me, like InDesign, Photoshop, Word, Samplitude, AfterEffects or any other software did before... and sometimes it is really not the software that does it but maybe the OS or your computer or your power supply... My experience is, that you will never regrad the backup you made or the sequenced files you saved in but you may heavily regrad the one you didn't do, especially if you are on a short timeframe. I have to be more careful than most others, since I am one of the beta-testers of A:M here, but being half as careful as me is still a good idea . See you *Fuchur*

It is ALWAYS a good idea to go with image sequences when rendering something. It helps if you want to change your animation afterwards (you can very likely use parts of the imagesequences and overwrite the others) and if for what reason ever something goes wrong while rendering (application-crash, hardware-fail, power loss, etc.) you can still use what you have already rendered and start from where you left. The avi-file would be written at the very end and that means: EVERYTHING before that has be a success. Additional to that you can use netrenderer to render with more than one computer/core which is not possible with an single AVI-file and so on. It is a very common practice to render to image sequences in the whole 3d-animation world. My recommendation: Always render to image sequences (TGA or EXR depending on what you need) and use A:M or if you do post production with AfterEffects (or some equal software) the postproduction software to render the images into a video-file. It will not take any longer (actually a little, but it really is not worth mentioning compared to having to rerender something in 3d) and is just more save and very good to be used in post software if you need to. See you *Fuchur*

Very nicely done Happy New Year to everyone .

Happy Birthday to you all. simon Cool Good to know you are on track . See you *Fuchur*

There is no real scripting language. There have been Python and Lua experiments in the past, but it never got very far. You will have to use C++ and Visual Studio to get a plugin working. I recommend this only to people who already have experience with C++/MFC-programming. Steffen can tell you a bit more about that than me, but as far as I understand it, there are example plugins in the SDK for close to any plugin-type (for instance Export of 3d models, Render-Output, texture plugins, post effect-plugins, modelling helper-plugins and so on) which should help you to see how these things are done. If you are still interested, please send me a PM or email me (werbung-at-patchwork-dot-de) to receive the last SDK. (will have to check with Steffen if we can make the latest SDK available to the public right now) See you *Fuchur* Thanks, I know C++ well, but I am a Mac developer and user now. Clearly the plugins must work on a Mac, so I doubt they use MFC. They do. There is some sort of converting layer for the Mac. I am no c++ developer and cant say much about it but when i last time asked Steffen about it it was something like that. See u *Fuchur*

Not totally sure about that image, but that seems to be drawn with Corel Fotopainter. ( I am not sure about that... it can of course be a 3d rendering which has been readjusted after that, but would not astonish me if it is drawn completly) Lightenting-Tutorials are rare, but one of them is this one. It is old, but the principles are still very true: http://www.hash.com/forums/index.php?showtopic=9803&st=0 More infos can be found in this forum: http://www.hash.com/forums/index.php?showforum=182 See you *Fuchur*

There is no real scripting language. There have been Python and Lua experiments in the past, but it never got very far. You will have to use C++ and Visual Studio to get a plugin working. I recommend this only to people who already have experience with C++/MFC-programming. Steffen can tell you a bit more about that than me, but as far as I understand it, there are example plugins in the SDK for close to any plugin-type (for instance Export of 3d models, Render-Output, texture plugins, post effect-plugins, modelling helper-plugins and so on) which should help you to see how these things are done. If you are still interested, please send me a PM or email me (werbung-at-patchwork-dot-de) to receive the last SDK. (will have to check with Steffen if we can make the latest SDK available to the public right now) See you *Fuchur*

Thank you very much, but there are really greater stars in the A:M world out there . See you *Fuchur*

If you can get along with my accent, you'll find a start tutorial about some of the patch modelling principles here: Start- & Patch Modelling ...and some other tutorials here: Video-Tutorials on PW3d Just to mention it: The tutorials are in English, but since some people have had problems with my tutorials in the past: English is not my mother tongue. While most people seem to understand me quite well, a few seem to have had trouble with them... please let me know to which group you belong to . See you *Fuchur*

...and A:M will no longer crash when rendering to AVI with Codecs thanks to Steffen. Will be included into the next version of A:M v18. See you *Fuchur*

You 're right on track there Stefan. Keep on moving See u *Fuchur*

Hi, I just worked my way through some trouble with Video-Codecs and I found some interesting things which apply to A:M too. Many think, that you can only output uncompressed AVIs with Windows-Versions of A:M if you want to export a video-file. Since Apple dropped the support for Windows 64bit-Quicktime-Output, it seems hard to output directly to a video format from A:M (which still applies for MOVs), but it really isn't. What you need to understand is, that A:M 64bit is a 64bit-software and like that it can only use Codecs which are 64bit-compatible. (and if you use A:M for 32-bit on Windows, it can only use 32bit codecs.) I just tested it and A:M can export for instance to this looseless codec (no quality is lost and the resulting file is still much smaller than uncompressed AVIs) which is available for 32 and 64bit Windows: Lagarith Lossless Video Codec. And this seems to be true for Xvid-Codec / Divx-Codecs and other stuff too. (just to mention it: A:M v18 crashes at the end for me, but the video-file is still written successfully and playable on my computer. I have written Steffen about that) > does no longer crash. After that you can use for instance MiroVideoConverter (freeware) to convert the file to MP4 files which can be opened on Windows and Macs and is useable for websites. Hope this helps some of you with your workflow. See you *Fuchur*

My 2cents on that: - For very simple movements, CP weights are working well enough. (for instance at fingers it is often enough to use them) - For complex joints you will like to use fan bones. (especially if you are setting up shoulders, etc.) - For movements which are not just meant to preserve volume but which will change something in shape (upper arm muscle, a bone which should look out if you move a arm, etc.) you should use smartskins. Often it can be useful to use fanbones and CP weights or SmartSkins and FanBones with eachother. I find that using CP weights and SmartSkins together can be hard to do in some situations, since they affect eachother too much, but in theory, this can be done too. See you *Fuchur*

Very nice! See you *Fuchur*

It alters the behaviour if you have more than 2 CPs in the hair guides. (otherwise you will not see the difference) One will manipulate the whole hair guide (with all the CPs in the spline) > "IK", the other one will only affect one segment of it > "FK". (if I am not totally wrong... I often confuses those two with eachother... ) See you *Fuchur*

Welcome back and happy splining . See you *Fuchur*

Do you have an example? Hair is working fine in Chor and Modelling-Window but maybe it is some sort of combination that is causing the trouble...? See you *Fuchur*

That really is an impressive setup and way to work . I learned a lot about how some things work with the relationships and installation-bones and I love how easy it looked and feel . Very well done See you *Fuchur*

Very cool article about your passion there and I absolutely hope you will succeed with your dream. For me it seems like the exactly right thing for you to do See you *Fuchur*

I am not sure if it really is a bug... it prevents the view from blocking the program by limiting its drawing-time. If in that time, nothing can be drawn on the surface, nothing is displayed... or am I missunderstanding that one? See you *Fuchur*