I'm losing chor constraints between models when I close...

[rusty]

Hi,

 

I'm not sure this is a bug or a restriction or due to a model creared in an eariler version or model corruption or perhaps the way I'm doing it. Anyone seen, know anything about or have a work around for chor constraints that won't work after you save/close/reopen. These constraints are from one model to another model to bones deep within a char rig.

 

This is a huge deal with my current project and any help from the community would be greatly appreciated!!

 

Thanks!

Rusty

[robcat2075]

As always... If you can post a sample PRJ that does it, that will make it immensely easier than someone trying to reconstruct it from the description.

[robcat2075]

A generic test of constraining a bone in one model to a bone in another model survived being saved and reopened, so we'll need to know more about your case.

[rusty]

A generic test of constraining a bone in one model to a bone in another model survived being saved and reopened, so we'll need to know more about your case.

 

robcat,

 

I've attached the project file and a readme Word document that explains the project file (both in zip file).

 

Thanks,

Rusty

 

Head_Attachment_Test01.zip

[Dpendleton77]

Thank you Nancy. I will look back into this when I get home.

[NancyGormezano]

Thank you Nancy. I will look back into this when I get home.

 

Uh, you're welcome...but I suspect you have accidently posted in wrong thread...this thread is probably what you want

[robcat2075]

I'm looking at this now. The empty, unnamed folder under the second character is concerning.

[robcat2075]

As far as I can see the constraints are working when I load the PRJ.

 

Here's what I see...

 

RustysConstraints.mov

[NancyGormezano]

Here's what I see...

 

Uh that's weird...because I see something different when I first bring up the project (17g-32). Did you change the head control bone?

 

But besides that - I too find that the constraints seem to be holding fine.

rustyh264.mov

[robcat2075]

Here's what I see...

Did you change the head control bone?

 

 

I changed the animation in my video because the original motion was too small to make it obvious if the bones were following. But it does survive saving and reloading.

[rusty]

Well, I'm flabbergasted but somewhat relieved but totally confused. I opened the test I posted (which definitely failed when I posted it) and...today, it worked. How this could happen is beyond me.

 

I reconstructed the entire thing and it failed (see attached). However, I did realize that there's a difference I didn't mention--though I do not know how it could affect anything like this. When I put the project together (in every case but the 'test' I sent), I'm on my notebook but all the files are on my desktop--I'm going to a network drive via a wireless network. The test project was saved locally on the C drive of my notebook but as I said, it failed before posting it and just to make me crazier then I already am, worked this morning.

 

I will definitely test it on my desktop later today (all files will be local) and see what happens and let you know. And, to be just as crazy as this problem, I'll recreate the test project and see if I get similar results (i.e. fails one day, works the next).

 

Also, I'll look into the unnamed folders. I certainly do not want to rebuild the models but perhaps I can get into the model file with a text editor and look for anything weird.

 

Thanks so much for your time...an hour after posting this the thought occurred to me 'watch, it will work when robcat tries it' but tossed out that idea immediately as totally crazy.... I think it's karma for all my sins.

 

Cheers,

Rusty

 

[robcat2075]

It's like on "Bewitched"

 

"But Abner... there WAS an ELEPHANT in Mrs. Stephens' back yard! I saw it with my own eyes! It was there five minutes ago..."

[rusty]

Well, it doesn't work on my desktop either. I've tried saving in a chor. I've tried embedding/not embedding. I've tried using intermediate bones. I've tried renaming the models, the bones, the project. There's no rhyme or reason. No hope for a fix. I will not spend two months redoing the models especially with no guarantee that anything will change. It's hard enough without stuff like this. Honestly, I'm so disgusted with everything right now that I'm just going to put animation away for a while.

[mtpeak2]

Well Rusty, the first thing I noticed, in the image you posted above, is that there are no targets selected in the constraints for the head proxy. The second thing is, in the project there are targets selected in the constraints, but you selected the control bones (torso and head control) you should have these constrained to the spine5 and head bones (both geometry bones). Control bones will pull away from the intended positions.

 

If you need help setting things up, I could give you a hand.

[robcat2075]

Take a deep breath... and let Mark help you.

[rusty]

