Getting The Thief Model In Game

[Domarius]

http://forums.thedarkmod.com/index.php?showtopic=3606&st=50

 

Why don't we try it out, and see if the effects on the physics are really that noticible?

And if they are, maybe we could just treat physics values seperately? People would have to remember that the numbers for physics don't equate to the real distances, they are still in doom units.

[New Horizon]

Oh, I thought we decided on going with 1:1. Don't know why I thought that.

[sparhawk]

@NH: I thought the camera was in the neck/chest the whole time?

 

It is. Maybe it shifts a little because of animations, but the supposed point is where the neck and the torso joins.

[sparhawk]

Just pop into a map and take a look at the 3rd person model to get a glimpse of what I mean. Make the gem visible and you'll see that the very top of the light gem model lines up with the eyeheight.

 

The camera is a the centerpoint if you remove all offsets on the model.

[Ishtvan]

I dunno, the calculation of 1:1.1 is pretty sketchy anyway. We should just go with whatever looks like the correct scale from the current camera height.

[Domarius]

Yeah - let's just try it

[Springheel]

I dunno, the calculation of 1:1.1 is pretty sketchy anyway. We should just go with whatever looks like the correct scale from the current camera height.

 

I'm confused. If the 1:1.1 is pretty sketchy, then why can't we just go with 1:1?

 

Seems like the following two ideas are contradictory:

 

1. Changing the size of D3 units to anything other than 1.1" messes up the game physics.

 

2. D3 units are pretty arbitrary and we can assign them whatever real world value looks best.

[Ishtvan]

We could go with 1:1 if it looks good from the current camera position, I'm just saying don't change the camera since that's the only non-arbitrary thing we have, that and D3 reference characters that "feel right" when looking at them from that camera position. Otherwise we could be sliding around 3 arbitrary variables (camera height, map unit scale and physics unit scale) and never converge on a combination that works.

 

It takes a while to establish a combination that actually works when there are obviously RL->game engine and psychological factors at work too. Try noclipping up in the air until the center of your screen is exactly at eye level of a character and tell me that character doesn't appear too short to you.

[Springheel]

do a pm_thirdpersonplayer 1, and tdm_lg_player 1

 

Does that mean type it into the console? I tried that and I kept getting an error that no such command exists.

[sparhawk]

They definitely exist.

 

But IMO it's pm_thirdperson 1 and not pm_thirdpersonplayer 1.

[New Horizon]

They definitely exist.

 

But IMO it's pm_thirdperson 1 and not pm_thirdpersonplayer 1.

 

Whoops. Typo on my part, sorry.

[Springheel]

Ok, it's hard to get a direct comparison, but here's what I noticed when standing side-by-side.

 

 

Presumably, our thief will be moving around slightly hunched over like that, rather than standing straight up striding around. In that case, the top of the gem is clearly higher than the thief. So it *appears* that the thief model needs to be made a little larger. Either that, or the gem needs to be lowered closer to the ground. I can't tell how the gem compares with the camera, however.

 

I compared the thief model to a few other objects, like chairs and tables, and he definitely seems a little on the small side.

 

Anyone else want to analyze this?

[New Horizon]

Ok, it's hard to get a direct comparison, but here's what I noticed when standing side-by-side.

 

 

Presumably, our thief will be moving around slightly hunched over like that, rather than standing straight up striding around. In that case, the top of the gem is clearly higher than the thief. So it *appears* that the thief model needs to be made a little larger. Either that, or the gem needs to be lowered closer to the ground. I can't tell how the gem compares with the camera, however.

 

I compared the thief model to a few other objects, like chairs and tables, and he definitely seems a little on the small side.

 

Anyone else want to analyze this?

 

I'll look into it Spring. Have you thrown it up on CVS yet?

[Springheel]

No. All I did was move the farrellposed.lwo file from Odd's pack into the editor. It still doesn't have the actual textures or anything applied, so I don't want to add it to CVS in that condition. It's good enough for a height comparison though.

 

In the thief's hunched-over pose, his eyes are at 64 units and the top of his hood is 70 units high.

 

By comparison, the builder guard is 85 units high and the elite city watch is 90.

 

 

 

 

I think the Thief should be resized so that his eyes are at the camera's 68 unit height when walking. Resizing the image to 110% worked in photoshop.

 

That said, when moving around the various maps, the taller AI don't really seem extraordinarily tall. The distortion of the FOV nicely covers up that they are much larger than you. So perhaps we won't have to modify them after all.

[Springheel]

This is still an open task. Does anyone have the time/expertise to look into it?

[sparhawk]

Oddity?

[Ishtvan]

Re: AI size

 

A while ago I went thru D3 again and noticed that even though the other characters' eyes are above the center of the screen when I look straight ahead, it still seems pretty natural when standing to them. When I noclipped up to where my camera/screen center height was actually at their eye height, they seemed much too short. Maybe there is some psychological reason for this, like we like to fill the frame more with a character instead of just cutting them off at the neck, and we like to look above the center of our screen when making eye contact in this case? Or maybe I'm just crazy?

[Springheel]

Or maybe I'm just crazy?

 

Maybe, because you posted all this already.

 

Yeah, you raised a good point. When I play around with the AI, they don't seem extraordinarily tall, just enough to be intimidating. I'm content to leave the AI as is. The player model does need to be bigger to match the camera height though.

[Ishtvan]

I wasn't sure if I posted it or not. Yeah I agree the player should at least be stretched up to camera height. The only AI that feels off to me is the tallest one, the pro guard. Maybe we can do some comparisons with the D3 hazmat guy for future AI, because they seem to have gotten it down pretty well in D3. Otherwise as we talked about, we could get into a neverending cycle of resizing our AI and changing our camera height with no gauranteed convergence.

[Springheel]

The only AI that feels off to me is the tallest one, the pro guard

 

It's a shame, because he will be the one used most often in non-city environments. Well, if we decide to resize him we should do it before Dom starts doing the animations for it.

 

Personally, I'd like to see him resized to the same size as the builder guard just for consistancy.

 

Who actually knows how to resize these AI models?

[New Horizon]

Who actually knows how to resize these AI models?

 

It shouldn't be too hard with the core files, they would just need to pop them into the appropriate program and use the scale function I believe. Not sure how that affects the skeletal rigging or what not, but that's all resizing would require.

[oDDity]

You'll have to detach the mesh and rerig them, re-weight the verts and then apply all thre animations agin. Simple resizing isn't an option. It's a real pity you can't do it from within doom with some code.

[New Horizon]

You'll have to detach the mesh and rerig them, re-weight the verts and then apply all thre animations agin. Simple resizing isn't an option. It's a real pity you can't do it from within doom with some code.

 

Yeah, really though. I spoke to Brian from id months ago and he said it would be possible in their next engine. Hmmm, I wonder if it's something we could pull off with Dark Radiant? Drag resizable AI would be pretty handy.

[sparhawk]

If you can do it in the editor you can do it in the engine as well. The editor would have to write the model back to an LWO file with the new size (which it certainly can't do). Otherwise it means that it is just stretching the vertices mathematically, which causes the problems that Oddity mentioned.

[Ishtvan]

Maybe we can scale the rendermodel axis in the code. All of the anims and rendering coordinates are based on the coordinates in the file times the rendermodel axis, so maybe scaling that would work. It seems like we've already talked about this and there was some reason it wouldn't work. I don't have access to the src now, but if someone does they could add a spawnArg to idEntity that multiplies both the physics and renderEntity axis by some scalar value.