Fuchur

Very very nice See you *Fuchur*

No, in general you do that in A:M first using BakeSurface (or you can use 3dpainter to do it, because it is using the spline-data directly) but you need to do it with the splines BEFORE exporting the final mesh. With editing the mesh in the other application: 1.) Create a model in A:M or anywhere you want. 2.) Export to OBJ and import it to 3DC or whatever voxel-application / sculpting-package you want. Now you can change the polygones and use voxels and micropolygone-modelling and so on. 3.) Export it again as an OBJ from that application and import the obj as a prop. 4.) Use Resurface / Retoplogy in A:M to make a spline/patch-based model. 5.) Use Bake Surface on the model to create UVs to be used in the painting-application. (can be 3dCoat or ZBrush or 3dPainter or whatever you want) 6.) Export it again as an OBJ from A:M (now with UVs). 7.) Use the paint-features of the application (now you can ONLY change the textures on the model. if you change the polygones / add or remove polygones (by using voxels, micropolygon-modelling, etc.) the UVs will no longer work.) 8.) Export the textures from the application (in 3d Painter you just hit "Save" for that, in 3dCoat you export the model as a whole which will create an OBJ-file and external texture-files. (the obj is not important, it is all about the image-files here) 9.) If the name of the files has not changed just copy and paste them to the folder A:M is referenzing the model from if yes, rename them first or use A:M to change the texture-files of the decals. (this is the better way, since like that the refreshing will never be a problem). Like that you can use any kind of modelling-method and texturing-method you want with A:M. If you don't need to use micopolygone-modelling / change the model in any kind of way in the other application other then the textures the workflow is like this: Without the need to edit the mesh in the other application: 1.) Create a model in A:M. 2.) Use Bake Surface on the model to create UVs to be used in the painting-application. (can be 3dCoat or ZBrush or 3dPainter or whatever you want) 3.) Export it as an OBJ from A:M (now with UVs). 4.) Use the paint-features of the other application (you can ONLY change the textures on the model. if you change the polygones / add or remove polygones (by using voxels, micropolygon-modelling, etc.) the UVs will no longer work.) 5.) Export the textures from the application (in 3d Painter you just hit "Save" for that, in 3dCoat you export the model as a whole which will create an OBJ-file and external texture-files. (the obj is not important, it is all about the image-files here) 6.) If the name of the files has not changed just copy and paste them to the folder A:M is referenzing the model from if yes, rename them first or use A:M to change the texture-files of the decals. (this is the better way, since like that the refreshing will never be a problem). Viele Grüße Gerald

You can of course use retoplogy (in 3d coat and / or A:M, while 3d coat has very advanced retopology features they are still no splines) The workflow would be to model a base-figure in A:M, advance it in 3DC reimport it to A:M to retopology it and than paint it with this method shown here. See you *Fuchur*

See my signature. It is not a direct way and not perfect, but still better than nothing. I'd love to see a real FBX-exporter too. (or Collada) See you *Fuchur*

I look at the shape of the curve, delete the CP i don't want, then reshape what's left to look like what was there before. You only do this on one curve at a time. But unless a CP is the cause of some problem I just leave it. One method I've found to work in a good number of places is to create a keyframe at the appropriate location on both sides of the keyframe that I want to get rid of and then delete that keyframe. This merges in the sense that it averages the new keyframe out based on what is happening at the two extremes outside the new keyframe... that's what I might term an 'averaging merge'. A little more controlled merge would be that of simply sliding the keyframe from the old location to it's desire position. This has the benefit of maintaining all of the keyframes (i.e. not averaging them based on it's neighbors) but is subject to the biases of both. I'm not sure what this form of merge would be called as technically it's not really combining any keyframes. Perhaps it is 'transposing'. Trans + Pose.... that works for me. 'Transferring' would then be using the Copy/Paste method of moving keyframes from one location to another. In the end you could use the export-method again going to *.mot and using a value other than 0 for importing back again... See you *Fuchur*

I understand what you are saying. A similar issue exists with the various rigs that a character can have in A:M. Actions created for one generally will not work another. As I'm after the poses more than the motion itself the BVH data could be used without any constraints at all to inform the poses as well. I'm not after every keyframe but rather only those poses that work the best for the intended action. I expect to hand animate the rest. I have a tentative plan to setup Thom (or some other character) to work with the Carnegy collection and use that as a trial for testing out optimal workflow in A:M. I have a video-tutorial on my website about that. It is only showing the basic process not a real finished result, but you may find it useful anyway. A:M & BVH Tutorial See you *Fuchur*