Well Rusty, the first thing I noticed, in the image you posted above, is that there are no targets selected in the constraints for the head proxy. The second thing is, in the project there are targets selected in the constraints, but you selected the control bones (torso and head control) you should have these constrained to the spine5 and head bones (both geometry bones). Control bones will pull away from the intended positions.

 

If you need help setting things up, I could give you a hand.

 

I appreciate your offer to help. I really do. And I would (and may) gladly accept your help--beyond this problem I could desperately use some help. Using A:M to create book trailers (regular work with good income if done right) is right there at my finger tips and I'd probably need to hire many from the forum to meet demand. I've been working towards this for 11 years.

decent one, for my own book, was a spectacular success within the writing community ("best trailer I've ever seen", "Jesus how can I get one", "what does it cost")! Of course the last is the challenge.

 

However, the bottom line regardless of absent targets in the screen shot I happened to send and regardless of what bones were used, is that

 

1. I have tried this over and over again for a week and before saving I got exactly what I expected to get but, after saving and reopening, the constraints (both still there and with the same targets), did not work.

 

2. At least three other users did not see this problem at all, and I'd bet no one else would...while I on the other hand, on two different PCs, with two separate installs and with two different licenses (both of course belonging to me) consistently did not work.

 

In my 11 years with A:M this is the 3rd time for this same anomaly. Think about that. What are the only ways such a thing could possibly occur? "...when you have eliminated the impossible, whatever remains, however improbable, must be the truth?"

 

Understand, this is a bad month for me; our dog who we love like family is dying, I have two torn rotator cuffs which, every day, grant me with a ridiculous amount of pain, oh... etc. etc.

 

Forgive me for unloading on you--I'm at the want-to-scream and tear-out-my-hair end of my rope. I need a least a couple of days worth of very DEEP breaths. No one should be talking with me right now. ;-(

 

r

[robcat2075]

I'm still not clear on what you are doing differently that makes it not work for you but still work for me.

[robcat2075]

I'm also not clear on why you need to constrain one character in place of another. There's got to be a simpler way to get this done.

[rusty]

I'm still not clear on what you are doing differently that makes it not work for you but still work for me.

 

Neither am I--that's what makes this impossible. However, I had one thought: I'm using the 64 bit version...are you and Nancy?

 

Rusty

[robcat2075]

However, I had one thought: I'm using the 64 bit version...are you and Nancy?

 

64-bit here

[NancyGormezano]

32 bit

[rusty]

I'm also not clear on why you need to constrain one character in place of another. There's got to be a simpler way to get this done.

 

I'm not sure I understand your question. Perhaps it is this: why am I attaching a head model to a body model? If so I'll give you the 'medium' answer: Writers and publishers won't pay much for book trailers and so I can't afford to build character models. I must instead use a set of 'virtual actors' from which clients must choose. If they want a custom character, it will cost them.

 

Virtual actors are just bald un-textured heads fully rigged with expressions and flattening poses.

 

Everything else is separate, prebuilt and 'snaps on' to the basic head.

 

Everything below the neck is wardrobe: pre-built, 'Snap-on' outfits. The 'outfits' them selves have Snap-On texture decals and pose controlled additions. Shoes are also 'Snap-on'.

 

Hair is the same--prebuilt hair-dos (all white, no color) with 'Snap-on' pre-developed colors. All interchangeable.

 

Same with face maps: pre-developed face maps for color (white, tan, black, brown, yellow), scars and character age (how many wrinkles).

 

Do to standard head construction you also get standard decaling ( or flattening) poses and therefore, standard mask shapes (granted not in all cases) and so almost all 'Snap-on' elements are interchangeable among all 'virtual actor models' though gender and head shape demand some separation.

 

But I digress...There's a whole lot more beyond 'virtual actors' but this is a topic I can discuss all day. It would mean that an entire cast can be assembled in a day or two. I've been working on all this for 11 years. I'm close to having the processes all nailed down. All of it centered upon and using A:M. If I can't use AM there's a huge part of my life wasted. It makes me dizzy how much I depend on AM.

 

Connecting the head to the "wardrobe" is one of the last things to nail down.

 

r

[robcat2075]

Are both characters rigged the same?

[rusty]

Are both characters rigged the same?

 

Well, one character is the body using Anvovin's thingy and the other is model is a head using the newer bone rigging method.

 

