Fuchur

Really looks quite well . A little bit work on here walking/sneaking but it really is well done and I like the whole composition quiet much... The music is nice, the character is visible and the new version were she gets rid of the hand of the guy is looking much more feminine. Keep on rocking *Fuchur*

Best wishes David Let's celebrate . See you *Fuchur*

Depending on what you got there both are good ways. If you for instance have triangles, Retopology is MUCH easier than getting the stuff right in A:M. If you have a very high polygone-amount it will be better too. If you have a model with good edge loops and quads and at a lower resolution, deleting is very likely the better option (if you are not running into finding normals-waiting times which are just too long). I had very good experiences with Retopology and would recommend it for the given situations and I did the deleting of parts and splines after importing too. Both are valid and nice methodes and it just depends on the case you are in at the moment. See you *Fuchur*

Very likely not. But it would be before that. A:M would still interpret X-axis data but in reallity it would be the y-axis which would be manipulated by the device. This is called remapping. A:M would think it would receice X-data but it would really be data of another axis but the API inbetween just remaps the informations. Try out if it works. It may be possible. See you *Fuchur*

I actually never tried to print an open object, but I am very positiv that you have to do that. Just close it and you should print without a problem. See you *Fuchur*

In my experience you dont have to... It is not a bad idea, but the STLs written with A:M are fine with the Rep2 given that you watch the normals. See you *Fuchur*

You mean if they does not loose the law sues against them.... See you *Fuchur*

I could, but what is with the other files? reboot - no effect. I think the easiest way is to copy all datas from the CD in an extra folder and forget the the libraries as long as AM works. One possibility would be to install A:M again without uninstall at first. That should write a new installation-log-file and since it is the same version you are reinstalling it should write the same files again. In the log-file A:M will very likely store the info what has been copied. Like that uninstalling is made possible. Then you could try to use it again (I doubt that it will work from the start) and if it does not work you should be able to uninstall then. The installation-file should be available again and the uninstall-process should work again. /////////////////////////////////////// Also nochmal auf deutsch: 1.) A:M nochmal installieren, ohne es vorher zu deinstallieren. 2.) A:M wird während der Installation eine neue Log Datei schreiben und diese müsste eigentlich die gleichen Infos drinstehen haben wie deine erste. (muss natürlich im gleichen Verzeichnis installiert werden, etc) 3.) Dann deinstallierst du A:M wieder. > jetzt müsste die Log-Datei da sein und es müsste gehen. 4.) Dann wieder installieren und gucken obs klappt. See you /// und machs gut *Fuchur*

You may want to make a double-click on these cryptic numbers next time . See you *Fuchur*

No you have to create hollows yourself. There is just an infill-level... that means that if you have a solid object (or part of it) it will be partly hollowed with a certain infill-level. It will create a pattern inside, quite equal to the once found for instance in bird-bones (which makes them very light but very durable anyway, because the inbetweens do not add to stability but only to weight). See you *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.