Doors: Current Setup Vs. Md5 Anims.

[New Horizon]

BT and I were discussing this in another thread and I thought it warranted a thread of its own.

 

Currently, there is a lot of hassle to setup a door. I'm having a tough time getting the new door model that BT recently put on CVS to work at all. Currently, the pivot point is in the middle of the door...so it rotates around this middle point, instead of opening as it should.

 

What are the pros/ cons of our current system vs. md5anims for doors. I know the anims aren't needed and that it's just a matter of not knowing how to set it up properly at this stage...but would there be any strengths to use md5 over the standard system?

[Ishtvan]

There were like 5 posts in the forum all saying to put the origin of the model in LWO at the point you want it to pivot.

 

If you mean using an md5 for opening/closing, I can't think of any advantages. The disadvantage would be having to rewrite all the door code, and add in all the physics checks ourselves that were inherited from D3 physics for the current door. Id didn't use anims for any of their doors so a rewrite would actually be a lot more work than the current door was to get working.

[New Horizon]

There were like 5 posts in the forum all saying to put the origin of the model in LWO at the point you want it to pivot.

 

Really? I guess I haven't checked the thread since then. So the origin would need to be placed in lightwave?

 

If you mean using an md5 for opening/closing, I can't think of any advantages. The disadvantage would be having to rewrite all the door code, and add in all the physics checks ourselves that were inherited from D3 physics for the current door. Id didn't use anims for any of their doors so a rewrite would actually be a lot more work than the current door was to get working.

 

Gotcha. I knew we didn't have to use md5's, since I was able to get the door half working...but just thought I would as if there would be an advantage. Thanks Ish.

[sparhawk]

Really? I guess I haven't checked the thread since then. So the origin would need to be placed in lightwave?

 

That's why we should have the wiki. I said all along that a forum is not a good place for certain information handling. This includes also desgin documents und such stuff.

[BlackThief]

you got that wrong NH - we don't need an anim to rotate the door - I think we will need an anim for the handle. if we don't do it with anims you'd have to make a seperate object for the door and the handle and you'd have to somehow clue those things together and rotate the handle and door at the same time. that seems to be reeealy complex to me and I think it'd require a lot more work for the mapper than if we just animate that handle.

 

I can move the current door model to the right point though so that it'll work for now.

[Ishtvan]

D3 does have entity binding functions though to do just what you're describing (have the handle stuck on the door). I don't know if you can do it in the editor or not, but we could write code to go thru all the doors, check for a handle object near them, and bind it automatically. Then the door could rotate it as needed for lockpicking.

 

We should examine the md5 possibility too, but it's going to be hard since lockpicking needs to jiggle the handle at any given orientation.. we would have to play the animation forwards, stop at some frame, remember the frame and play it backwards/forwards from that frame to jiggle it back and forth. Is it possible to play an animation backwards?

[sparhawk]

We will handle this through code. No need for anims just for the handle. We will create an association between a door and it's handle and then animate the handle. I think I should extend the frobbing, in order to be able to highlight multiple entities, so that we can highlight the handle and the door at the same time, when one of them is highlighted.