I will also try something else that might be a difference between myself and all of you: I installed the 'g' update over the older version.

 

I'll try a fresh install...hope there's no hassle with the new licensing system.

 

Thanks,

Rusty

[robcat2075]

- if they were the same rig then you could just reuse the animation from one on the other without having to use any constraints.

 

-It's really clear to me that even when the constraints are working, the wrong bone is being targeted. Are we sure that that is not what you are seeing and not a failure of the constraints?

[rusty]

- if they were the same rig then you could just reuse the animation from one on the other without having to use any constraints.

 

-It's really clear to me that even when the constraints are working, the wrong bone is being targeted. Are we sure that that is not what you are seeing and not a failure of the constraints?

 

Tying the head proxy of the head model to the head control of the body model would, as far as I can see, would do everything needed. There maybe a lower level head bone that the head control drives and this might be more 'proper' but other than that I see no difference. ??

 

The other bone constraint was just a first stab at the problem...it might even work with some tweaks.

 

In both cases the control bones would control both head and body.

[robcat2075]

The other bone constraint was just a first stab at the problem...it might even work with some tweaks.

 

the torso targeting is the one that was clearly targeting the wrong thing. In TSM2 the torso control has no geometry solidly attached to it, it only influences the end of the spine

[rusty]

More news...

 

Why would the same thing fail on my two PCs and work for everyone else. One could have been 32 versus 64 but...nope.

 

Another possible explanation is how V17g was installed. I installed right over the previous edition.

 

**************What did you guys do?

 

The next one is that we really weren't trying the same thing, ergo:

* the path to the files.

* I stripped out all the images and materials on the one I sent.

 

Yet I failed on this test version too on the day sent but it worked the next day...this is too insane to contemplate.

 

I uninstalled and removed the files AM and reinstalled it. My first attempt seemed to work but I realized that the models were not embedded as the test models were. When I embedded the models...it failed.

 

I've planned out more tests, will let you know.

 

*************** If anyone can think of what other differences besides PC model please ring in.

 

Cheers,

Rusty

[robcat2075]

I swear all i did was open the PRJ you sent and then tried to find what was wrong but I never found what was wrong because it was working.

[Rodney]

If anyone can think of what other differences besides PC model please ring in.

 

There appears to be something different about your workflow.

I have several theories but not enough information to speculate much further.

 

At a wild guess I'd say that you are not using the saved Choreography that maintains the constraints but I don't know why that would be.

When animating.... or wherever you are experiencing the problem... are you ever creating a new Choreography?

 

One could have been 32 versus 64 but...nope.

 

This was not likely to be the problem (not impossible but less than 1% chance)

Likewise, it is probably (that is to say a high probability) not due to installation.

The problem with pursuing these lesser options first is that if the problem gets fixed you might inadvertently credit the wrong thing for the fix.

If someone suggests formatting a harddrive... I swear I'll roll my eyes all the way around my head.

 

Yet I failed on this test version too on the day sent but it worked the next day...this is too insane to contemplate.

 

It is likely that you are doing something different in each of these cases.

If we can find out what that difference is then we'll be in on the fix.

As that is workflow/location specific we need more information.

Perhaps you can screen capture your attempts?

If you don't have a good screen capture program try screencast o' matic.

[rusty]

Update:

 

(And btw, the following is the work flow)

After a fresh install of AM Nothing changed. I opened a new project, imported the 'head' and 'body" models, created a chor then implemented the constraints, I visually reviewed them and tested them, everything worked. I saved and exited AM.

 

I then realized I'd messed up--all tests to date had everything embedded in the project. So heck, lets see what un-embedded does.

 

I opened the project and my constraints WORKED.

 

So... I repeated step one but embedded everything, set constraints, tested, closed and reopened. Constraints FAILED.

 

I ran two more test embedding one model then the other model. Both WORKED!

 

Note: as rule I always embed everything always--you probably know the reasons.

 

