Todo: Resizing Ai [open]

[Springheel]

Ok, it's been more or less agreed upon that two AI models need to be resized.

 

The Thief player model needs to be increased in size by 110%, in order to match up with the camera.

 

The Builder Guard and Elite City watch will be left as they are.

 

The Professional Guard needs to be reduced in size to about 92% his current size (this will make him about the same height as the Builder Guard).

 

Unfortunately, according to Oddity:

 

You'll have to detach the mesh and rerig them, re-weight the verts and then apply all the animations agin.

 

 

So, is there anyone that currently has the skill to do this? Dom and BT are probably the two people who have the best chance of learning/knowing how to do this.

 

I've been told getting the player model in game is a fairly high priority, so how best to accomplish that?

[Ishtvan]

In case we can do it in the SDK without changing any models: I'm going to see what happens when I multiply the renderentity axis as well as whatever axis animation uses by a scalar scale value in the code. I doubt it will work, but I'll report what happens.

[Ishtvan]

Well, I got crates to start out 1/2 the size by multiplying renderEntity->axis by a scalar, but whenever you interact with them they pop back to regular size for some reason. AI aren't responding to the size change yet. They may set their axis in a different manner.

 

EDIT:

Okay, looks like idEntity::UpdateVisuals is calling idEntity::UpdateModelTransform which sets the renderEntity axis to a new normalized axis. That's probably what it is, and it's fixable.

 

Okay, something is causing the physics object axis to get reset when it is in collisions or something, and then UpdateModel reads in the reset physics axis. This is why the single multiplier goes away when physical interactions happen.

[Ishtvan]

Ladies and gentlemen, I give you... Minibuilder!

 

 

http://img.photobucket.com/albums/v241/Ish...minibuilder.jpg

 

The animations seem to work fine, as you can see he's attacking.

 

I pretty much just changed the renderEntity axis. I had to put the multiplication in idEntity::UpdateModel (hopefully one more float multiplication there is not bad for performance), which runs each frame, because otherwise that one kept setting back a non-scaled axis. I'm not sure what Brian Harris was on about when he said it was impossible, it's pretty much just a one-line change. Maybe he meant it wasn't do-able using only scripting.

 

I'm having a problem where the scale multiplier seems to get applied twice to the visual model, but only once to the clipmodel (so when I set it to 1/2, he's 1/4th the size with a clipmodel 1/2 the size). Still trying to track down that problem, but it should be fixable.

 

MiniBuilder skates on the floor a little when he walks, I think it's because of this difference between physics axis and visual axis, but it could be another thing that needs to be scaled. Also the shadow is a bit messed up, looks like the shadow of the full size one but it cuts off halfway up. Even if these two aren't fixable, they'll be less noticable for a small size change when reducing the AI.

 

I'm still not 100% sure that every aspect of this will work, but if it does it should save us some time since we won't have to reanimate all the AI.

[Dram]

OMFG.............JESUS..........ISH.....

...*flatline*

 

MY FUCK MAN!!!! YOU ARE THE MAN!!!!!!!!

[SneaksieDave]

Oh my. So if you're this far onto this, then resized static meshes should be easy, right? I mean, aside from the unpredictable, buggy rotate method?

 

And YAY we can have variations in guard height.

[Dram]

Yeah, at worst we can set the statics to nonsolid and put nodrawsolid. >

[New Horizon]

THAT IS HILLARIOUS!!!

 

When the time comes, I'm guessing we'll be able to incorporate this into DarkRadiant for 'drag' resizing of static meshes.

[Springheel]

I'm still not 100% sure that every aspect of this will work, but if it does it should save us some time since we won't have to reanimate all the AI.

 

Mini-builder is hilarious! That's going up on the website next update.

 

 

This is certainly worth pursuing. Is it something that is 'hard-coded' to the model, so mappers don't have to do this manually all the time?

[New Horizon]

Mini-builder is hilarious! That's going up on the website next update.

