SVehicle

SVehicles are a vehicle base class for UT2004, as an alternative to the KVehicle of 2003.

SVehicle stands for Skeletal Vehicle: these still use Karma, but are based on skeletal meshes, using a single actor as opposed to KVehicles which spawn an actor for the chassis and 4 wheels. This cuts down on network bandwith. The new collision system works by letting the user add box or sphere primitives to any bone of any mesh, and specify the scale offset from that bone. There's also an option in UnrealEd for a "collision static mesh" (though specifying a static mesh with collision data doesn't seem to do anything useful, so it may be this is broken or not yet implemented).

SVehicles are an improvement on KVehicles because:

1. They take less CPU to simulate.
2. The art pipeline is easier because they are just one mesh.
3. They reduce the number of actors in the level.
4. They use less network bandwidth.
5. The code is much simpler (no big setup functions to spawn wheels, no complex net pack/unpack).
6. They allow more control over the 'wheel'/ground interaction.
7. They allow weighted skinning for suspension parts etc.
8. Shadow projectors work properly.

Properties

Main

bool bDrawDriverInTP

Whether to draw the driver when in 3rd person mode.

bool bDrawMeshInFP

Whether to draw the vehicle mesh when in 1st person mode.

class<Actor> DestroyEffectClass

name DriveAnim

Animation to play while driving.

vector DrivePos

Position (rel to vehicle) to put player while driving.

rotator DriveRot

Rotation (rel to vehicle) to put driver while driving.

array<vector> EntryPositions

Positions (rel to vehicle) to create triggers for entry.

array<vector> ExitPositions

Positions (rel to vehicle) to try putting the player when exiting.

vector FPCamPos

Position of camera when driving first person.

int MaxViewPitch

Maximum amount you can look up and down

int MaxViewYaw

Maximum amount you can look left and right

float Rise

between -1 and 1

float Steering

between -1 and 1

float Throttle

between -1 and 1

float TPCamDistance

vector TPCamLookat

float VehicleMass

Affects how much impact the propulsion, turning, strafing, etc. the vehicle is affected by. Lower means less mass and thus more impact (i.e. Raptor has mass of 4, Goliath has mass of 12) ~~~ presumably this also affects impacts between vehicles?

array<SVehicleWheel?> Wheels

Wheel data

Hidden

bool bGetOut

Pawn Driver

array<SVehicleTrigger?> EntryTriggers

SVehicleFactory ParentFactory

ShadowProjector VehicleShadow

Functions

Basically the same as KVehicle, but also abstracts some of the functions from KVehicles' subclasses bulldog and KCar.

TakeDamage( int Damage, Pawn instigatedBy, Vector hitlocation, Vector momentum, class<DamageType> damageType )

Same as in KVehicle, except pc.PawnDied(self) is commented out.

FaceRotation( rotator NewRotation, float DeltaTime ) (simualted)

Overides this pawn function because vehicles ignore this call.

PostNetBeginPlay() (simulated)

A simple, abstract version of the one in Kcar. Do any general vehicle set-up when it gets spawned. This function just basically creates triggers for gettting into the vehicle like the bulldog class.

ClientKDriverEnter( PlayerController PC ) (simulated)

Same as before in KVehicle (events called on driver entering/leaving vehicle).

KDriverEnter( Pawn P )

Same.

ClientKDriverLeave( PlayerController PC ) (simulated)

Same.

bool KDriverLeave( bool bForceLeave )

Same.

Destroyed() (simulated)

Same, but also destroys triggers used for getting in and the shadow projector.

PostBeginPlay() (simulated)

This function is *new* but it just glues a shadow projector on.

bool SpecialCalcView( out actor ViewActor, out vector CameraLocation, out rotator CameraRotation ) (simulated)

This has been extended a bit and includes fist person as well as third.

Events

EncroachedBy( Actor Other )

Same as in KVehicle.

VehicleStateReceived()

Called from C++ PostNetReceived(), seems to be called every time PostNetReceived() is called.

UpdateVehicle( float DeltaTime ) (native)

Do script car model stuff here - but DONT create/destroy anything

SVehicleUpdateParams() (simulated)

This event serves the same purpose as KVehicleUpdateParams(): to reset any vehicle physics related stats. Called when a parameter of the overall articulated actor has changed (like PostEditChange) The script must then call KUpdateConstraintParams or Actor Karma mutators as appropriate.

Tick( float deltaSeconds ) (simulated)

Exactly same.

Known subclasses

• ONSVehicle – Parent class for all Onslaught vehicles and vehicle weapons.

Related Topics

• Vehicles – Main topic for all Vehicles
• Physics?

Discussion

O-GL: Sorry for the lack of info on this page ... help! Is it just me or is SVehicle very similar to KVehicle?

MythOpus: IT is. It just uses a [Sketelal system]?

AlphaOne: What is the difference between a SCopter and a SHelicopter?