Based on this, only on my PC (just one, didn't try both), and at least for tonight anyway, when

* everything is embedded, it fails.

* if any one model is embedded, it works

* if neither model is embedded, it works

 

Does that tell anyone anything at all? It indicates that only on my PCs, if the program gets too big it fails. This seems easy to test but... tomorrow for that.

 

BTW, if any of you think I'm doing something out of the ordinary or not looking at it right I'll be happy to do a Cross Loop desktop sharing and optionally an ooVoo video/voice to show you on both my PCs (the mentioned utilities are free and easy).

 

Cheers,

Rusty

[Rodney]

Apologies for retyping what you've already typed. I'm going through line by line to see if anything stands out.

 

 

Workflow

Create New Project

Import the 'head' and 'body" models

Create a Chor

Implement constraints

Visually review and test constraints to ensure everything works

Save Project (unembedded)

Exit A:M

(Note: This workflow worked/works)

 

Problem: All tests to date with everything embedded in the project did not work. (although sometimes they inexplicably did)

Repeating the above steps but embedded everything, set constraints, tested, closed and reopened. Constraints FAILED.

 

Question: I'm curious... did you embed again before saving and closing or only before setting constraints?

 

 

Two other tests:

Embedding one model first then the other (in separate tests) results in the constraints working in both cases.

 

Results:

When everything is embedded, the constraint(s) fail.

If either model (but not both) is embedded the constraint(s) work.

If neither model is embedded the constraint(s) work.

 

Query: Does this indicate that only on my two PCs and only if the (file?) gets too big, the constraints will fail?

I don't find that to follow logically. As you say this should be fairly straightforward to test.

 

The only thing that stands out to me at this point is that you may not be fully embedding all the files in your Project *after* you have set the Constraints. If this were the case then when opening the Project again the Constraints would not work, just as they are not working in your specific case. When dealing with pre-saved models that are then embedded into a Project there is a chance (due to many the variables of workflow) that the models are not actually embedded.

 

I would be also curious to see if saving/reusing only the Choreography would maintain the constraints.

Rationale: You may not need the whole Project if you only need the Choreography

Precedent: Chors were used instead of Projects in Tin Woodman of Oz.

[robcat2075]

Based on this, only on my PC (just one, didn't try both), and at least for tonight anyway, when

* everything is embedded, it fails.

* if any one model is embedded, it works

* if neither model is embedded, it works

 

Does that tell anyone anything at all?

 

It's a curious circumstance. Everything was embedded in the PRJ you sent us but it worked as expected.

[rusty]

Hi Rodney,

 

Thanks for chiming in and I hope this finds you well and happy.

 

Question: I'm curious... did you embed again before saving and closing or only before setting constraints?

I'm a fiend for standardized workflow. For my 2nd 'embedded test' I started a brand new project and followed my standard workflow which is to open everything I need then do 'embed all' then save. Then work starts (create chor, drag items to, save, do constraints/save/test/save). If/when I add new items I add/embed/save then work.

 

I don't find that to follow logically. As you say this should be fairly straightforward to test.

I just don't believe at all that if the project gets to big it fails but three things point to it. Will test anyway.

 

The only thing that stands out to me at this point is that you may not be fully embedding all the files in your Project *after* you have set the Constraints. If this were the case then when opening the Project again the Constraints would not work, just as they are not working in your specific case. When dealing with pre-saved models that are then embedded into a Project there is a chance (due to many the variables of workflow) that the models are not actually embedded.

I don't follow this. Whether a model is embedded or not or is later (after creating chor constraints on bones) embedded or un-embedded should not have anything to do with chor constraints unless the process changes one of the bones involved. The simple thing I'm trying now has worked thousands of times for me. It should work and it does work--LOL--for everyone but me.

 

The only differences I've yet identified between myself and others are:

1. All my files live on a network file system (the same on all PCs)

2. I stripped out all of the images and materials on the test I posted.

3. Most likely PC brands and configs differ.

4. I'm here and they're somewhere else, LOL.

 

What else??

 

would be also curious to see if saving/reusing only the Choreography would maintain the constraints.

Rationale: You may not need the whole Project if you only need the Choreography

Precedent: Chors were used instead of Projects in Tin Woodman of Oz.

 

I often use chors for models which for one reason or another are actually multiple models constrained together in the chor. I plan of using this when I get it working. I tried this--still didn't work. I tried exporting from the chor to a model which is not an option as you loose poses...but didn't work.

 

Today (or soon) I will try:

* An ultra clean install (go through the registry)

* Eliminate the network file system

* Eliminate all materials

* Eliminate all images

* Constraining to non-control bones in the body (the Anzovin rig)

* Create a new user and try it

* Test project size

* Try a third PC using the 30 day trial (if this is possible)

 

If you can think of anything else I can try, please let me know.

 

It will interesting if we can ever find out what's going on Randy, because right now it seems like this problem is not just weird... it's down right impossible...unless the AM code contains a statement like:

 

If (user==rusty) {don't work}; !!!!

 

Again, thanks for chiming in!

 

Rusty

[rusty]

Based on this, only on my PC (just one, didn't try both), and at least for tonight anyway, when

* everything is embedded, it fails.

* if any one model is embedded, it works

* if neither model is embedded, it works

 

Does that tell anyone anything at all?

 

It's a curious circumstance. Everything was embedded in the PRJ you sent us but it worked as expected.

 

Doesn't work here. Impossible.

[robcat2075]

Here I am opening the unaltered PRJ and it works fine immediately...

 

RustysConstraints.mov

 

[rusty]

Here I am opening the unaltered PRJ and it works fine immediately...

 

RustysConstraints.mov

 

 

It failed before I sent it...I made very sure of that...then, the next day when everyone else said it worked I tried it again...then it worked. And, continues to work. As I've said, this is not possible. I intend to duplicate the above and see. I've actually saved the full model projects to see if the next day they work...nope but that's how insane it is. And this is the very first step in my production of the book trailer for book two which I started writing a couple of months ago.

 

Rusty

[robcat2075]

It failed before I sent it...I made very sure of that...then, the next day when everyone else said it worked I tried it again...then it worked. And, continues to work.

 

Sorry , I thought the problem was that this one stopped working again.

 

Looks like what you need to do is send the whole thing to Nancy, let her open it once, then you'll be good to go!

 

None-the-less, it's good to hear you had success with your book trailer!

[rusty]

If I were on your end, I'd almost have to think that maybe Rusty if full of it...pulling everyone's leg...or just... whatever.

 

I dug up an old program called CamStudio and captured a very simple example of what "I'm seeing" and put it on You Tube. Perhaps I'm doing something really stupid and don't know it...that would be nice!!! Take a look and tell me if you see anything I'm doing wrong. You might read the description--a narration of what I'm doing. Have a look...

 

http://youtu.be/sY_FPbwvrEE

 

Rusty

[Rodney]

I don't follow this. Whether a model is embedded or not or is later (after creating chor constraints on bones) embedded or un-embedded should not have anything to do with chor constraints unless the process changes one of the bones involved. The simple thing I'm trying now has worked thousands of times for me. It should work and it does work--LOL--for everyone but me.

 

It has a lot to do with the target of those constraints, especially if you are constraining two models to each other.

If the model is either not there or has changed then the constraint will fail.

This aligns with Mark's ealier observation of the constraint targets not being in your earlier screenshot.

Perhaps the targets weren't there because (after setting them) they simply were not saved.

 

Note: This is generally not a problem with constraints because they are within the same model. When constraining external models together it introduces additional variables; specifically that those external relationships must never change. If they do the constraints will fail.

 

Consider:

In your video you imported Model and then immediately embedded (I would never bother doing this because it isn't likely to embed everything... some variables may be introduced later that nullify this). But this is okay, you can embed as many times as you want and that'll be okay.

 

*Now here's where I think you might be going wrong*

When you import a new Model into the project from an external source (versus creating it new in the Project itself) it isn't automatically embedded.

The reason for this is that A:M thinks you want to maintain that link to the external Model so that changes you make to it will be automatically reproduced (in that Model) elsewhere.

 

Now follow me here...

If you fail to embed immediately before saving A:M will not embed external links.

 

So why did the Project file that you shared with others fail for you both before and after but not for everyone else?

I'm not entirely sure about the before part (perhaps you tested the file before embedding and saving) but the latter was likely due to your current workflow which has you regularly importing the files again.

 

The fact that your resources are on a network in a variable in this in that any external resources will fail if they are not in the same location. A:M however does a pretty good job of telling us if the external resources are missing so I don't think this is particularly relevant to the issue.

 

I watch the video but was a bit confused by the mouse appearing to click other places than where it really did.

I'll watch it again after offsetting my spatial calibration by a few inches.

Unless I am mistaken, I did not see you 'Embed All' again before saving.

 

When embedding, my suggestion is to *always* embed immediately before saving.

I can't think of a good reason not to do that unless there is something you specifically do not want to be embedded.

 

 

* Open AM

* Open the models

* Embed all and save

* Create a new Chor, embed all again and save

* I drag both models to the Chor

* I add 'translate to' and 'orient like' to two bones from the head to the body so that when

I move the body bones the head moves

* I test the constraints by moving the body bones which move the head model

* I save the file and close AM (In my estimation, this is where the workflow likely fails as the external files *may* not embedded but externally linked, especially if you forgot to re-embed at an earlier step)

* I open AM and open the file in AM

* I inspect the constraints in the project workspace

* I select the body and move the bones that should move the head (I also refresh by

pressing the space bar)

* The head does not move now...the constraints though there do not work!!

 

I would be curious to see what difference there is with regard to the constraints (if any) if you embed just before saving.

Of course if embedding the Models is counter to the goal of having the modular parts of the master model then I understand why it would not be optimum to e embed them. If expecting all files to be embedded you really MUST 'Embed All' just prior to saving. If nothing else doing this will remove some significant variables in troubleshooting the issue.

[rusty]

I don't follow this. Whether a model is embedded or not or is later (after creating chor constraints on bones) embedded or un-embedded should not have anything to do with chor constraints unless the process changes one of the bones involved. The simple thing I'm trying now has worked thousands of times for me. It should work and it does work--LOL--for everyone but me.

 

It has a lot to do with the target of those constraints, especially if you are constraining two models to each other.

If the model is either not there or has changed then ...

 

Hi Randy!

 

Wow! Thanks for all this effort! You can tell when someone really has the passion.

 

I've been doing 3D animation since 1992 and using A:M for 11 years (since v8.5) yet I'm still always learning new things about the program and animation. Perhaps this is another opportunity! But I'm not quite there yet. This is because I think I'm hearing and understanding you but... I must be missing something. I cannot think of a single reason or situation where you would need to 'embed all' just before saving or next time you opened the project you'd lose something (unless you go around deleting files the project has links to). Is there any kind of example you can provide?

 

Even though I only 'kind of' agree with what you're saying (again...if I'm understanding it correctly) it got my hopes up, but those hopes crashed when I tried it and got the same result.

 

It seems to me that what you say maybe sound advice to a beginner who wants to make sure that all the project or model elements are embedded so he/she can send the project to someone else or move it breaking file links. Granted if you embed a model that you open and you add say a new material that you have opened, that material will not be embedded unless sometime before you save/exit you explicitly embed it. But will present no problems upon reopening the project (unless you remove the material file or move the project file thereby breaking the path to it).

 

elements added to a model after embedding it--elements being... well, all I can think of right now are materials. Those materials will open with the model via their link but they are not embedded unless you specifically embed them before saving.

 

>>>>

It has a lot to do with the target of those constraints, especially if you are constraining two models to each other.

If the model is either not there or has changed then the constraint will fail.

>>>>

Well, the above is not 'completely' true. You can make changes to the model as long as you do not change the chain of bones to the target. You can open a different model (say a high res model) and as long as the skeleton is the same, you can change the target model in the chor and all will still work.

 

>>>>

Note: This is generally not a problem with constraints because they are within the same model. When constraining external models together it introduces additional variables; specifically that those external relationships must never change. If they do the constraints will fail.

>>>>

Yes...break the chain (or path) to the target and game over.

 

>>>>

Consider:

In your video you imported Model and then immediately embedded (I would never bother doing this because it isn't likely to embed everything... some variables may be introduced later that nullify this). But this is okay, you can embed as many times as you want and that'll be okay.

>>>>

Ah, perhaps I can learn something I don't know here...exactly what would NOT be embedded? In my experience the entire model without exception is placed inside the project. If the model contains a material which is not embedded, then its link will be brought in but beyond that and images what is there? More important though is exactly what 'variables' "may be introduced later that nullify "???

 

Probably, LOL, we are on the same page and I'm just looking at what you're saying wrong.

 

Cheers,

Rusty

[robcat2075]

I know that for TWO we used chors exclusively with all models external and were still able to constrain things to other things.

[Rodney]

Ah, perhaps I can learn something I don't know here...exactly what would NOT be embedded?

Any external file that is introduced to the project file later can be expected to be unembedded.

This is why we can safely have some files embedded while others are not embedded.

 

I think we are chasing tails here.

But I don't want to leave this variable dangling.

 

As suggested before it isn't necessary to embed everything.

I was simply suggesting that if your desire is to embed everything then you should be sure to 'Embed All' just prior to saving.

 

The process of fully embedding files in a Project is easily tested:

Create New Project

Create New Model

Embed All

Import (different) Model

Save

Note the little disk shaped icon that is on the imported Model that isn't present on the created (embedded) Model.

This indicates that the file is saved externally and therefore NOT embedded.

 

Now do the same test but embed just prior to saving:

Create New Project

Create New Model

Import (different) Model

Embed All

Save

Note that no Models are external (there is no disk shaped icon on the Model in the PWS).

All files are now embedded

 

This may not resolve your constraint problem but it is a better workflow if you expect all files to be embedded.

There aren't more steps in this workflow you simply don't have to Embed All at the beginning (which is an unneccessary step)... do that just prior to saving instead.

If you have any external files that are constrained to internal files and the external file is not located where the constraint expects it to be that constraint will fail. In fact, it has to fail because the target is no longer there.

 

Again, I am not suggesting this is the case with your situation and perhaps addressing a different problem while ruling out an important variable for this case.

This is especially true if you cannot see any reason to Embed All just prior to saving.

If you do not intend to embed everything in your Project then performing an Embed All just prior to saving wouldn't be desireable because it will embed files that you desire to remain external.

[Rodney]

I know that for TWO we used chors exclusively with all models external and were still able to constrain things to other things.

 

I'm not sure if we fully established what Chors save that Projects do not.

I know we did establish that Project files were unnecessary as long as the Chor file was saved.

[robcat2075]

Bottom line, embedded or not embedded should not make a difference to a constraint.

 

The only way i can imagine not-embedded models being a problem was if you created a constraint with some external models, saved the chor, then when you reopened it, some other models that happened to have the same names but not necessarily the exact same bones were being loaded instead.

 

However i can't imagine how that situation would be created in the first place.

[NancyGormezano]

Coupla things I notice:

 

I just watched Rusty's video - and differences that I notice is that he is on Win 8 and I am on winXP pro. I assume Robert is on Win 7, do not know Rodney's OS nor platform

 

The constraints look like they should work in Rusty's video. However I also notice the way he opens the saved project: from the list, rather than navigating to it with File/open. Maybe it's grabbing the wrong project file on his system? But yes, again, the constraints look like they should work

 

I also would suggest choosing embed all before the FINAL save of the project, just to be safe and superstitious.

 

The other practice which is a MUST that is not being done, is that if Rusty intends on switching the body model's and heads later on when he gets this working, even if models have same skeletal system, then he should rename the "shortcut to headmodel" to HEAD, and "shortcut to body model" to "BODY" before doing any of the constraints.

 

Constraints have been known to break if this isn't done, in previous versions. Do not know if that is still true in ver 17.

 

I also wonder if there is some confusion as to what's being embedded where, as it is now possible to embed things in a chor, and not just in projects. And materials can get embedded in models. Ugh. Too confusing. I never embed anything unless I intend to archive it, or share a project with someone else (like now). You never know what's using what and where, unless you check the status of the component.

 

As for differences in Projects and chors: Yes I only work with chors and rarely ever use a project (but I don't do netrendering). However, in past there were quirks/bugs with chors not saving certain items (eg Fog rotoscope maybe and other things that don't come to mind). Also the path to the particle systems files are saved in same folder as current or last saved project, even tho the paths are accessed in the chor.

[rusty]

I know that for TWO we used chors exclusively with all models external and were still able to constrain things to other things.

 

Dependability and minimizing loss are the most important goals for myself in workflow decisions. Best practices change. I would like to know all about this change (a change to me anyway) to using chors. It seems they are used instead of project files. Why?? What started this? Was reliability a factor? What are the advantages? What else, if anything were you using chors for...models?

 

All this should be a separate topic, this may already exist. If not, what would be the best forum?

 

Rusty

[rusty]

Ah, perhaps I can learn something I don't know here...exactly what would NOT be embedded?

Any external file that is introduced to the project file later can be expected to be unembedded.

This is why we can safely have some files embedded while others are not embedded.

 

I think we are chasing tails here.

But I don't want to leave this variable dangling.

 

As suggested before it isn't necessary to embed everything.

I was simply suggesting that if your desire is to embed everything then you should be sure to 'Embed All' just prior to saving.

 

There are other reasons and considerations for when and why to embed and these have probably evolved. This is pretty important to me but this is the wrong thread so I will start another. This thread is to figure out why my damn constraints are failing!! I must get them working dudes and dudettes! ;-)

 

r

[Rodney]

All this should be a separate topic, this may already exist. If not, what would be the best forum?

 

A new topic right here in the main A:M forum would work well.

We can always move it to a more appropriate place later (if necessary).

[rusty]

Hi Nancy,

 

I hope this finds you well and happy. Thanks so much for your time and effort spent on my problem.

 

I just watched Rusty's video - and differences that I notice is that he is on Win 8 and I am on winXP pro. I assume Robert is on Win 7, do not know Rodney's OS nor platform

Good eye! But, I'm getting the same results on my desktop which is Win7. :-(

 

The constraints look like they should work in Rusty's video. However I also notice the way he opens the saved project: from the list, rather than navigating to it with File/open. Maybe it's grabbing the wrong project file on his system? But yes, again, the constraints look like they should work

No, it was the right file but I tried opening it though A:M... same same.

 

I also would suggest choosing embed all before the FINAL save of the project, just to be safe and superstitious.

Actually I usually do this. Not in a project as simple as the test I posted--I know I embedded each model. My issue is the importance of doing the embedding as soon as I bring anything into the project. This has to do with the way I do things, with protecting the resource on disk--either the existing version or the static version in the resource pool which I do not want changed--and...either auto save or the manual saves which I do quite often. If I don't embed it as soon as I open it, I could make an unwanted change, have an AM or PC crash that could affect the resource or, somehow corrupt the project and then save accidetally impacting the resource on disk.

 

The other practice which is a MUST that is not being done, is that if Rusty intends on switching the body model's and heads later on when he gets this working, even if models have same skeletal system, then he should rename the "shortcut to headmodel" to HEAD, and "shortcut to body model" to "BODY" before doing any of the constraints.

 

Constraints have been known to break if this isn't done, in previous versions. Do not know if that is still true in ver 17.

I have never encountered problems with this... and of course if you change the resource name in the chor you lose AM telling you (in the name) what resource it's linked to so I actually and purposely avoid changing chor link names. I exchange low-res for high-res models on a regular basis and have never had a problem...but I'll keep this in mind.

 

I also wonder if there is some confusion as to what's being embedded where, as it is now possible to embed things in a chor, and not just in projects. And materials can get embedded in models. Ugh. Too confusing. I never embed anything unless I intend to archive it, or share a project with someone else (like now). You never know what's using what and where, unless you check the status of the component.

Ah...my work flow is just the opposite and for many reasons but I'm starting a separate topic on the pros and cons of this--I want to reevaluate my practices. Not embedding 'everything' would be a huge change for me...not necessarily a bad change but a basic one. However, reliability and minimizing loss are always my top considerations.

 

As for differences in Projects and chors: Yes I only work with chors and rarely ever use a project (but I don't do netrendering). However, in past there were quirks/bugs with chors not saving certain items (eg Fog rotoscope maybe and other things that don't come to mind). Also the path to the particle systems files are saved in same folder as current or last saved project, even tho the paths are accessed in the chor.

 

This is so interesting. I only use chors for complex models requiring the combination of multiple models (at a certain patch count models become impossible to work with due to response time). This would also be a huge change for me but again...my top considerations and all always dictate my choices.

 

BTW, with great excitement I tried saving the chor but, dag-nab-it, my constraints still failed. This entire thing is not possible! Every time I open that project and move that bone and the head doesn't move a dizzy wave of unreality washes over me! How can it work for everyone but me? This is not POSSIBLE!

 

Cheers,

Rusty