Tore
Forum Members-
Posts
2 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Everything posted by Tore
-
Thanks Nancy! Looks fantastic! I'll try this out immedeately!! :-)
-
I am trying to get a linocut look in A:M. Something like this (linocut by danish artist Palle Nielsen): The closest I can get is this (done with the Grid material in A:M): But I would very much like to be able to let the grid follow the surface on the organic forms, and also to get variation in the type of crosshatching/lines. This is not easily done - if at all - with the grid material. Then, as I searched the Darktree site, I stumbled upon this picture in their gallery: This seems to be excatly what I'm looking for. Alas, no information is given, except that the picture is made by Yith Moser. And I can't find this guy or any info on how this picture is done by googling. Anybody here know anything, or have any suggestions?
-
Thanks Rob! Exactly what I needed :-)
-
A quick one: is it possible to shift the position that a layer is rotating around? OR is it possible to assign a bone to a layer (without making any splines)? Need to swing a door (the layer) open.
-
Nope, did not work. A:M keeps on wanting to log on at program start, whatever the status of the community window at previous program termination. BUT, in the meantime I found the solution: using regeditor I found that the value "1" was set for "community/auto signin". Changing this to a zero, turns off the auto sign in at program start alltogether. And this setting seem to stick! If anyone have problems with slow program start, this does the trick :-)
-
Gerald, I have now tried to change the time out value in the reg base, and it worked! But unfortunately it only worked once! On second run of A:M the value somehow is reset to 20 seconds :-( So timeout must be written somewhere else, and poked into the register when closing A:M. Any idea? Isn't there a way to prevent A:M to communicate with the community server altogether?
-
Closing down the community window/tab, doesn't change anything in the load sequence. A:M tries to communicate with the community server no matter what. I'll try the register trick tomorrow (it is 3 in the night here in DK right now, so I better get some sleep) and I'm confident it will work. Thanks for the help :-)
-
When starting A:M up, the program suddenly stops loading, displaying this message: It just sits there for 20 seconds, then continue and complete loading. I am not sure if this is a new behaviour, but I think so. I then tried opening the community service tab in A:M with the purpose of changing what I thought to be a setting, so A:M would load without trying to connect to community service. I couldn't find any settings there, just the login screen. Then tried to log on, and guess what happened: yes, exactly: it halted for 20 seconds and then came with this message: I am not interested in using community service (from inside A:M anyhow) so how do I stop A:M from trying to connect, and thus start up faster? (Oh, and by the way, I AM connected to the internet, and I HAVE tried shutting down firewall and anti-virus - it didn't do any difference)
-
Malo, I found out, and I am just now trying out this nifty little converter. Have to experiment with flip u/flip v combinations, and when I open the converted .mdl sthraight into A:M 17 it crashes. Need to create a new empty model and then import the Troer-made .mdl into that, to make it work. If I can get it to work properly, it will solve a lot of problems. Thanks a lot!! And thanks Rob for the shift-key trick - I'll try it out shortly. And anyways the A:M .OBJ importer seems to be broken, so I guess that needs to be reported in Mantis.
-
Malo, that seems to explain a lot - there apparently IS a bug in the A:M importer! That means it can be fixed!! :-) What by the way is Troer??
-
I have several times tried to come to grip with the method you're describing, Fuchur, unfortunately unsuccesfully. When baking in A:M I can't choose the size of the maps, and ends op with some irregular and very small sizes. 200x100 pixels or something like that. And when exporting to .OBJ A:M asks me to rename the bitmaps to accomodate DOS naming conventions. Whatever my respond A:M crashes before it saves anything... Mack, you're propably right - I'm beginning to come to the conclusion that A:M is not suited to work with other software. A pitty though! Of course except for 3Dpainter. I own that program, but it has some major quirks that make it very difficult to work with, in my oppinion: It cannot paint across seams, except when in projection mode which on the other hand is painstackingly slow - on complex models I have experienced waiting times of 5-7 minutes. Completely unfit for a fluent workflow. And further development on that software seems to have come to a halt. So it seems the only possibility left is what you say, Rob: to hope that 3DC (or ZBrush) include .MDL importing/exporting...
-
Well, it isn't really about the shape of the UV-map. Wether it is split in islands or it is one continuus map or it is cut by hand or it is done as AUV map, the result is the same. As i stated above, and as you can se on these tests: Here I have split the UV-map by hand in 3DCoat: Here the UV are created by A:M as a cylindrical map (have tried spherical too) And the result always ends up distorted: Furthermore, if the model is even a tiny bit more complex then a vase, the cylindrical map method simply doesn't work, as the map splines of say extruding parts wil get overlayed UVs, PLUS the distortion.
-
Hmmm...interesting. But even so, I don't understand why this bulging and inconsistency in the widht of the stroke occur. In my oppinion it shouldn't. If applying paint to a UVed subdivision model (say in ZBrush), and you step down to the lowest subdiv level, no distortion happens in the colormap. A:Ms splines are not that different from a subdiv model - A:M even splits the models up in polygons when rendering. The problem here lies somehow in the way the UV-vectors are pinned to the spline-mesh/cage, I guess...
-
Oh, and by the way my software versions are: A:M 17.0g 64bit 3DCoat 4.00 beta 14 a1 (GL 64bit) ZBrush 4R5 PC/Windows 7
-
Having experienced some strange behavior when handling UV-maps in A:M, I am wondering if I am doing something wrong, or this is a bug. It goes like this: 1. I make a (in this case very simple) model in A:M. 2. Exporting the model (without UV's) as an .OBJ 3. Importing the model into 3DCoat. 4. ...and gets this automatic UV unwrapping. 5. Still in 3DCoat I then paint something on the model. 6. And export the model as an .OBJ with enclosed Targa color map. 7. Back into A:M I import... 8. ...and gets this distorted result - even if I render the model. The projection bulges and weave, and the seams are misfitted. 10. Looking at the model in A:M's UV-editor reveal the problem: the UV-splines are not coherent with the model splines, and they weave in and out of the grid. First I beleived this to be an error in the way 3DCoat generated the UV map but having tried same procedure in numerous other ways, including making the UV by hand as a single island, making the UVs in A:M (as tiled one-patch sized islands) and export them out of A:M together with the model, and trying all of these methods in ZBrush instead - every time with approximately the same ugly result. Well, that was my sad little tale - anybody have some input on this?
-
A last explanatory on this - then I'll shut up :-) The default interpolation selection feature, if implemented, would appear in the Options menu in the action tab, and it could look something like this: Procedure would be like this: Open A:M, select Tools->Options then select Action Tab. You then get the above choices. Make the appropriate selection - in my case I would tick "Hold". Go back, and make a Chor, import a rigged object and begin animating. Every keyframe set, will now have "Hold" as interpolation. Regardless what you animate. Every time you set a keyframe, it "looks" at what is ticked in the options panel and inherits this setting. If you go back to the options menu and check say "Curve", all the keyframes that we set in the chor just before, will still be "Hold", but any NEW keyframe we set will now be "Curve". We still have the choice to right click on any keyframe or group of keyframes we have set and choose another interpolation method for THEM. But if we do individual changes this way, and thereafter set new keyframes they'll still look at the current setting in the options menu and inherit the setting herein. Currently A:M works exactly like this, except that there is only one setting in the options panel, namely "Curve". One setting that can't be changed. Of course the standard setting when you install A:M should still be "curve" just as the rotation starts out set to "Quaternion". If someone is new to A:M, they would propably never see this panel anyhow, let alone change any settings. So the risk if people "breaking" the software would be absolutely minimal. All in all A:M would look and function exactly as it allways have done, with that tiny difference that crazy people like me could choose to animate the way that fitted their style best. And NOW I'll shut up!
-
Something tells me we are misunderstanding each other. I do NOT propose a general overriding setting for the keyframe interpolation. I'm wishing for a setting that tells A:M which interpolation it should WRITE INTO any keyframe it sets. Once a keyframe is set, changing the default value wouldn't change it - only keyframes set henceforth (unless the given channel was set to a locked interpolation) The keyframes thus set, off course should be changable to any of the other interpolation methods at any time (just as it is now). The instruction to change interpolation should still have the option to be set for all consecutive keyframes if so wished. In fact the only difference would be, that as it is now A:M ALLWAYS writes "spline" into any keyframe set - unless the user does something to change this on the objects intended for animation. I propose that this default value, when setting keyframes, could be chosen by the user. And off course it would be much easier to just set once and for all the preferred interpolation, and then later make possible adjustments. Some of the things you write, eg: "...don't have to change the whole character from Hold to Spline all together." "...and they won't be overridden by a global setting I might change tomorrow or that someone I send a chor to might have set differently." tells me that you must have got what I am talking about wrong. None of this would off course be the case, nor would it make A:M's animation system any less powerfull, as it wouldn't change anything (except of course the users ability to freely choose the prefered interpolation method, instead of having to change A:M's pre-destined choice) Furthermore it wouldn't slow down the animation either, as only the bones, objects, whatever that gets animated would need channels. If I'm still not able to make my point clear, then I propose to take a look at Blender which has such a system implemented that works just fine and straight forward. :-)
-
Wow!! A video tut all for me, personally!! That's something - thanks for taking the time. Rob! :-) Very clear instructions. And I agree that it is a nice workaround. But...it IS still a workaround, and multiplied over several characters with a lot more bones each, than in your 3-bone-example, it becomes somewhat cumbersome. Personally I would so much prefer to set this once and for all in the options menu. In the action tab one allready can set the interpolation to be either Euler, Vector or Quaternion, so why not have the added versatility to be able to set the keyframe interpolation?
-
Thanks for all the comments on this - I had almost forgotten the A:M Reports procedure for feature requests - I will post there. And, Rodney: good to be back again :-) A comment on the default spline interpolation "issue". Rob, I'm well aware how to set keyframe interpolation on individual (or multiselected) as you describe. But that is on keyframes that's allready there. I really miss the ability to set the standard interpolation right from the outset BEFORE any keyframes are produced. This could be done in the preferences. Why? Well, I animate EVERYTHING in holds (even camera and lights etc), just as one would do in an analog stop motion film. I typically animate in two's, sometimes in three's, so it is very anoying when the software starts interpolating, and a very tedious job to pick every single bone, of every character and every light, set a keyframe for that bone, and then right mouse click to designate the correct interpolation. Well, I'm aware that my animation method propably is pretty rare, but other animators might have the need to animate with straight interpolation, for instance, without to have to change individual curves either. So a preferences option to choose which interpolation method to use in general, would be VERY welcome. I really can't see what harm it would do to leave this rather important choice completely to the user of the software... Regarding UVs - I have experimented a lot with different setups: sculpting, painting and UVmapping in ZBrush and then importing into A:M (as the heads in the attached picture)...sculpting in A:M, export to Blender, unwrap and paint in Blender, then import back to A:M, or model in A:M, unwrap in ZBrush, then paint in 3DPainter (as the bodies of the characters in the picture). Wouldn't it be sweet though, just to have two easy buttons inside A:M: "Mark seam" and "UV unwrap mesh". Then load into 3DPainter and paint. :-)
-
Couldn't find any thread on this subject (?), so I'll start one here: 1) Ability to auto unwrap and save real UV-maps, including ability to mark seams. (Would save so much time and work) 2) Option in preferences to select default spline interpolation in action/choreography (Indispensable!!) 3) Option to select the visual representation of bones. Especially to stick-look. (Less cluttering when animating) 4) Ability to utilise multicore processors inside A:M. (Greater speed all around) 5) Ability to do graphics processor/GPU rendering. (Much greater render speed in some instances)
-
Thanks a lot for the kind words! Really exciting to get such good reception! With "Here" I'm taking another approach entirely than in "Trapez": The story is based on a dream I had, and I have started with sketching the visuals rather than writing down a strict narrative. The film will propably not have any lines or speak, and the pace will be very slow, flowing and...well, dreamy. Unfortunately some demands on the sculpting and other technical considerations have made me leave A:M - for this one anyhow. I will sorely miss the support and exchange from you guys, though. I must admit I can't remember how I initially heard of A:M. I have been using the program on and off for many, many years, starting way back on the Amiga when it was named Journeyman. I remember making some short clips for childrens television, 3-5 seconds or so, and it took weeks to render and drained the power of the Amiga even if it had a wopping 512 kilobyte memory!! :-) Well, it really makes me feeling old!!
-
While Trapez is cooking out there in the big festival world, I have begun work on the next digi stop motion "Here". This time with original script (by me). If you like a (as of yet) very small preview I 've made a blog for it here: http://heremovie.blogspot.com/
-
I have just received notice that Trapez has been accepted for the Aguilar De Campoo Short Film Festival (european section) held in Spain 3-7th december 2011. http://www.aguilarfilmfestival.com/ Keeping fingers crossed for the 3 other festivals Trapez is applying for!
-
Great! Thanks a lot!