I look at the shape of the curve, delete the CP i don't want, then reshape what's left to look like what was there before. You only do this on one curve at a time. But unless a CP is the cause of some problem I just leave it. Reduce keyframes will do that for you. You have to do it one by one with everychannel, but it is still faster then going through all of them by hand. on the channel you want to reduce in PWS and select "Reduce Keyframes". You will be asked for a reduce-level to insert... See you *Fuchur*

Ah, did not realised we were talking about the chor but thought of an action itself. But yes, than Roberts suggestion is the right most straight forward one. See you *Fuchur*

Thanks for the response . Hope that it will help people to understand A:M's modelling better. See you *Fuchur*

An easy way is, to export your action as *.mot-file and reimport it again with a tolerance of 0. Step by step: 1.) on the Action in the PWS and choose "Plugins > Export > Motion (*.MOT)" 2.) Export the action to a file. (name does not matter) 3.) on the Action in the PWS again and choose "Plugins > Import > Motion (*.MOT)". 4.) Choose a tolerance-level of 0. 5.) Import again. Neve tried this before, but it worked in my simple case here. See you *Fuchur*

It is more like an interpolated texture or something like that. I dont see that this is available in A:M right now, but still yes: It is quite much to do for that. See you *Fuchur*

I am quite sure they are, but Normals are facing the right direction, right? See you *Fuchur*

That is fine, but I think it is more about the fun to do it than to have the model in the end... at least for me. See you *Fuchur*

There is the smooth-plugin... but it is not exactly what you are searching for. See you *Fuchur*

The question is: Do you really need that resolution? 0,1 mm is already quite small. Is it necessary to go to 0.025? This only makes a difference with technical functional-models (if at all) and lets face it: For that it is more like a fun thing or to initially try somet stuff out, but you will have a hard time building something useful in that direction with it. It is more for models, prototypes to show stuff, etc. In the end: Do you need the resolution? For most purposes I would say: No. And the good thing about the makerbots: They have experience and you can print bigger objects while being less expensive. I'd go for a makerbot. Although I find the dual-extrusion-model not too attractive... for different colors you very likely will use an air-brush-system anyway till they can provide 512, 1024 or even 2048 colors. (some of the high-end-printer can deliever that... but I dont have my moneybag around to pay 100.000 Dollars right now... ) I am playing with the thought to buy a replicator 2 so... See you *Fuchur*

I would lean him a little bit forward so he can balance out the other leg and arm better at the first image. Other than that: Nicely done See you *Fuchur*

However... that turned the five-pointer into a six-pointer. New problem! Martin would likely be the ultimate authority on how A:M deals with these things since he originate the code for it. Too bad he doesn't visit much anymore! he is only adding the cp to force another subdivision behaviour... it would not really be there. it is only to illustrate the difference. see u *fuchur*

Really good example! Thanks for showing... maybe it would be worth to have a look in that direction. See you *Fuchur*

Pardon me but, how do you bake the surfaces ? Its something I would like to try but couldn't find the option... ? regards simon that is a new feature in v16. see u fuchur

Same from me . Congratulations and keep on rocking . See you *Fuchur*

I like that very much. Did you use dynamics or were the bounces keyframed ? regards simon It is all just cloth-dynamics. Didnt do anything but placing them above the camera . Very much fun . Attached you can find the project-file. Hope you have fun with it . See you *Fuchur* box.prj

Hi! Just wanted to share a small simulation I did with these cubes. It is a cloth-simulation... even if it does not look that much like one See you *Fuchur* rendering_box.wmv

Many of those problems may be overcome if you just minize and maximize the current window (in A:M itself). You just have to force a refresh of the drawing engine. Try that first before closing and opening A:M again. I have not experienced this with my new card, but my old did that too some times. That was my (qite easy) workaround. See you *Fuchur*

Do you know any more about that? Get an AMD HD7850 (for instance) it is a very solid card for about 200 bucks and I am very pleased with it. I have a PowerColor 7850 PCS+. The other stuff depends on what you want to built: Single-Core-Performance: Most Intels will outperform AMDs of the same price-range. Multi-core-performens differes, especially for the 6-core AMDs. See you *Fuchur*

Really, really great looking candle! See you *Fuchur*