Foxpaw: I don't think SVehicle even uses a skeletal system. I think the distinction is that KVehicles use Karma, while SVehicles use proprietary Unreal physics. (PHYS_Falling and such) I think the "skeletal" comes from the fact that non-static meshes (aka vertex meshes) are being called skeletal meshes by everyone now. And that's probrably what this class is designed to use. Or something.

Wormbo: No, SVehicles use Karma and skeletal meshes, that's what the Epic people tell us.

..... refactor me

Foxpaw: Oh. So it's just a KVehicle with DT_Mesh? It's already known (at least it's on Karma) that a Karma actor can have any drawtype.. so I'm figured there would have to be some logical reason to make it a different class. Unless Epic doesn't realize that you can have a different drawtype with Karma and hacked it in natively?

O-GL: KVehicle is DT_Mesh. Bulldog is the only one with DT_StaticMesh. What I didn't realize before is that skeletal meshes (aka animations) can have some sort of karma collision. I always used to think only static meshes could have karma collision information attached to them ... apparantly not https://docs.unrealengine.com/udk/Two/AnimBrowserReference.html#Collision is this new? Anyway, I'm sure modellers would prefer the static mesh way where they could create a Karma hull within a program such as 3dsmax and export it with the model. Using primitives in UED sounds ... primitive . Also, if that and the seemingly hackish physics don't turn you away from SVehicles, the word 'native' in every class probably will. I hope its not the same in UT2004.

Foxpaw: Not sure if you noticed on Karma or not, but as I said, any drawtype can use Karma. (not sure if Epic realizes this, maybe that's why they made this class) Even sprites can use Karma. Just set staticmesh to the mesh you want to use for the dynamics, tgeb set DrawType to whatever you want to be displayed. The Static Mesh is always used for dynamics, but does not require DT_StaticMesh to work.

Wormbo: The DrawType only specifies how to display an actor. Karma always uses the StaticMesh for its calculations. I'm sure Epic is fully aware of this, and sice classes allow logical grouping of functionality it makes perfectly sense to create a new class for karma vehicles that use skeletal meshes instead of combining multiple static mesh actors.

O-GL: Any comments on the [UDN link I posted]? Why were they talking about adding karma collision to an animation in the animation browser? It seems that you do not require a .usx with karma collision data anymore, but instead, you can use a .ukx (ie DT_Mesh and mesh=) with no need for static meshes. Wormbo, I think the main issue is that Epic prefer to add items onto bones instead of constraints because its much easier. Like for example vehiclular turrets and characters could just be attached to a bone and manipulated accordingly. And, I guess, the characters and turrents wouldn't rotate realistically because they are oriented according to the rotation of the bone they are attached to (instead of being motorized physically to achieve a certain rotation).

Foxpaw: I did go to that UDN link - it does appear that it is a way to add a more precise collision to a model that would normally have cylinder collision. However, I don't know if that applies all the time, or only when using PHYS_Karma or PHYS_KarmaRagdoll. Well. To that I say.. I don't like it! Skeletal meshes are slow, mmkay?

O-GL About the link, I think adding karma collision to meshes is new. It is there because (probably) it is going to be in UT2004 plus it is already in the UER:UED. I have tried it out and it works as described. This quote by James Golding on the Epic mailing list states:

For each box you can say if it should block Karma, Zero Extent and Non Zero Extent traces. For Karma it takes the bones in the reference pose and bakes a solid collision shape out of this. Animating the bones in the game does not change the karma collision (ie that used when you drive into a building, or when another vehicle drives in to you). For Unreal collision (zero and non-zero extent) the boxes do move with the bones if you animate/control them. Note that Unreal physics won't pick up the velocity of the bones though - so if you are standing on a bone's box, and it translates due to animation, you will slide off.

Something interesting about this collision is that it can be set to either block karma or unreal physics (although I didnt notice this option in the UER:UED so this option must be in UT2004). Sweet thing is, it looks like we can get a more accurate player collision and we're not stuck with cylinder collision. Per-poly collision was touted as one of the most interesting gameplay features of Doom3. I’m not sure if you can have a Karma collision for general collision and Unreal collision inside this karma collision for shot/trace collision detection only.

Foxpaw: I don't think that cylinder collision for most stuff is bad. The only place this sort of collision would be useful at all would be on very large meshes, because on general player meshes and such - because a player IS more or less cylindrical. Plus non-cylinderical or non-spherical collision takes about 1000 times as long to compute.. mm.

O-GL: Foxpaw, are you drunk ? You don't sound so good.... I think that it also depends on the type of game. In UT where the players move like acrobats on steroids, I dont think it matters so much because they are moving so fast that its hard to hit stuff at all. But in a slow-paced realism game like CS, maybe more realism is a good thing.

Foxpaw: Well, the thing about non-cylinder collision for players on foot is, that cylinder fits a player very snugly. The change of you hitting a person's cylinder but not actually having the trace pass through a part of their mesh is next to nothing. (the exception being while swimming) I could see it having use where there is a considerable chance of something like that happening, like on some kind of giant tentacled monster, but for regular humanoids, the chance of that is next to nothing, and what with the hit effects and such you wouldn't be able to see where your shot landed precisely enough to know that it didn't technically hit a part of the skeleton anyway. More accuracy is always better, but I think that the processing resources that that sort of collision requires would be better spent elsewhere, like on higher polygon counts for those same meshes.

O-GL: Agreed. Add that to the fact that most games have a lock step of 30fps in internet games, the server's not exactly going to accurately judge the trace. Im drooling about the number of polygons in future games more than I am about improved shot collision. Doom3 uses really low poly counts too .

Foxpaw: Really? According to some of the press I've heard about it it has trillions. ID went so far as to claim at one point that the game uses no texture maps and everything, "down to the hairs on peoples heads and individual pores on their faces" was just modelled in 3D. Of course, I'm fairly certain that that was a load of BS on ID's part and that the game will use texture maps.

O-GL: I dont know if thats the same Doom3 I'm thinking of ... I'm thinking of a game with shadow volumes and normalmaps on everything. They probably did model some things with no texture maps and insane poly counts just to get good looking normalmaps, but then just dumbed the model poly count down to 2000 or so to make it run ok with shadow volumes. IMHO, the unified lighting system runs too slow to be useful for most games. But, such a moody singleplayer game sorta requires shadows. Considering most games arent of this type, I think John Carmack needs to stop making his space rocket and start making Quake4, or something.

Lilguy:Yikes, getting a little off-topic here...Well, it seems most of the discussion up to this point has been speculation, so here's the skinny on SVehicles: first, they're a single actor as opposed to KVehicles which spawn an actor for the chassis and 4 wheels. This cuts down on network bandwith. Secondly, the new collision system works by letting the user add box or sphere primitives to any bone of any mesh, and specify the scale offset from that bone. There's also an option in Ued for a "collision static mesh" but I've yet to figure out what that's actually used for (Specifying a static mesh with collision data doesn't seem to do anything useful, but feel free to correct me on this. I added a few comments at the top, and added this to category UT2004

Foxpaw: Hmm, I have to disagree with some of the points that you added - number one, you can add sphere and square collision primitives to static meshes, in any pattern or orientation that you desired. Also, KVehicles do not require a static mesh to be used for the display. You can use a skeletal mesh for display and static mesh for the physics, if you are so inclined.

Also, having the separate actors does not use more network bandwidth - this is because each actor does not handle it's own replication. The "main body" collects information from all the "parts" and packs it together, then sends that over the network. KVehicle does not use the regular movement replication system, as Karma is too unpredictable. Instead, it replicates the Karma rigid body state, allowing a client to keep up to date with the simulation itself, rather than the movement of the objects in the simulation.

Also, although it's something of a matter of opinion, native subclasses for certain types of vehicles is not really a good thing. Since they're native, your ability to modify them is strictly limited.

Lilguy: Well my point was that the primitives you added were rigid, despite the fact that the KVehicle could be using a skeletal mesh. If you wanted moving collisions, you needed a seperate actor. ( clarified that in the list.) As far as network bandwidth, I'm taking that straight from the mouth of Steve Polge. I couldn't find the quote from the ut2003mods mailing list because I forgot the password and don't have any messages left in my inbox

I understand that naitive classes are limited, but I think without naitive implementations of the physics used with those different types of vehicles, we wouldn't have had the quality of gamplay that we do in 2004. If there's something you really wanna do, I don't think there's any reason you couldn't do it in a subclass. Or, if you don't like the naitive implementation, write a non-naitive version and use that instead!

I just found a quote by James Golding on SVehicles, so I replaced my "better than" list with his. I can certainly attest to number 1: if you stick a Karma actor in a level, then run it over with a bulldog, your framerate dies. But SVehicles don't seem to have a problem when you stack 'em all up.

5parrowhawk: Does anyone know why vehicles won't respond to throttle/steering/rise changes when a driver isn't present? Is there a hack to get around this?

Switch` Most vehicles shut down when there's no driver, it's by design. Regarding native onslaught vehicles, you could try putting a dummy pawn inside. You can have a custom driver-less Vehicle, KVehicle, SVehicle or ONSVehicle but some events might not be called in some cases. You'll have to roll your own or enable them somehow, ie KWake() or Enable(). Also you'll want to check all the script functions for any driver-less incompatible code.

---

Refactor Me

Tarquin: Do we need a page just on [karma collision]??

SuperApe: This page need some work. Package name for one. The function and event defs could really be made clear without saying, "Same as KVehicle". A bunch of refactoring too. (added tag)

---

Category Class (UT2004)

Refactor Me – See discussion comments above.