Solis' Thread

[Ishtvan]

We can attach an entity to a particular joint on the hand, and it will follow any transformations that joint goes through. As long as the sword always matches up in orientation and relative position to some joint on the wrist or something, it should be fine. Or we may have to make a joint especially for this purpose, I don't know how it's set up.

[Domarius]

We can attach anything in the game to any joint of a character. All that needs to be done is to get the offset and rotation right on the moment of attatching.

 

Yeah just leave the sword in, don't worry if it doesn't look right, floating in his hand. As long as it looks right in Motion Builder - that's what the in-game one will look like once the orientation is set properly.

[Springheel]

Actually, I think it's time we removed the sword. We know how to do the attachment now, and it will be easier for me to test how it looks if the sword isn't there. Unless there's an important reason to leave it in, why not get rid of it now?

[Ishtvan]

We still can't do a dynamic attachment that switches from the hip to the hand, I have to write a function and an anim frame command for that.

[Springheel]

Are you saying that it's not a good idea to remove the weapons yet? AFAIK it's not going to ruin anything if the AI can't draw their swords for a while (except perhaps for the alpha map, but we're not supposed to be making decisions based on that). Just seems like since it has to be done, it might as well be done now while the models are being resized, especially since the sword behaviour on the new animations is kind of wonky anyway.

[Dram]

(except perhaps for the alpha map, but we're not supposed to be making decisions based on that)

 

I think we've all realised by now that the alpha release is one of the main factors for so much progress recently. This is a good thing of course but yeah. Hell, it's our two years of work that's going to be shown to the public on Sept 18, so we may as well try and fix some things etc. I know we're not 'meant' to fix things just for the alpha release, but it's already happening and is unavoidable, everyone wants their relevant things to look really good for the alpha, so yeah.

 

 

Just stating an absoluely pointless and useless thing etc

[Springheel]

Hmm, I think I disagree with just about everything in that post.

 

The flurry of activity began long before the idea of the alpha map came about--it probably began with the finalizing of the latest betamapper release back in May/June, if you want to pin it down.

 

Secondly, I think it's highly unlikely we'll be showing the map to the public on September 18th. Charting the progress so far (while excellent work) I'd be a little surprised if the map is even finished, let alone optimized and bugtested, by then. And even if you decide not to sleep between now and then and manage to finish it, we still haven't decided when/if we'll show it to the public at large.

 

Thirdly, creating new models and textures for the map is one thing. But choosing NOT to make progress on something that needs to be done because it might make the map look bad is very wrong-headed, IMO.

[Dram]

The flurry of activity began long before the idea of the alpha map came about--it probably began with the finalizing of the latest betamapper release back in May/June, if you want to pin it down.

 

Hmm, well I don't exactly remember much of that but I guess you're probably right

 

Secondly, I think it's highly unlikely we'll be showing the map to the public on September 18th. Charting the progress so far (while excellent work) I'd be a little surprised if the map is even finished, let alone optimized and bugtested, by then. And even if you decide not to sleep between now and then and manage to finish it, we still haven't decided when/if we'll show it to the public at large.

 

Well I think I might have it finished, but not necessarily fully optimized bugtested etc. I've more or less started optimizing as I go, otherwise it'll be more of a pain later on.

 

I guess we could release this thing at Christmas or something if it does'nt get finished before then. Though I'd think it'd be finished before then anyways, but whatever.

 

Thirdly, creating new models and textures for the map is one thing. But choosing NOT to make progress on something that needs to be done because it might make the map look bad is very wrong-headed, IMO.

 

Of course, it'd be dumb to "remove" something just because it does'nt work perfectly so that the public don't o complaining and all about it etc. Like the leaning, although it does'nt work well, there's no point in removing it from the code so we have a finished product.

 

 

 

I guess in the worst case scenario we can release raw gameplay footage of either this map or another on Sept 18th if it's not done and all.

 

Well whatever, I'm still going to keep going at it full steam ahead.

[Springheel]

Well whatever, I'm still going to keep going at it full steam ahead.

 

Of course you should. You're doing an excellent job and I'm really enjoying watching the map take shape.

 

All I'm saying is that it would be silly to postpone work that needs to be done (like removing the guard weapons) because of what it might do to the alpha map (especially since it's still up for debate whether we'll have any AI in a public release anyway).

[Dram]

Of course you should. You're doing an excellent job and I'm really enjoying watching the map take shape.

 

All I'm saying is that it would be silly to postpone work that needs to be done (like removing the guard weapons) because of what it might do to the alpha map (especially since it's still up for debate whether we'll have any AI in a public release anyway).

Thanks

 

Yeah of course, we don't want to stop work for an alpha, it's technically meant to be sort of like a leak, as in, it has everything the way it is currently (at the time of it's release), so if something does'nt work, it does'nt work.

[sparhawk]

The work on the alpha map should definitely not stop needed work on other things. Just as we wont go out of our way to make additional complex content for it, we also shouldn't go out of our way and NOT do it, if this is the logical course of action.

[Ishtvan]

Are you saying that it's not a good idea to remove the weapons yet? AFAIK it's not going to ruin anything if the AI can't draw their swords for a while (except perhaps for the alpha map, but we're not supposed to be making decisions based on that). Just seems like since it has to be done, it might as well be done now while the models are being resized, especially since the sword behaviour on the new animations is kind of wonky anyway.

 

That's up to you guys, if you can stand AI not having a visible sword until I get around to writing the function, then sure go ahead. We just have to make sure there's a good joint to attach it to, and add one in if there's not.

[Solis]

Are you saying that it's not a good idea to remove the weapons yet? AFAIK it's not going to ruin anything if the AI can't draw their swords for a while (except perhaps for the alpha map, but we're not supposed to be making decisions based on that). Just seems like since it has to be done, it might as well be done now while the models are being resized, especially since the sword behaviour on the new animations is kind of wonky anyway.

 