This is certainly worth pursuing. Is it something that is 'hard-coded' to the model, so mappers don't have to do this manually all the time?

 

If we can incorporate this into DarkRadiant...wow...just imagine being able to resize windows and other construction assets on the fly. Perhaps I'm getting ahead of myself and don't fully understand how this is done...but I'm hoping for the best.

[Dram]

AFAIK Ish means that it's done by constantly telling the model to scale somehow. So if you add a variable to that you could make it so you can change it in editor etc.

 

However it's done it's a BIG breakthrough

[sparhawk]

Ladies and gentlemen, I give you... Minibuilder!

http://img.photobucket.com/albums/v241/Ish...minibuilder.jpg

 

The animations seem to work fine, as you can see he's attacking.

 

That looks hillarious!

 

 

I'm not sure what Brian Harris was on about when he said it was impossible, it's pretty much just a one-line change. Maybe he meant it wasn't do-able using only scripting.

 

They always say this when they don't want to spend time on invetigating it I guess. I always said that it should be possible because this is a consequence of the math and not of the code.

 

 

I'm still not 100% sure that every aspect of this will work, but if it does it should save us some time since we won't have to reanimate all the AI.

 

Yup! This also means that we can create variations on the models by slightly altering their height.

[Ishtvan]

Yes, it's a key in the entity spawnArgs so mappers could set it to size things. I still have to iron out some things though before putting it up on CVS. Statics shouldn't have any problem.

 

For some reason on items with physics the physics axis keeps getting reset by something I haven't found yet, and it happens when the physics run. So I can scale the clipmodel by the same amount as the render model initially, but it pops back to the old clipmodel when physics runs, and then the renderEntity axis is rotated by the clipmodel axis, so if I don't correct it every frame, it also pops back to the original size when physics is run. I tried to find it last night but couldn't yet. It could be something outside the SDK, or just something I haven't found yet. Even if it's outside the SDK, maybe we could correct it right afterwards. Id didn't write the code with this scaling in mind, so in some places they set various axis back to the Identity matrix which clears any scale factor. I just have to find these places and correct it if possible.

 

One solution might be to leave everything else alone, but alter the SetAxis or GetAxis functions to make sure they incorporate the scale factor there.

 

Resizing statics should be fine because they don't run physics, although I'm not sure if they have the same shadow problem.

 

The most important one for our case is actors (AI). It's weird, I can see the collision models are scaled correctly for all the bodies of their AF, but I'm experiencing some weirdness when trying to hit them in combat. Could be the combat model is not scaled correctly. Also when they go into ragdoll mode, they stay scaled visually but the AF pops back to the original size, which is not surprising since I haven't edited AfEntity yet. Also the shadow is rather messed up as I've said. I still have some tests to run to see what's going on.

[Domarius]

I was talking to my superior about this (a programmer) and he said the reason you don't resize mesh's in real time is that the normals of the polygons aren't scaled as well, which causes innacuracies with the lighting/shading on them, so re-sizing needs to be done in a 3D app.

 

I'm no expert on this, but that builder looks like he's being lit from below, yet you're aiming the torch down onto him.

[Ishtvan]

Why would the D3 renderer scale the diffuse map but not the normal map? That doesn't really make sense to me. It's scaling the entire renderentity axis, which seems to work to tell the renderer to scale everything.

 

I'm not sure it looks like he's lit from below, that could just be the circular falloff from the flashlight which is hitting somewhat to the right of him. What test would I have to set up to prove whether the normal is scaled or not?

[Ishtvan]

Btw, note to self:

 

Entities update their visual position and orientation from the physics

using GetOrigin() and GetAxis(). Direct origin and axis changes of

entities should go through the physics. In other words the physics origin

and axis are updated first and the entity updates it's visual position

from the physics.

 

This means I should definitely write SetAxis in the physics to take into account the scale factor, and maybe leave everything else alone, in order to rescale an entity. Unfortunately, SetAxis is overloaded on a variety of different physics objects, which means I'll have to alter a number of files.

[Ishtvan]

