Fuchur

I have not been very active in the forums lately but still lurk almost daily and am enjoying the latest subscription, for sure. I just felt compelled to add something here. Yes, the current splash IS a high quality model indeed, and won out in the competition, but I have to side with "SEM_Kids" on this. IMO, A:M could use a better Brand / Identification certainly with it's opening screen. Something with a bit more universal appeal. This is something that has been discussed before. We had a winner in the mascot contest which has been elected democratically and like that there is no argueing about it. The next mascot contest will come for the next major version. @SEM_Kids: please check ur pm. See u *Fuchur*

You can of course hollow ur objects. My makerbot rep2 has printed many of these hollowed stuff. The only problem may be overhangs which can not be printed without supports if they are overhanging too much. (The layer u r printing just needs something to be printed on). Additionally to that u need to specify an infill level for solid stuff anyway. (By default something between 10-15%. This means that there will be many holes in an object anyway. But that is nothing u need to worry about too much. The infilllevel maybe increased if u need a moe stable object which needs to be able to handle higher pressures etc. See u *Fuchur*

In general it should work but i tend to at least close the cylinder in itself. That works... never tried without till now. See u *Fuchur*

Please have a look at the setting "Cast Shadows > Darkness" of the lights. To fully block the light you need to set this to 100%. Default is 80%. In some situations (I am not sure if it was a zbuffered shadow or a raytracing one) you need to have a object with a real thickness (no single-thick-object but a closed one). But first try the Darkness-Setting. See you *Fuchur*

Best wishes and have a great day Robert . See you *Fuchur*

Looks great See you *Fuchur*

This has been fixed in v17.0g. It is available on the forums. See you *Fuchur*

You will not directly see the shadow in the TGA... you have to interpret the Alpha in it. Try loading it into Photoshop and have a look into the channels. In AE it should be possible to interpret the Alpha too... never had problems with that. See you *Fuchur*

A:M 64 bit is (quite a bit) faster than A:M 32 bit in terms of rendering. Since there is only 32bit for Macs, Macs render slower than Windows computers with the 64bit version on them. The rendering speed for 32bit versions is more or less the same on both platforms. There are a few more troubles on 64bit, but I am not sure if there are really that many more. Some users seem to run into much more trouble than I do. I think it may have to do with other 3d-software on the computers which is interfering with A:M or something like that. I am not sure. While both version are valid and at the same part, I think that 64bit version of A:M will be more activily developed than 32bit versions. (I think the Mac-folks will get their own 64bit version sooner or later but it is quite hard to get it going for Steffen, as I understand it) 64bit version has no Quicktime-export and no Direct3d-Mode anymore. (as a Macler you never had Direct3d though). Not having Quicktime right in A:M is not a bigger problem, since you can convert the AVIs anyway aftwards and you should anyway try to render to image sequences anyway and put them together in Quicktime or FCE or some other filmeditor-programm. In long terms I would suggest to use 64bit-version of A:M, but you can of course use both versions next to each other... like that you dont have to make this decision now. See you *Fuchur*

Technically the rendernodes are attached to one subscription / activation code. In that aspect: Yes, they are a subscription too. But this is not an official Hash-statement. I just had to program it that way, because it was the only possible (technically possible) way to do it. See you *Fuchur*

Shadow-Buffer is the one you get for TGA too... it only gives you the shadow out in the Alpha-channel and overwrite anything else... I think steffen did get rid of it because of that for EXR in v17. It is not meant to be used with EXR anyway, since there you can work with each light separately, etc. See you *Fuchur*

Easier than I thought it would be and much better than rendering it directly into the image. Thanks for showing this Robert . See you *Fuchur*

It should... be sure to set Alpha, Gamma and Magnitude! See you *Fuchur*

Using the numeric value in the manipulator menu should help too. See u *Fuchur*

Maxwell is using bruteforce algorithms. This means they just dont care about rendertimes. While other renderers tend to simplify things to get faster results and take it that the quality if the rendering may suffer a little maxwell just runs on and on and (in the right circumstances) will provide higher quality and it is the users turn to stopp it somewhere ehen the quality is nice enough. Like that since they r not concerned about rendering time they can use techniques/materials which are not limited in anything. Bruteforce-algorithms are actually nicely scaleable, that means: It is easier than other techniques to cut the rendering in small parts to use with many different threads. So they are highly effected by GPU-rendering speedvise. Still they are slower in normal situations than other stuff... think of it as Radiosity vs Ambietn Occlusion. Radiosity will give you the better looking results but will take much longer than AO. Which style you want is your choice, but it will cost you something if you are using radiosity. The bad thing: you need hours per frame to get great results. And of course some renderengines are just better than others... That is true for the quality of materials, the style and the rendering itself. And keep in mind: the best renderengine is nothing without a good user who can use it. See u *Fuchur* Ps: never had a closer look at Arnold so cant say much about it but what i heard is, that it is using bruteforce too and is like that a physical correct renderer.

At least in my version (17.0) I can drag it into a modelling-window. See you *Fuchur*

Thanks, I didn:t knew that. Thought Cuda would be necessary for all gpu rendering. Wonder why the Octanepeople exclude all the rest? I think mostly because CUDA was available before OpenCL-standards were and the Octane programmers were some of the first who used GPU-power for rendering, so they used the technology they had. Now it is harder for them to rewrite the render-engine, especially since it is explicit written to work with CUDA-commands and not very open for other GPU-command-sets. CUDA may be a little faster too, but I doubt that this is because CUDA is better but because Nvidia's implentation of OpenCL is just a little slower than ATI's (because they want to push CUDA instead). But this is only guessing... never did a 1:1 test (which is hard, because you cant run CUDA on ATI... so you need the exact same computer with different graphiccards which need to provide the same performance from ATI and Nvidia, which is close to impossible... Anyway both technologies are (in the right circumstances) much faster than CPU-renderings... See you *Fuchur*

Easy: I dont own a Nvidia-Card but only ATI-graphic cards as many other people do too and creating a "feature" which can not be used by 50% (or more) of the users (since ATI is often faster for games and is often less expensive people like to buy AMDs) while there is an alternative which can handle both manufacturers, it is just a logical choice for A:M to use something that helps potentially 100% of the users instead of 50%. In general I like standards better which are supporting as many systems as possible. CUDA has advantages (tends to be a little faster) but it just has too many disadvantages in the other direction and OpenCL has other advantages too (for instance you can access CPU-power with the same commands too, which is not possible with CUDA), it is widely useable, etc. See you *Fuchur*

Try to click ones in the modellingwindow on the selection of the cps and copy now. If you just click on the group in the PWS and copy there too, A:M will only copy the group but not the content of it. If you select the group in the PWS and click than once on the selection of CPs in the modelling-window and copy again, the geometry should be copied too. See u *Fuchur *

I cant help there much, but yes I see the potential... (I am a webdeveloper with advanced skills in PHP, JavaScript and MySQL and quite basic skills in Java and C, but not with C++ which A:M is written in.) But I would not go for Octane... While it is a nice renderer, it only support Nvidia-Cards and that is a no-go for me. There are alternatives of course, like the Indigo-Renderer or even more promising Luxrender. Indigo-Renderer is more used in an architectual context and is a little more expensive but is a full blown ready to use openCL- and Cuda-based renderer. Luxrender is free and uses the GPL-license with a C++-API, has a currently developing OpenCL implementation (useable by Nvidia and ATI-cards) and is a nice looking renderer. So if I could vote (which I can not) I would vote for Luxrender to be connectable to A:M. It is available for Windows and Mac (and Linux, so that is not that important for A:M). OpenSource and free for commerical usage means no license-prices and no additional costs for A:M users. Sounds like a great deal to me. We will see what the future brings... It could be a great addition, if it can be combined with A:M. See you *Fuchur*

Hey, do you have a paypal-account? I'd like to support your animation-project, but I can not use Amazon Payments (provided by kickstarter) since I dont own a creditcard. (just not needed in Germany since we have a EC-Card with any bank account and no charges which can be used for buying things in all over Germany... (actually all over Europe)) See you *Fuchur*

Just to make it clear: Threads have nothing to do with Realtime-displays. Threads (Multithreading) are not used for Realtime-displays in A:M. It was used for other tools in A:M and it was tried to use multiple threadings for final rendering. See you *Fuchur*

The 2.2 is quite creepy and I think it is the look you want to get. 3 is too bright... there is no longe a real shadow anywhere and I can see every detail. The animation looks good. For the images before those: I have the same problems as the others. very very dark (close to not at all visible). I'll try it at my workcomputer, where we have calibarted, professional monitors for graphics-work. But in general they behave more or less like my semi-pro Dell Ultra Sharp. See you *Fuchur*

At most 10-15 mins if you ask me See you *Fuchur*

I am very sorry to hear that.... she will be remebered and may live in ur thoughts. See u *Fuchur**