11 réponses à ce sujet

[Mecheon]

How are we going? Time for a good ol' round of "Mecheon broke something and wants to know why"

I've been working on turning the Mist Dragon into a Lindworm for a while now, and tried my prototype model (With just the legs removed) ingame. Well, the texture went downright haywire (Despite just being an unchanged Mist Dragon texture), but I think that's just my DDS converter acting up

What did give me a problem, though, is that, although all I've done with the model is change a few names, it refused to animate the hands on the dragon. Everything else was fine, just the hands. The problem on this is, its a very replicatable issue and doesn't appear to just be one of my regular attempts at breaking the game

Give this one a shot. Extract the Mist Dragon model, and go in and change its name over to something else for the model references (I used lingrey for my critter). If its matching what my computer is doing, then the model should animate everything except the hands in the toolset

Any ideas what's going on? I can see some previous mist dragon edits have added their own animation file, but I'd prefer not going down that path in order to save some space

[Bannor Bloodfist]

You would have to check the animations themselves as well, some of them are baked with the actualy part of the creature they are attached to. You should be able to test that directly inside max by running the animation itself.

Sometimes just doing a reset x-forms will fix this issue, but sometimes doing that will break the entire animation sequence.

Another thing to remember is that every time you import and re-export something, you are running a very high risk that the animations will just break. This is a very well documented problem with the import/export routines of nwmax/nwmaxplus.

As far as the texture getting screwed up, if you are using the same texture, just renaming it, there is absolutely NO reason to decompress and recompress into DDS. Every time you recompress you are losing data in the texture itself and typically break the uvw mapping. If all you are attempting to do is see the texture inside of max, decompress it, rename it. Take a copy of the original DDS and just rename that. NEVER decompress and recompress unless you actually modify the texture, not it's name, but actually edit/change the texture itself.

[OldTimeRadio]

Bannor Bloodfist wrote...
Another thing to remember is that every time you import and re-export something, you are running a very high risk that the animations will just break. This is a very well documented problem with the import/export routines of nwmax/nwmaxplus.

Do you happen to know of a model I could use to reproduce that issue?  Though they're almost exactly the same thing when it comes to core operations, there's always been something a little wobbly or at least different about NWMax and I've compared the code to the Aura scripts lots of times trying to find whatever the difference was, but never could.  The closest I was ever able to get is that NWMax lacks good garbage cleanup from operaitons and so memory usage (definitely) and odd behavior (maybe) go up the longer you have your session open.  This is really apparent in tile slicing and WOK export, both on large scales, for instance.

Modifié par OldTimeRadio, 16 septembre 2012 - 06:35 .

[OldTimeRadio]

Did you ever find out what the issue was? If so, what was it?

[Bannor Bloodfist]

OldTimeRadio wrote...

Bannor Bloodfist wrote...
Another thing to remember is that every time you import and re-export something, you are running a very high risk that the animations will just break. This is a very well documented problem with the import/export routines of nwmax/nwmaxplus.

Do you happen to know of a model I could use to reproduce that issue?  Though they're almost exactly the same thing when it comes to core operations, there's always been something a little wobbly or at least different about NWMax and I've compared the code to the Aura scripts lots of times trying to find whatever the difference was, but never could.  The closest I was ever able to get is that NWMax lacks good garbage cleanup from operaitons and so memory usage (definitely) and odd behavior (maybe) go up the longer you have your session open.  This is really apparent in tile slicing and WOK export, both on large scales, for instance.

To be honest, I believe it is rounding errors.  There is a section of code somewhere in the nwmax set of scripts that does global rounding but I am not enough of a programmer to tell you what section of code it is.  There is a way to cut that section out or comment it out or to increase the precision, but again, I have no idea exactly where it is located. 

At one point in time i had a version of NWMax that did not have the issue, but it was just a set of scripts that had been emailed to me by joco prior to me using gmail... as a result, I no longer have those updated scripts.  I think there may be mention of the code section that you may be able to find using the omnibus, or it may have just been someone claiming to have fixed it without posting the code.

