A neat trick, generating animation files from vscript

[shotgunefx]

Now I don't know how useful this will be for everyone, but a thought from a long time ago bubbled back up while I couldn't sleep an tried to give it a go and in initial tests, it actually works pretty well.

It still needs a tad bit of tweaking to fix some rotation issues (but it's mostly qc stuff),

But basically you run the script on yourself, then fire a startrecord() on yourself, then fly through your map like you want your intro/outtro camera (or heli, car, whatever) then dumprecord() and it spits out a smd file all set to cut and paste. It also spits out the position in the map for you to place your prop_dyanmic

Then bring it into blender or SoftImage and tweak it if you want (though looks pretty good out of the console).

I'd also like making a version for physics props. So you could set up some, say cars running the script, blow them up with in game entities and record it. When you get a take you like, dumprecord(), compile it and place it where it tells you and you should get an animation that is pretty much exactly what you saw without all the lag of a bunch of physics props. I don't think multiple bones in one file will be any big deal, probably just name them after the phys props.

Though one issue I see is it's pretty hard to figure which way an entity is facing. Man I hate Portal2, very jealous. I wish Valve would port over the easy stuff to L4D2, very stupid a script cannot figure out which way it's entity is facing, or trace a line into the world. How much can you do with that?

So for right now, it's best to just use your mouse and W and glom GetForwardVector as it happens to be the way your facing.

I do foresee a few potential problems. One is the backbuffer of the console isn't very long. I just assumed that the file options in squirrel are locked out, but I'll give it a go, if so, I'll just write straight smd files.

Failing that, I can set it up to dump N frames at a time, or possibly get it to log it somewhere.

But either way, might be handy for people who don't want to learn a modeling package for simple stuff. Definitely think it's good enough for making intros and outtro's out of the box as long as you can replicate the action you want walking or noclipping.

Stay tuned.

[The_Rabbit42]

Holy ♥♥♥♥, that is cool. If you keep experimenting with this, I'd love to hear what else you find.

[shotgunefx]

Originally Posted by The_Rabbit42

Holy ♥♥♥♥, that is cool. If you keep experimenting with this, I'd love to hear what else you find.

Well the basic version is actually pretty simple, I'm doing nothing more than saving the origin and forwardvector during recording and constantly refiring on myself. Then when I'm done, I simply print out an appropriate smd file minus the initial position

[shotgunefx]

A little follow up. Unfortunately, I don't think this will work for L4D2 unless someone more mathematically inclined can provide some help.

The problem again is I can't tell which way I'm facing and I can't even fake it. I tried taking the estimate between currentpoint and last point but they still need to be converted to Euler and I'm just not smart enough to do it. Even If I parented something to the player to figure heading, I'd still have the Euler problem.

So as it stands, the best you could do is just record a smooth track, then fixup the rotation in another program.

On the plus side, Portal 2 has functions for that (GetAngles), just need to convert to radians, which is trivial, so I guess I'll start copying assets over.

And as far as writing large SMD files, well as I figured, file ops are blocked (as they should be), so my workaround is to let you print it piecemeal

DumpRecordFrames(0,999) // prints header and first 1000 frames
DumpRecordFrames(1000,1999) // prints just frames
DumpRecordFrames(2000,2100) // prints last hundred and end

[Rectus]

Originally Posted by shotgunefx

The problem again is I can't tell which way I'm facing and I can't even fake it. I tried taking the estimate between currentpoint and last point but they still need to be converted to Euler and I'm just not smart enough to do it. Even If I parented something to the player to figure heading, I'd still have the Euler problem.

Converting from rectangular coordinates to Euler's form is pretty simple: http://en.wikipedia.org/wiki/List_of...al_coordinates

Φ is the azimuth (horizontal angle).
θ is the inclination (vertical angle with 0 straight up).

Edit: If you want to use the direction the player is moving, you can use the vector from GetVelocity().

[shotgunefx]

Just about got it I think, here's a quick simple test. I need to work out a bug with the last frame but not a bad start. Not 100% perfect but pretty close.

http://www.youtube.com/watch?v=JmG7WyAR1IE

Some potential issues, at 30fps, you only have 333ms to do you're thing and not sure how steady the clock is. I can't use Think as it's too slow, (well I could), but for higher than 10fps, I'm basically just constantly refiring 1/fps away. I imagine with a lot of props/bones that host_timescale would help. I would think a slower rate would give it more breathing room. Anyway...

Basically all your phys props/ func_physbox, (could be dynamic too but I digress), just need to name them uniquely and have them register on load with the master script. Start recording, use your physexplosion (or wake them up, script random velocity, etc) and when you're done stop recording, that's pretty much it. The whole record+boom+stop cycle is best done by trigger otherwise you'll end up with unwanted frames.

To use it, copy and paste the smd/qc and compile, if it's just prop_physics, change the master script to a prop_dyamic with the generated model, your prop_physics to prop_dyanmics and SetParent and SetParentAttachment prop_ent_name (bones are named after the props it's recording for ease of use) for each prop and you're done.