The main reason it would be nice to keep the sword on, if it won't be problem to remove when we actually import the model into the game, is so that we can see precisely how the sword will be oriented when it's attached in the game instead of having to guess where the sword will be based on the rotation of the hand. Alternatively, if we could simply set up a dummy bone in Motionbuilder that functions as an indication of where the sword will be when it's attached in the game, that would also work. Otherwise it would be hard to tell exactly where the sword will be in each part of the animation, for example when it's being drawn from it's sheath you have to go through pretty much every frame and make sure that the sword doesn't go outside the sheath as it's being pulled (an issue I noticed with our current draw animation).

 

In any case, it would be nice to know what it will take to remove the sword and have it attached in the game rather than having it be a part of the animation. I can work without it if need be, the animations can always be tweaked later if we need to change things like hand orientation.

[ascottk]

The main reason it would be nice to keep the sword on, if it won't be problem to remove when we actually import the model into the game, is so that we can see precisely how the sword will be oriented when it's attached in the game instead of having to guess where the sword will be based on the rotation of the hand. Alternatively, if we could simply set up a dummy bone in Motionbuilder that functions as an indication of where the sword will be when it's attached in the game, that would also work. Otherwise it would be hard to tell exactly where the sword will be in each part of the animation, for example when it's being drawn from it's sheath you have to go through pretty much every frame and make sure that the sword doesn't go outside the sheath as it's being pulled (an issue I noticed with our current draw animation).

 

In any case, it would be nice to know what it will take to remove the sword and have it attached in the game rather than having it be a part of the animation. I can work without it if need be, the animations can always be tweaked later if we need to change things like hand orientation.

 

What I did with the player's bow draw animations is delete those polys in the md5mesh (in my case, the arrow) and kept that mesh in the md5anim so I'd have a reference. I don't know about lightwave/maya but I think the d3 animations only use the bones & not the mesh.

[Ishtvan]

If it doesn't follow the hand exactly, adding a dummy bone for it would probably be a good idea anyway since we can only bind it to a joint and have it follow that joint, so if it needs to move independently of the hand then it needs to have a separate bone we can bind it to.

 

I think going thru the sheath was a conscious decision of Odd's, he said it wouldn't work to come completely outside of the sheath and people wouldn't notice.

 

As for what it takes to attach things, I have to write a function so we can do it dynamically. We also have to design this behavior, not sure how it's going to work. Are we going to have multiple entityDefs for different attachment points, or should we try to pass all the info in with the anim frame command? I don't know yet.

[Springheel]

I haven't looked at the textures much though, I don't have the def or shader files for the guard, just the jpegs that motionbuilder creates. I'm not sure how I'd go about turning those into texture/bump maps and editing a shader file for them, or what file structure is used for it. Doom 3 is still a bit foreign to me.

 

I could probably find the texture and material files for you if that's what you need. Do you need the def file?

[Domarius]

Hm, Solis has a point. So does Ish.

 

I was never happy with the sword moving through the holder, but unless someone wants to make some modelling changes, there's not much we can do about it.

[Solis]

I could probably find the texture and material files for you if that's what you need. Do you need the def file?

Yeah, right now I'm just using a skeleton def file which has the bare minimum that's needed for the model to be compiled in Doom 3, so the standard def file would help. If it's not too much trouble it would be nice if I could get the files needed to fully compile the Elite Guard so that it's easier to see how it will look in the game. Right now all I have for reference are the Motionbuilder animations and a very weird ghost-like silouette in the game.

 

Also, which draw animation were we talking about? I downloaded the "Elite 7 side on.fbx" file, and it seems that some of the sword-through-sheath issues are due to the animation rather than the model. I could touch it up if we're going to be using that one, if there's not much else for me to do right now (was a decision ever made as far as rerigging the models?)

[Springheel]

Ok, I'll put together the files. I'll also see about getting you CVS access.

 

In the meantime, I'm going to post an organizational chart to help keep track of who is doing what. I also have some questions I'd like to hit you guys with. Stay tuned.

 

edit: Solis, do you have FTP access yet? I can't remember.

[Solis]

Thanks, and I've replied to that questions thread. And no, I do not have FTP access.

[Springheel]

Ok, you should be upgraded to full member now, Solis. You can get the login info for the FTP in the Information forum. I've put the files you need in the animation folder, called solis-darkmod.rar.

 

You can also talk to Sparhawk about getting CVS access so that you can stay up to date with file changes.

 

edit: Hmmm....for some reason the upload crashed out and now it says I don't have permission to upload. The file there isn't complete.

[Solis]

Thanks, I can get on the FTP now. Wohoo, now I'm official.

 

That file doesn't seem complete though, both on the FTP and in the Email you sent me. I can get some of the files by running the archive recovery, but the rest of them it gives an error when I try to extract them. How big is the rar supposed to be?

 

Oh, and it might not be giving you permission to upload if the FTP is set to not allow overwriting of files. You can just name it something different and upload it again, and then someone with full access can delete the original.

[Springheel]

The email didn't work either? Hmm, maybe the archive was corrupt somehow. You've got about 90% of it already though. Can you tell me what you have that works?

[Solis]

Hmm, actually nevermind, it looks like when I first downloaded the file from the email, the download was cut off and the file was incomplete. I tried again using Firefox instead of IE, and it worked. Thanks, I'll take a look at it a bit later.

[Springheel]

Solis, is that throwing animation on ftp somewhere?