General enquiry

[Flux]

Hi, I'm currently studying for an Msc in computer animation and trying to work out a possible masters thesis. I'm very interested in contributing something to this mod as my project. The thief series has long been an inspiration for me and I've followed along with the development of this mod with great anticipation and awe. Used to post on the old ION storm forums a little following thief 3's development, used dromed back in the day too Just wondering what are the general areas most in need of assistance?

 

Obviously as a masters project it would need to be substantial and based around a proposal and research. I mainly come from a coding background which is what makes up the majority of the course. We've been working with OpenGL, python and renderman mainly, for differing applications. Before that I had a few years with Java amongst others. We've also done intro modules to maya and houdini etc.

 

One small assignment I've been working just recently has been a basic 3d collisions game which I've based around the old arcade classic Breakout. As a group project I also did coding and level design/editing for a hl2 mod. Just to give you an idea of some of the areas we've looked at.

 

Personally I'm very interested in level design and I'd like to incorporate something into a small but solid map using dark radiant too. I'm very interested in AI as well, not sure where you're at currently with this?

 

Anyway, I'm wondering if you guys have any thoughts/suggestions? Below is a link to some of the past projects people have investigated to give you some idea of what I might offer. I don't know if it's a feasible idea really, if not, no worries. It might need to be something that is currently way of your radar in terms of implementation but that is applicable to the game as a future target but workable now. I just thought I'd throw this up here, I'd be really interested to hear from you all regardless.

 

Thanks and keep up the inspiring work!

 

Previous Masters work examples

[Crispy]

We could use some help in the animation department, as I believe we're only just on track to deliver a basic core set of animations, for various reasons. Springheel (art lead) could tell you more about that. Do you have any examples of completed animation work?

 

The programming department is slightly less in need, I believe. But there is still a bunch of work to be done, and I'm sure greebo wouldn't mind having some work taken off his plate.

 

We do have a bunch of great mappers already, though of course you're very welcome to join in. Beta mapper access is normally granted based on examples of previous/existing work. If you're lacking in relevant portfolio material, you can show off your skills using DarkRadiant and Saint Lucia assets (all publicly available).

 