func_physbox just become func_brush with the same caveat about parenting. I don't see why you couldn't change them all to propper models as well, just make sure they keep their origins.

And if it's brushwork, and you're not afraid of Blender or SoftImage, all you should have to do is propper it, and envelope each piece to the correct bone, so instead of having 40 func_brush brick's getting knocked from a wall, you can wrap it up all in one wall model and skip the whole parenting thing.

Hmmm, speaking of Propper, I should hit up the author. I wonder if there is some way to shoe-horn in weights, then you could just propper+anim.smd and you're done I think.

And while it's no replacement for SoftImage or Blender, it's FAR easier, and if you can get good results, probably much faster time wise.

It's still a pain dumping frames as you can only get about 1000 lines at a time. (though I haven't checked if you can change that in Portal, can't change the console back buffer in l4d2).

I'll make a GOOD example maybe Sunday, then I'll do some more testing, some cleanup, and some additions like generating the qc file, or at least the attachments. Barring any unforeseen issues, I should have a version 1.0 posted within the week.

[shotgunefx]

Originally Posted by Rectus

Converting from rectangular coordinates to Euler's form is pretty simple: http://en.wikipedia.org/wiki/List_of...al_coordinates

Φ is the azimuth (horizontal angle).
θ is the inclination (vertical angle with 0 straight up).

Edit: If you want to use the direction the player is moving, you can use the vector from GetVelocity().

I missed this. Well for anything like recording phys sims, Portal 2 is the way to go and l4d2 is just not going to work.

But as far as for camera intros and such..., wouldn't I want GetForwardVector instead of GetVelocity? I mean it's the same thing just normalized. Anyway, as I said I'm math impaired and that's giving me a headache lol, if you want to write it out as pseudo code, I'd be happy to try it, but for my needs, Portal 2 seems like the way to go.

But seriously, with a handful of the additions Portal 2 got, scripting could do so much more in l4d2. I want TraceLine dammit. And really, no IsIncapped? IsBot? IsDead? But getting off topic.

[Rectus]

The only reference I have is the dev wiki, and it's not really clear on what GetForwardVector does. The values get normalized anyway if you convert to Euler's form and assume the radius is 1.

I'm not sure on how you want the data formatted, this should give the angles in radians in the same format hammer uses.

azimuth = atan2(x, y)
elevation = 0 if z is 0, otherwise (PI / 2 - atan( sqrt( pow(x, 2) + pow(y, 2)) / z))

I have no idea how .smds work, so I'm not sure if this will work at all.

[shotgunefx]

Originally Posted by Rectus

The only reference I have is the dev wiki, and it's not really clear on what GetForwardVector does. The values get normalized anyway if you convert to Euler's form and assume the radius is 1.

I'm not sure on how you want the data formatted, this should give the angles in radians in the same format hammer uses.

azimuth = atan2(x, y)
elevation = 0 if z is 0, otherwise (PI / 2 - atan( sqrt( pow(x, 2) + pow(y, 2)) / z))

I have no idea how .smds work, so I'm not sure if this will work at all.