Argh, I just spent a few hours doing this the "proper" way adding a scale factor to the physics obj and rewriting all the setaxis and other calls to multiply by the scale whenever it changes the orientation. So far though "something" is setting it back for moveables (they start out scaled, but then whenver they're moved they pop back to original size, or, depending on what I change, they can also go into a crazy superposition of different sizes and eventually fall through the floor, but I cannot get them to scale down and stay that way so far), when they collide with things, and it's not even working for statics for some reason. The quick hack setting the renderentity axis works a lot better than the "proper" way so far.

[Domarius]

Why would the D3 renderer scale the diffuse map but not the normal map? That doesn't really make sense to me. It's scaling the entire renderentity axis, which seems to work to tell the renderer to scale everything.

No, the normals of the polygons.

I'm not sure it looks like he's lit from below, that could just be the circular falloff from the flashlight which is hitting somewhat to the right of him. What test would I have to set up to prove whether the normal is scaled or not?

I'm no expert, but I'm certainly going to ask my head programmer about it tomorrow.

[OrbWeaver]

I understood normals to be unit-sized, which means they should not be scaled. The direction of the normals would not change whether scaled with the model or not, so the issue would be whether their size is scaled and whether the renderer has a problem with this or not.

[Domarius]

Yeah that's what I thought to, so I'm going to ask him for more detail.

 

Regarding the lighting angle of the builder - the main thing that's making me suspicious is the highlight on his breastplate. It's down at his waist, where it's angled downward. I would expect the highlight to be up on his upper chest, where it's pointing upward, if you're shining the light down on him.

[Ishtvan]

I understood normals to be unit-sized, which means they should not be scaled. The direction of the normals would not change whether scaled with the model or not, so the issue would be whether their size is scaled and whether the renderer has a problem with this or not.

 

I don't know much about this either, but it seems like the normals would need two things, a point of origin and a direction. The direction is just a direction vector and it doesn't need to be scaled. The point of origin I would assume would be related to the coordinates of the polygons themselves, since the normals extend out from the poly faces. Since the renderentity is being scaled down and scaling the poly's down, I would hope that the coordinates for the faces of the poly's (which is where the normal vectors would "attach") should scale down as well, but I don't know.

[Domarius]

Okay here's what he said;

When using vertex lighting the normals are stored in your vertex data.

When you scale your mesh the normals will become denormalised. You

should be able to enable hardware renormalisation to counter this. I'm

not sure what the speed hit is these days.

 

http://cs.anu.edu.au/~Hugh.Fisher/3dstuff/ogl-lighting.html

http://www.ogre3d.org/phpBB2/viewtopic.php?t=12397&

 

If you're not using vertex lighting, you may not have a problem.

[Ishtvan]

Hmm, that doesn't sound good. How sure is your colleague that the D3 renderer also does it this way? We don't really have any way of knowing ourselves without asking Id. This whole thing would be a good thing to ask Id about actually, because it could be some part of the engine we don't have that is setting the physics collision models back to original size when they move, too. I looked all thru the physics code that we have but haven't found it yet, and I know Id has some CollisionModelManager thing that is not accessible to the SDK, so that could be what's doing it. Too bad they don't respond anymore.

[SneaksieDave]

Has anyone ever gone to Mr. Carmack himself for these types of questions which go unanswered? Maybe the other guys don't know. He is surprisingly willing to answer a question, especially if you load it down with all kinds of technical mumbo-jumbo and questions, so he knows you're bright enough to understand his answer (and worth the time).

 

Heh, I remember for Quake, I wrote to him asking what happened to the skies? How they used to be nonsolid in the leaked alpha which I was acknowledging having an illegal copy of, and he answered me back, "Yeah, I fucked that up I when I redesigned the collision to handle..." [snip, I don't have it memorized]

 

johnc@idsoftware.com (it used to be that; if it changed, I'm sure it would be jcarmack)

[Ishtvan]

He would probably just laugh at my poor knowledge of the rendering process.