I don't know how new and exciting a Computer Animation masters project has to be. I'm going to assume that you can't just make a bunch of awesome assets (e.g. animations) - if you could that would be perfect. The Doom 3 SDK is reasonably open, with only a few bits of it being closed-source, so if you're interested in implementing a particular piece of technology all the better. I notice a few of those projects had to do with procedural animation, for example. (Word of warning, though, the guts of D3's animation code are pretty impenetrable and completely uncommented.) Stuff like flocking is less likely to be useful, unless you use it for ambient animals (like birds), since our AI is pretty computationally intensive - you generally can't have massive crowds on-screen at once, without implementing some kind of fancy "group awareness" system.

 

Anyway, welcome to the forums, and I hope we can figure out a mutually-beneficial arrangement.

[Flux]

Interesting, thanks. In terms of rigging/animating, I think I'd need to develop a tool for creating animations and then produce some using that etc. Seems like you're already very well setup for this though and just need someone to use the existing software. The course I'm on is really more about the tools/coding side of things than actually creating the animations themselves. I did a small procedural animation using python and renderman but that was to become more familiar with python and renderman themselves rather than the animation produced. Of course it's all pretty broad and the whole point of the final project is that it's something new for ourselves that we investigate quite deeply so it's all part of the learning process I guess. I'll be looking at particle systems, fluid dynamics and kinematics in more detail next term too etc.

 

Procedural animation is definetely more up my street so if you have any ideas about how you might see that applying here that'd be great. I'll look into some of this stuff further with some of my tutors anyway. The esoteric nature of the doom 3 anim code sounds. . . er fun! What about procedural shaders? Are you making much use of them, might that be an area I could contribute something in?

 

If there is anything else that people think of though, I'll glady discuss it and find out more from my end. I guess the main problem is that you're already quite far into development and have a very solid, established setup in place already. I'm guessing with a lot of the coding for example that at this stage you only need people for more continuous, small scale issues as and when they crop up. Thanks for the quick reply anyway.

[Ishtvan]

This isn't a high priority among the current programmers, but if someone wanted to work on it, we could probably benefit from it:

Doom3 includes inverse kinematics (IK) for the legs of characters (walking, running), and the SDK has some code for IK for the arms (reaching for things at various positions), but this code was never used in the game itself. So I'm guessing it's probably riddled with bugs and maybe only partially completed. I don't know if IK is something you're interested in, but if so, you could look into implementing Id's existing arm IK code or writing your own. We could also use some IK when it comes to actions like sitting in chairs and lying down on beds. Currently we don't have any, so all chairs and beds have to be at a certain height to match the animations. Is that something you would be interested in?

[Flux]

Yep sounds interesting to me. So I might create some animations using the implemented arm IK as well if I was successful? And then maybe demonstrate it in a level. Are some of the animations you need connected with the lack of an arm IK or are these two things totally separate? Anyway I'll have a look into that as well, thanks for the suggestion.

 

I don't think this project kicks in for another couple of months possibly so I'm just trying to work out a clear idea at the moment but obviously I'd like to research into it sooner than later etc. After that I'd be working on it for three months I believe from about June-August. Just to let you know.

[Ishtvan]

Yep sounds interesting to me. So I might create some animations using the implemented arm IK as well if I was successful? And then maybe demonstrate it in a level. Are some of the animations you need connected with the lack of an arm IK or are these two things totally separate? Anyway I'll have a look into that as well, thanks for the suggestion.

I believe we do have a general "reach for things" animation that we use for stuff like opening doors, that right now always reaches to the same place relative to the AI. Maybe that could be used as a basis and then updated to work with arm IK? I think you can enable/disable IK in certain frames of the animation, but beyond that I don't know the details of how it works, if you have to animate differently with IK in mind or what.

 

Another part of it is deciding whether to kneel down if what they're trying to reach for is on the ground, and the code for deciding to do that (which should be fairly simple). We have a kneel animation but the current version has some issues.

 

I think most of the animations we need don't really have to do with arm IK, but if it's a choice between not working on the project at all and working on something that, from our perspective, is low priority, might as well work on it IMO.

[Crispy]

Procedural animation is definetely more up my street so if you have any ideas about how you might see that applying here that'd be great. I'll look into some of this stuff further with some of my tutors anyway. The esoteric nature of the doom 3 anim code sounds. . . er fun!

Hehe. Well, that sounds like a good fit then.

 

What about procedural shaders? Are you making much use of them, might that be an area I could contribute something in?

As in graphics shaders? Rebb's the man to talk to about those. He's customised some shaders to fix issues with Doom 3's ambient lighting, and he's just recently been working on possible improvements to the mod's frob highlighting effect which involve shaders. I'm not sure that we have much else to work on in that department, unless you have any specific ideas for visual effects we're missing.

 

I'm guessing with a lot of the coding for example that at this stage you only need people for more continuous, small scale issues as and when they crop up.

The general coding work is certainly mostly of that nature at this point, yes; for the most part it's fixing bugs and making other improvements to systems which are already in place (albeit roughly in some cases). If we can find a nice little separated project like arm IK, though, then that would work well.

 

Yep sounds interesting to me. So I might create some animations using the implemented arm IK as well if I was successful? And then maybe demonstrate it in a level. Are some of the animations you need connected with the lack of an arm IK or are these two things totally separate? Anyway I'll have a look into that as well, thanks for the suggestion.

This is dynamic IK, you understand; implemented completely in-game, rather than in an animation as such. I imagine it would be applied over the top of pre-canned animations to modify them. For example, the "lean forward and reach for something" animation (which potentially has secondary movement of the body and so on done already) would be modified by adjusting the arm bones so that they actually reached towards e.g. a door handle. The location of the door handle has to be compensated for at run time, since the animator has no knowledge of its location.

 

I guess you'd create (or appropriate) a demonstration level showing the use of the IK, yes. So for example you could have some AIs patrolling around and opening doors from different angles.

 

Stuff like sitting down needs "butt IK" rather than arm IK. When an AI plays its sitting animation in order to seat itself on a chair, the butt IK would kick in at an appropriate point and move the AI's pelvis up/down to compensate for the difference between the pelvis's location in the canned animation and the actual height of the chair seat. The AI's feet would be expected to stay at the same height, either by rotating the thigh bones to compensate or by relying on the foot IK (which already works).

 

Lying down on a bed of variable height would be similar, I imagine, except the feet would be free to follow the pelvis around.