Noel
-
Posts
587 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by Noel
-
-
You should be able to turn this off with the camera's "Camera Frame" property.
-
I've made the assembling actionfile for the proxy to be:
\Shared Data\Models\Set_chors\ku-klip workshop\Ku-Klip_Shop_proxie\KKlip_inside.act
the proxy foundry model is set to be:
Shared Data/Models/Set_chors/ku-klip workshop/KU-Klip_final/KKlip_inside/models workshop/foundry.mdl
I was going to relocate the files and save the projectfiles for the sequens, but there where missing some other actionfiles on the ones I tested (lip sync and so on), so I didn't dare to save them
Thanks Stian
Martin if you want I can do a search and replace in 2_07 to fix them all.
Just let me know.
-
To get it to work for 2_07_57 I used
LinkedModel=../../../Shared Data/Models/Set_chors/ku-klip workshop/KU-Klip_final/KKlip_inside/models workshop/foundry.mdl
LinkedAction=../../../Shared Data/Models/Set_chors/ku-klip workshop/KU-Klip_final/KKlip_inside/Workshop.act
-
To clarify:
To see what I was running into load 2_07_06.cho. You will notice that it uses the proxy set which now is missing files.
So any scenes that use the proxy set will not load.
We either need to go to each of those scenes and use the final set like the current revision of 2_07_57, or make the old proxy set work.
Or, these files were moved and or renamed and just need to be browsed for.
Affects most scenes from 2_07_06 through 2_07_105
These are the actual files that the scenes use:
LinkedModel=../../../Shared Data/Models/Set_chors/ku-klip workshop/Ku-Klip_Shop_proxie/KKlip_inside/models/foundry.mdl
LinkedAction=../../../Shared Data/Models/Set_chors/ku-klip workshop/Ku-Klip_Shop_proxie/KKlip_inside/KKlip_workshop_inside.act
Thanks
-
Dito, good looking stuff!
See the following link for a question/issues.
-
First of all cool looking stuff Stian.
My assignment this week is 2_07_57, but with your latest changes it won't load.
This scene was using the proxy set, so I thought I would switch to your new final set, but the action object action to populate the set is embedded in your project.
So I guess there are a few issues, (unless I'm missing something, [its happend before])
1) To switch to the final set I saved the workshop action wth all the actionobjects into
Shared Data/Models/Set_chors/ku-klip workshop/KU-Klip_final/KKlip_inside/Workshop.act
That way I could text edit my file and swap the proxy foundry model for the real one, and the action that you deleted for the one I just saved.
This worked.
2) Do we need a proxy set for this sequence?
Or do we need to load all scenes that used the proxy set and replace it with the final one?
3) In the future it would be nice if the final and proxy set models and populating actions that are already being used were just modified instead of replaced or removed. That way the set changes would seem seamless to the animators.
Thanks
Noel
-
I update regularly also.
There used to be a way to change the way tortoise works that was easy to switch during the install. This caused some trouble, but seems to be removed from the installer.
A recent version changes the way svn stores info in the localcopy, this doesn't cause any trouble that I know of unless you try to use your localcopy with the older version of tortiose (like if you have a usb drive that you move between systems).
So my advice is to upgrade as they are always fixing things with tortoise, and the risk of having to download the data again is low.
-
Yep, that file seems to be missing.
-
Anytime you are assigned something, especially something that affects multiple scenes. You should make sure you have a dotproject task for it in your dotproject todo list.
That way if someone else decides to change something that may effect what you are doing they can look in dotproject without having to search the forum.
This reduces the chance of conflicts, and confusion.
Thanks for looking out for me Nancy. You didn't do anything wrong, just a heads up for everyone.
I made sure the task is assigned to you in dotproject now.
Have a happy holiday everyone.
-
Here are my notes on what I did.
Here is the latest 1_03_34 wip mov.
See first post if you want to compare the two.
My call is that it is two steps forward one step back.
Thanks.
-
Noel this looks excellent!
Do you form your own phonemes or use the dope sheet?
I agree with Nancy about all she said.
All I'd suggest is to possibly change the anticipation of the hand raise from when he says begin, to start at "ask". This would emphasize the "ask quesitons" part of the statement which is the point I believe Scarecrow is making.
George
Can't take any credit for the lipsync. From the svn log that was tacoballz.
Thanks to you and Nancy for the suggestions. I'll see what I can do in an hour or two.
Noel
-
Ok, got that. I tend to fill my local TWO folders with variations on models that I play with as well as maps. I assume:
1) when I update my local folder, that the svn will not touch my local files that I haven't added to the svn, and will just try to update those files that are being controlled on the svn and will add any files in the folder that are missing, but not redownload those that I already have and are the same as those on the svn. TRUE?
yes
2) I assume update means it will try to incorporate my changes locally of a controlled file with changes that are on the svn and that if it can't it will produce an error warning TRUE? And, as well, will crap out my local file. As it has done. Which is why I always make a backup copy of a different name before I try update.
For the most part if it updates and merges someones changes into a file you happen to have changed since you last updated it isn't a problem. But if you feel safer backing up before you update, feel free.
a) If I am ok with losing my local modifications of a controlled file, I should choose Revert on this crapped out controlled file. TRUE?
yes revert takes anyfile back to what you got on the last update.
If I want to retain my local changes of a file that I updated previously (without problem) - made changes locally and someone in the 30 secs that I took to make my changes has committed a new version such that I get an error when I try to commit. Then I should call for help. TRUE? but first do a update, get crap files and get .rxxx, .mine files to send to you? TRUE?yep, thats called a conflict. If you are sure you didn't mean to work on that file you can revert it. otherwise I'd like to see the conflict files, even if you are sure you just want your changes. Then its up to you if I help you resolve the conflict, or do it for you.
.hinfo files are designed to be the part of the file that shouldn't be commited. If you update and get one, or accidently commit one, use svn to delete it (with tortoise, Explore to that file, right click and choose tortoisesvn, delete. Then commit that folder and it will delete it from the svn repository so it goes away with everyone else's next update).
Oy Yoy.
I have hinfo files on all my controlled files. I have never tryed to commit them, delete them, or do anything with them. I just thought that was what was telling the svn that there was a file that exists with same name when it really isn't there (as I had deleted the file, not the hinfo). And I was asking perhaps that I should delete the hinfo file as well so that I could just get the svn file.
What is NEW info to me - is how to delete files - I have been using the standard Windows delete, rename rather than Tortoisesvn delete, rename....I did not know there was a difference and perhaps the tortoise delete actually does remove the hinfo file as well. TRUE? And perhaps here is where some of my sins lie.
Uh I may have confused the issue here a little bit.
svn knows nothing about .hinfo files. They are created by A:M to store stuff like window position that would cause conflicts. So they are designed to not be commited.
There is no need to delete them, unless they are acidently committed. then they should be deleted with svn.
Thanks Noel, this must be very trying for you to have to deal with some of us clumsy fingered addled brain inarticulate incompetent boobs.
We appreciate you and hopefully you won't develop a drinking problem.
No problem.
-
Hi TWOers.
Here are my notes on what I did.
Here is this change 1_03_34 wip mov [attachmentid=22348].
Here is its current state if it has been changed after this post
Any suggestions on how I can improve it tomorrow?
I would probably concentrate on the fingers.
Thanks
-
just delete the local file that it is complaining about. This happens when the file gets updated on the server with the same name, but with a different upper/lower case. It thinks the file already exists on your machine and throws the error.
So if you delete your file on your local copy, and update again, you will get the latest.
Should one delete the filename.hinfo file as well? Is that why svn thinks there is still a copy?
However if you delete the filename.blah (and maybe it's .hinfo file) - then how does one just get the file and not have to download the whole folder (at the lowest node of the folder hierarchy)?
Perhaps one should just rename the local (bad) file to use caps (or whatever the name is on the svn) and perhaps it's hinfo file? & then select revert (which I assume means to revert my local file to the one currently on the svn and not a previous version on the svn?).
Gawd, what a mouthful...
I am only adding to this thread because I run into funnies as well and am trying to understand how to use the svn, and this might be related to what Robcat is running into. I do not want to disrupt getting Robcat's problem solved, if it's not related.
After deleteing a file that svn complains about, you just need to update the folder that contains that file.
To do this with tortoise use Explorer to find that folder and right click on it and choose svn update. Then you can try updating what ever you were doing that gave you the error.
.hinfo files are designed to be the part of the file that shouldn't be commited. If you update and get one, or accidently commit one, use svn to delete it (with tortoise, Explore to that file, right click and choose tortoisesvn, delete. Then commit that folder and it will delete it from the svn repository so it goes away with everyone else's next update).
-
If your models folder has an svn icon overlay in explorer, then update just it.
If it doesn't have an svn icon overlay then you'll need to check out each sub folder under models that you need.
If you do a partial checkout of just say
shareddata\models\actors
shareddata\models\props
That means that shareddata\models\ itself is not checked out (no svn icon overlay)
you can check out other subfolders of shareddata\models\ into shareddata\models\ like
shareddata\models\Set_Chors
If you then want to check out
shareddata\actions
you can, but not by checking out shareddata you must checkout shareddata\actions on its own.
So if you want to get something that you don't already have in a folder that does not have an icon overlay you must either delete that folder and check it out to get everything, or check out each of its subfolders that you want by hand.
A:M's repository browser will show you what you've checked out with it, but if you have checked out things with tortoise you'll have to use the icon overlay to tell if a whole folder is checked out or not.
-
Corrected some info in the above posts.
Contributors shouldn't generally need to edit the task. just create task logs. Awaiting aproval can be set in the logs.
Thanks
-
Is someone else working on him again? Since I got him yesterday? Or is something else going wrong with how I am doing this?
Hi again.
BobC fixed a bad material path at around noon yesterday.
So Either you already had a conflict or you didn't update right before you saved your copy of tinman over the real one. (Typically you souldn't save a file over an svn file, but instead, update, load, modify, save, commit. But this was a special situation)
Anytime you update and get a conflict warning you should resolve those confilcts as soon as possiple.
If anyone is unsure about how to resolve a conflict see http://wiki.hash.com/two/published/SvnConflicts
I coppied the file you sent over tinman, fixed the material links, and commited it.
Thanks Nancy.
-
Hi all,
I think I fixed Nancy's deboned problem, but may have lost some of KenH's work.
Ken if you want to check that, and log it as a problem in the link below, if it is a problem that you can't repair on your own.
http://www.hash.com/dotproject/index.php?m...d=716&tab=0
If you need to repair it, ask Nancy to commit what she has, and wait until you are done. and start with that version.
If you need me to repair it please add a note to http://www.hash.com/reports/view.php?id=3965
I also noticed that the above dotproject task was unassigned.
I assigned it to Nancy.
The following are some suggestions to reduce conflicts. They aren't directed at anyone in particular, just something we all should keep in mind.
To reduce svn conflicts people editing a model should first make sure they are assigned to that task, or corridinate with the assignee.
Update before starting a specific change.
commit after a specific change.
Basicly any time you think your work is better than the last update you should commit. That way if you happen to make a mistake some where we can always go back to an earlier commit.
If two people are working on the same actor at the same time and don't want conflicts they should coordinate like this.
Sally Is assigned a task. Updates makes a change.
Thom says to Sally, "I'd like to change this."
Sally says "sure I just committed my work, let me know when you are done."
Thom updates, changes, commits, and tells Sally.
Sally updates and continues with her changes.
Thrown in this mix is modelers and riggers/posers. Of course modeling and rigging should be done before texturing, but sometimes adjustments need to be made. Those changes should be coordinated with the assigned texturer/texturette.
phew. (wipes brow)
Nancy It looks like email from us to you probably isn't getting to you.
See http://www.hash.com/reports/view.php?id=3965 for info on that report.
Thanks
-
KU-Klips beard and hair have disappeared or is invisible. That should help with the lipsynch but I don't know how I'm going to get it back.
Try pressing the shift+8 key aka '*'. It toggles Draw particles/Hair.
-
We'll look into it.It'd be cool if someone could program a widget to automate the creation of the reflection map. Something like an action in photoshop, but in AM which goes and takes probe shots from Tinman's location and applies them to his materials. Then it'd all be lighting the scene again.Please submit a feature request with the data (text to svn revision and scene number, or a zip of what you have if its not on svn) And what the existing workflow is, and what you think the workflow would be with this feature.
Thanks
-
So I guess that there are 4 things to choose from.
Make adjustments to my existing knee lift.
Don't do the knee lift if the screen shot above looks natural enough.
Or try KenH's clasped forearms with elbows on knees?
Or its good enough for this pass. (I don't think so)
Thoughts?
-
I don't think he's bent too much. His left hand could use a little extra touch though, when it moves up from his knee to his cheek. When I move my hand that way, it doesn't move in front of my face, it just makes an arc from the knee up to the cheek. Also my fingers are curled as my hand moves and uncurl only when they are about to come into contact with the cheek.
Not bent to much where? (the mov or the initial screen shot) I wasn't to clear in my last post, so I edited it to have a screen shot with the knee lift from the mov, and without the knee lift from A:M.
I agree with the finger bends. I actually do put my hand in front of my face when I do it, but I probably should record my self so it looks more natural. I think the problem there is a combination of timing, and fingers to straight like you said.
I think that with out the knee lift his the back of his head looks to jammed into his back.
When I try it my self my neck is fully bent back, and I must lift my knee to aim my head up.
What do you guys think?
Thanks
Woot's elbows are way too far up his arms. I'd scrap that move as rather than looking comfortable it looks painful. I'd go for something like this instead....
This sounds like I'm being an a** (yeah but your pose is na na na) but I'm not meaning the following that way. I think that your pose looks like he has a stomach ache and he is bored with what he is listening to. I just animated what I thought I would do in this situation.
I'm not in love with my pose, just like it better so far.
Thanks
PS Edit folows--
Yours would proabably work better if it looked like he had more weight on his elbows, and I guess bored is just his head angle and eyes.
So I'm willing to try that this evening if others agree that I should.
Thanks
-
Hi In incorporated most of the suggestions.
Not lifting the leg bent him over to far or bent his neck to much.
What do you think?
Here is the 1_03_45 wip
[attachmentid=22116]
Here is a screen shot of with out a knee lift
[attachmentid=22117]
Here is a screen shot of the above wip with the knee lift
[attachmentid=22136]
-
Hmm, I'm unsure why you have tinmans right arm rotating to thoses extremes. Also there should be shoulderpad bones showing, to make adjustment to them. Scarecrow looks good though, but I'm not an animator, so what do I know.
I was just trying to straighten his arm out for balance, but his elbow should probably be in a more natual position. Good point. (my elbow can do that when my arm is staight bu your right it doesn't feel natural).
I think we should consider adjusting the shoulderpad rigging so that the pads remain up. ie parented to the torso/shoulder not the bicep. Or the shoulderpad bones should be visible by default, but in the animations I did I think that the shoulder pads shouldn't have moved, until the seccond pass of animaiton, but instead they spin around with the arms motion. Probably something that should be looked into by a more experienced animator, and disscussed with the tinman rigger.
Thanks
ku-Klip workshop changes and existing scenes
in TWO Sets
Posted
I did the search and replace and commited yesterday. This should be resloved now.
Thanks Stian