Now THAT I understand. Thanks. I'll give it a spin. The difference is GetVelocity is normalized, GetForwardVector is not but both the direction you are moving (not necessarily facing).

Fun fact Vector.Norm does not normalize a vector, it returns a float

[Rectus]

Originally Posted by shotgunefx

Now THAT I understand. Thanks. I'll give it a spin. The difference is GetVelocity is normalized, GetForwardVector is not but both the direction you are moving (not necessarily facing).

Fun fact Vector.Norm does not normalize a vector, it returns a float

Maybe .Norm returns the normalization factor (inverse of the length). If so, you can normalize by multiplying it with the vector: v_norm = v.Norm() * v

[shotgunefx]

So... close. One thing throwing me off was, if you take a prop_physics, it has a different orientation than a prop_dynamic. So when you'd run the animation, the start and end would be the same, but any rotation would be off by 180.

One last issue I'm trying to squash, the animation works ALMOST perfectly. I've got an explosion with 25 bones as a stress test, func and props.

It looks fine, chairs and wall chunks barreling through the sky, but when they get near the end point, they start to lerp upright. Is this because it's transitioning to the idle pose?

One other neat thing, by looking at the changes in velocity, I can detect hitting something, which means I can generate sound and other events automatically

update

And thanks again Rectus for the tutoring

[shotgunefx]

Figured it out!

The problem is if you have a prop_physics that has "Don't take physics damage" checked, while it looks like it's rotating, the entity reports it upright (it doesn't simulate the collide), so it stays upright until it comes to rest, then reports the right angles. Grrrr.

Also, ,you can enable the console to log via con_logfile so dumping these giant animations is SO much easier. I'll post a video in a bit

[shotgunefx]

Coming along.

Check it out - http://www.youtube.com/watch?v=yxIMZ2tdysY

Now it seems that ent_fire will not fire quicker than 1/20 of a second even if you specify a delay of 1/30. Still, look pretty good. It seems due to the lower recording rate, it does miss some very fast rotations (watch the chair). I don't know if there are any cvar's that could be useful but it's still producing decent animations.

But conceptually, I really like this, use all the ents you want to create the motion and just record it out. Want a carousel? func_rotating and a bunch of tracktrains and record it out.

[shotgunefx]

So I've added the ability to reset. So now if you don't like the first take, Reset() put's everything back where it was and sleeps them. Set con_logfile and do take after take.

I also added playback (of sorts), unfortunately, if you're recording physic props, they will not take their angles while the engine keeps complaining.

Also finding some interesting (and some odd) things about Portal. It looks like you can actually modify the think interval, don't know if you can do it on a per object basis yet via nextthink, I'll try it later.

Some odd stuff, apparently Portal 2 has different limits on material name lengths. So a lot of my texes won't work and it refuses to compile. Since this is just for physics, I just replaced them with generics.

Really odd is that physics work differently with a map that has just gone through vbsp then one through vbsp+vrad (didn't run vvis). With vbsp only, large physboxes would act too light and fly very far, once I ran lighting, all of a sudden they would barely move. I had to up the explosions by ten. Setting max values actually tapers out pretty quick, you're better off firing the explosions multiple times.

And the lighting! Even regular old lightmaps looks so much better. I didn't appreciate how much until I saw my own map in it. Even textured wrong, shadows look great.

But as far as use cases, well, I don't want to give too much away, but I had an event in Map 3, it was pretty much a proof of concept until I could animate it propperly, anyway the part of the event I'll talk about is the power plant's smokestack collapsing.

I did an update to that with more gibs. It's still a temp but it gives you a better idea of what's gonna be possible. 40 bones, 15 seconds.

Notice the car on the right bouncing from the impact, that's recorded. That type of world interaction I think would be very hard to capture otherwise.

There's SMD for all these takes, just some keybinds and over and over until you get the right shot. So freakin easy.

The very last take is a playback, you can see how they stay upright no matter what.

http://www.youtube.com/watch?v=bRO5PhIwxSM

[jsmucha]

-That all looks pretty neat. Can't wait to see how it turns out in real time in the campaign.

-Is it possible to have a helicopter explode?