This is a long standing bug … not being able to translate an object (camera, light) in local in the respective viewport. So, if the viewport is in Camera mode and I try to move it along it’s local Z to dolly, it translates along the world axis. If I try to translate a light in “O” (object) view mode along local Z, it simply rotates … it doesn’t even translate. :shrug:
I think 2.4c and d were good updates though, I’ve had far fewer crashes with these patches. And with all the updates to the renderer, I decided to finally give it a try and I have to say I’m really impressed. I understand now why Wegg and Taron are always gushing about it. I was going to render my short in LW but now I think messiah would be a better choice.
There seems to be another bug in regards to animating with all but the parent coordinate system. Rick found that when animating with 1 channel (even usining I, independant channel), messiah will make active keykrames for similar channels. For example, lets say you animate on the Y axis, messiah will also create active keys for X and Z.
You can find it in the same thread/issue I reported earlier about the active and inactive keyframes.
Curious, that should only happen for channel groups, if that method is chosen. I’ll check it out and we’ll look at it! It’s those funny things that recently all pop up, probably because finally you all get active, too. So those bugs are kind of like pimples and you guys are kind of like a special soap? HAHAHA…or something like that. So what happens is, now that you are applied, the little bugs come out so we can wipe’em off! :bounce: :argh: :drool: (kinda looks like hurling, doesn’t it?!)
I think that was just in regards to moving the key in time within the motiongraph’s curve stuff…guess it wasn’t generic enough to cover the dopesheet, too. Sure, good call! That sort of stuff makes me feel like a waiter or barkeeper at a 50’s diner, taking orders and sticking them on those white postits and spin it over to Fori and Dan, hahaha…
But I’m getting ready with a big, big can of worms for me to open by you guys, hehe…nice stuff, but it certainly makes me a cook again, too! :rolleyes:
Well, many of those things are there for a long time but you finally gave us back hope, so posting bugs is back in the “making sense” area and a productive task instead of being “on the list”
Oh man - that pimples analogy could be taken quite far, but I better resist >LOL<
Hey Taron, thank you very much for your fantastic spirit lately! :bounce:
This is how I always thought messiah should be developed
Ok here is a little list of things that could been inproved in Messiah!
I made this list yesterday when I was working on a real project in Messiah:Studio 2.4d
Some bugs but mostly workflow issues:
You can’t delete the active camera of two cameras. Messiah should automatlicly delete
the active camera and just activate some other camera! Or bring up a requester asking you
to chose wich other camera to use as active.
(Important!) Often when copying objects and objecthierarchies the meshes disappear!
We need a way to change settings for all surfaces with the same name at the same time, now you have to select all surfaces (Can be plenty of them) Think of LW feature: Surface by Object or by Scene!
When merging a scene I would like a requester so I can choose wich objects or lights or
cameras I like to import. Think of/look at, how 3DsMAX Merges scenes!
I wish improved filtering for the item list and the wievport, sometimes I just want to
see my Lights, only bones or just objects!
I would like to be able to group objects, so I can have a “package of items” under just
one item, see grouping in 3DsMAX!
I vote for instancing as a alternative to copy, again se 3DsMax: When you do a copy you get a requester asking you if you want to do a copy or a instance!
I want to be able to save the last rended picture from the preview window! And also a feature to switch between the last render and the previous! And the ability to see the alpa
in the prewiev window!
You can’t delete all selected surfaces under one or more surfaces, in the surface list.
This would be handy: If you doubleclick on a “MaterialBall” in the material tray, that
material could get applyed to the current selected surfaces!
The preview settings aren’t saved with the scene, very time-consuming when jumping
betwen different scenes!
Control-drag limeted-region often “jumps away” from the mouse-pointer and the
interaction is slow and clumsy?
If the same material and suface name exist in two scenes, then after merging one scene into the other, you got a duplicate of the surface, not so handy if you like to edit the surface! For object import this works grate when Messiah makes no duplicates!
When using limeted-region I like to have the prewiev-window to get the size of the
limeted-region! I use this often to tweak the rendering quality of hires-pictures, and I
hate when a BIG-black windows cover my whole screen!
If the preview window is to big to fit on the screen the window size should be scaled
to fit the screen. And it should be scaleble!
If I deactivate say Pitch on an item, I still can rotate in pich if I’m using the “r”
on the edit sphere!? Not what I want! I want that pitch-channel Deactivated! This is true
for all deactivated chanels…
It would be handy if we could save multiple selected objects as one mesh/object, I
often need to do this to check the position of things from the scene when modeling.
The current active camera should stay active when merging another scene, cause they do not in current Messiah!
I like to be able to: right-click on an object in the item list and choose: Replace!
It would be good to have a little handle in the midle of the limeted-region so you can
reposition the whole region in one click and drag!
You can’t undo delete material.
I miss a weight-painting-tool or support of weightmaps, this is the main thing I miss
in Messiah and still keeps me going Maya or LW for character work!
And… (yes I added this now…) FreezeTransformation, to zero-out the setup position of items!
Keep on working!! The new Messiah 2.4d works better than ever, I just had one chrash at work yesterday! :wip:
/ Svante
another little annoyance, the * b utton is used to clone objects.
it is also used to clone expressions…
but try using it on armatures and you find that it does nothing!
but when you switch over to your item list…you see a bunch of copies of a bone, or worse a higherarchy!
REALLY glad to hear that you’ll let the gys know about the inactive keys becoming active when moving dope master keys - That really would be one cool bug to remove!
wowee…big list! I’ll look through it a bit later tonight, just a quick note to the two “bugs” about keyframe moving and creating…
I can’t confirm them, but I can explain:
if you move an object along it’s local coordinates, it actually is only a helper for you to move it, while in fact this kind of motion could require the translation of more than one axis! If an object for instance is headed and pitched, a local motion along X would in fact move the object along all axis and needs to create X Y Z information in a key, therefore creating a key for all these channels. It’s actually logical and can not be changed if you want to continue taking advantage of the “on the fly” ability to switched between local and world coordinates! Trust me, when I say this, but you most likely wouldn’t want to have it differently. Having it differently would be an equivalent of making a Null object as a parent to the object you want to move and key on only one axis, while rotating it only through the Null. This would simulate the procedure a lock to local coordinates would amount to!
SO … not a bug!
As for the doopsheet timeshifting of keys, I can not confirm that it would activate inactive channels of a key. Works perfectly fine here! So I don’t know what you’re really doing, but I hope you are running 2.4d!!! :shrug:
Again, I’ll look through the big list in a moment!
But THANX already for making it!
Damn, that’s a fantastic list! Looks all right and applicable! That certainly puts us to work for quite some time, hahaha. We should make a poll on us focusing on making all of this work as opposed to doing anything else, hahahaha. No really, it’s a fantastic list. What I like about it most is the fact that it really highlights things that we’ve neglected and in some cases have simply forgotten. It all sounds familiar though and best of all it all makes sense. Just the instancing thing I’m not sure about, because it’s more of a radical addition, I think. Out of experience I’d say, this would probably be the last list item we’d take care of, but that’s just my feeling. Wouldn’t be the first time that I’m completely wrong and it turns out to be among the first things, hehe, but yeah…
List filters sounds like such an ordinary thing, I’m all for that one, too.
The surface and material list management really needs some work, that’s for sure!
Well, I shouldn’t even start with an item by item reaction, because it mostly would read like this: Yes, excellent, totally, right, I’d want the same, thought about it already, sure thing…etc…etc…
SO: GREAT, we’ll examine the possibilities for a short term realisation and what would take longer to do! :wip:
I really want to see this issue adressed, but I’d like to point out that keeping these keys inactive is not what you actually want 90% of the time. If you’re working on timing in the dope master, moving a key in one channel without altering the other channels can alter your animation, not just the timing, because the channels will go out of sync.
I find that most of the time the problem is not that they get activated, but that they don’t get activated to a value they had while inactive, but to a value they had when last active. If you purposely inactivated them to smooth out a curve or whatever, they will snap back to their original (wrong!) value when they get activated by dragging keys in dope master.
I’m not sure if my explanation is clear enough, please tell me if there’s any confusion and I’ll put up some screenshots to illustrate better.
Anyway, what I’d really like to see is a “key activation rules” dropdown, so we can select between the way it is now, no activation whatsoever, and sort of “activate in place” option
that would create a key in channels that don’t have it instead of just activating it (the same thing I’d get if I pressed create button in that channel). So if I dragged a key in dopemaster it would first create a key on all channels, then move them to a different position (creating a key after moving would get me the same thing as not activating them at all).
Also, it seems that alot of people (including myself) run into this issue: To parent in place, you have to go into tools and select parent and check some boxes to enable the parenting in place and then click another button - after selecting the objects to parent. It would be great if there was a universal PIP toggle that always showed up on the screen (an armature like the ones we have already), this way you could toggle parent in place or keep rotations quickly. Most importantly though - messiah would respect this setting even with drag and drop parenting…
No drag and drop, but a PIP armature button is already possible - just create a handle and assign the parentInPlace command to it. There are some other parent/unparent commands as well.
Now we just need that dynamic parent in place solution hint hint
I don’t mean to sound like a dick, but how do you know what I want 90% of the time? I made those keys inactive for a reason. They should stay that way until I decide to activate them again.