One of the files that typically displays the issue is the original air-ships, over water, by Some_Ux. The proplellors break I think on those, and some or all of his other regular ships have the same sort of issue.  Be aware that those original models created by him are a complete mess of linked objects, so badly linked that any re-import/export by NWMax will break them due to rounding errors and the way that animations are tracked inside of aurora.  Not sure if it is the baking process on export or what, but they have some very visible issues where objects will be off screen, or at least off tile.  he also had a large portion of objects linked to a single tile in a multiple tile group, which causes management issues.

Great looking ships, as all of us know, but editing them in Max tends to cause all sorts of issues.

Happy hunting! 

[Mecheon]

Bannor Bloodfist wrote...
You would have to check the animations themselves as well, some of them are baked with the actualy part of the creature they are attached to. You should be able to test that directly inside max by running the animation itself.

That was my first thought, but I did check the mist dragon, and it didn't have any inbuilt animations. Plus, when I imported the animations seperately, it animated perfectly

Sometimes just doing a reset x-forms will fix this issue, but sometimes doing that will break the entire animation sequence.

Gave it a shot, didn't seem to work. The oddest bit is that its always just the hands, the arms and every other body part animate perfectly

Another thing to remember is that every time you import and re-export something, you are running a very high risk that the animations will just break. This is a very well documented problem with the import/export routines of nwmax/nwmaxplus.

I'm figuring this is what's happened. I just a fresh copy of the Mist Dragon out of the files, imported it just to convert, changed just the model name at the top and replaced it. Same issue

As far as the texture getting screwed up, if you are using the same texture, just renaming it, there is absolutely NO reason to decompress and recompress into DDS.

I haven't recompressed it yet, but the plan was to later change the skin. Just haven't done that yet. Honestly, looking at how the texture is going, I'm thinking somehow when I imported/exported from the bif files its managed to mess up the UVWrap in addition to the animations, either that or when it converted to the ASCII side its messed up the UVs

[OldTimeRadio]

@Bannor - This might be it, the part that does that agressive rounding.  About Some_UX's (and others) "odd" models: I haven't tested it, but I think I might have a clue about what was causing that strangeness, beyond just the way some of them are put together..  NWMax ResetXForm might not remove transforms like it implies, even with a safe pivots off.  As much as everyone's sort of cautioned against it, doing an actual Reset XForms from Max and then DELETING the resulting XForm modifier in the stack might be a possible way to deal with that.  Maybe I'll have something a bit more useful on that count in the future.

@Mecheon - Can you upload your c_drgmist.mdl (or whatever it's called) to mediafire or something like that and let me take a look at it?  Maybe before that, I'm assuming you're aware of how sensitive supermodeling can be?  In other words, if you renamed a part internally in the equivalent of your c_drgmist.mdl and that part is not named the same in the c_drgmist_anims.mdl file, you're probably going to have trouble.  I would also point to a 2DA line being a problem but for hands only not moving, that shouldn't be it.  The hierarchy needs to match in the base model vs what's being used as the supermodel, too.

[Pstemarie]

Use the mist dragon from Project Q as a base for the animations - I fixed the issue with the non-animating hands back in v1.4.

[OldTimeRadio]

What was causing it if you recall?

[Pstemarie]

If I recall correctly the hands/feet on the model were not linked in the same manner as the hands/feet on the supermodel - a missing or additional node if I remember right.

[Mecheon]

Pstemarie wrote...

Use the mist dragon from Project Q as a base for the animations - I fixed the issue with the non-animating hands back in v1.4.

Oh, awesome! Worked a treat

Fixed the texture issue along with it somehow, to boot

Modifié par Mecheon, 20 septembre 2012 - 01:35 .

[OldTimeRadio]

@Pstemarie - Thank you for the info!