Chris Paulson

Good job at getting my code working so far. The IK stuff needs at lot more work on it to get it working. It needs to the following: - predict the next foot placement do a line pick on it Work out a height to place model/hips IK adjust both feet to meet correct floor height (determined by line pick) I halted work on IK stuff to get the blend tree code working, as this would effect the next foot placement. The first picture is showing a bug as it says the stance is "unknown", I have already fixed this bug in the animation analysis code. I really didn't think you'd get your head around my code so fast, amazing.

You might be getting called for each surface of the model the ray goes through.

Sorry Lumooja forgot to give you credits. Yes it has a old version of gamelib that I used to get myself started when moving from blitz to c++. I hacked a lot though to to fit my own needs and preferences. Lines of sight: - Can AI enemy see player checks

Just seen the vid with sound on. CLASSIC! PS Just need to swap the spiders out for women in underwear.

I guess if you've seen all my previous posts you'd not be shocked if I agreed strongly with this one. If recast (or any other navmesh/pathfinding) was integrated in everyone would have a really big head start on doing AI. We would then we would start seeing real graphics with moving pictures, instead of lots of nice oil paintings. It's a shame that I'm not a blitz/C++/Lua integration wiz else I'd do it tomorrow. It just needs the right person to find the time and it could be done. Trouble is it's not sexy like all the other graphical fluff...

Thanks for the explanation. It seems to work really well. Why are you doing blitz and c++?

Looks really good to me, better than my boring vids! Could you explain a little how things are working and what's going on?

File Name: myproject.zip File Submitter: Chris Paulson File Submitted: 11 Mar 2010 File Category: C/C++ Code Hi, a few more people have asked for my uptodate code including the IK animation, so here it is. Warning, it's all WIP, messy and unfinished and has it's pants down around it's ankles. If it's a help great, if not tough. Sorry for size of file, it's tricky to cut down without loosing too much. Thanks to Pixel for the player controller. Thanks to Tyler for math code. Included stuff:- recast nav mesh Behaviour trees (alive) Basic AI Steering Line of sight stuff IK animation animation definitions loaded from XML Blend tree's (WIP) Player gun animation Scene loading Gun/Bullet code Maths stuff Click here to download this file

I suspect ForEachEntityAABB might be best to use as this would be a scene graph type lookup and you would not have to loop as many entities per frame.

I've being working on a locomotion/animation system that will provide nice results and gives good transitions from one stance/animation to the next. I was inspired by articles I read on the Internet and the Unity locomotion video. Luckily the person who did the Unity locomotion system posted his thesis on the Internet so I could read some of the concepts and then do futher study of the concepts from the internet. The Unity system is highly mathimatical/analytical and because of this I have not done an exact copy, as to be honest it's out of my league, I'm not bright and my maths is poor. I've therefore implemented a system that requires less maths. Here's an overview of what I've done. The Problem ----------- To get an nice animation of someone standing still then breaking into a full run you need to blend idle into walk, into run, giving each one an ever increasing/decreasing blend weight. For example:- Idle weight 1 walk weight 0 . . . Idle weight 0.75 walk weight 0.25 . . . Idle weight 0 walk weight 1 . . etc etc However to blend a run and a walk together you need to synchronise the animations so the legs are in a similar position, otherwise the blend may cancel each other out and you'd get animation artifacts. To solve the problem you need to be able to take a leg position in the walk animation and match the most similar position in the run animation. The solution ------------- I have broken down walking/running into the following stance components:- Land - When the foot is flat on the floor (toe and heel on floor) Strike - When the heel strikes the floor Lift - When the heel leaves the floor (toe only on the floor) Flight - The foot is not on the floor I pre analyse the animations and work out where each stance start/stop frame is and it's length. This can then be used for synchronisation. I also work out the travel distance of a animation so I can accurately move a model/alter playback speed depending on it's movement speed and eliminate foot skate. Now for example if my animation was 75% of the way through a strike stance I can sync in the run animation 75% of the way through the same stance for the same leg. What blending gives me ---------------------- Instead of just having a idle, walk and run animation using blended weights I procedurely have the equivlent of 100's of animations between idle and run. What next --------- I've cracked (in a none refined way) blending based on speed, I can now move onto blending based on turning angle. For example: - If I was walking and turning at 45 degrees and I had an animation which did a turn of 90 degrees I would play 50% weight of walk and 50% of turn animation giving me the required angle. Hope the next stage works, wish me luck... Video of walk to run (to follow when upload done) --------------------- (I've only got 30 seconds of fraps) It might not look very sexy but it taken quite a few week of coding effort to get to this stage. In the text stats at the top it displays: - The master animation (the one with the hightest weight) The playback speed of each animation (controlled by the speed the model would be moving) The calculated weights and the calculated stance for each leg.

I think in UDK you could define render/post effect render volumes. ie You'd define a volume/area where a certain type of PP effect would be implemented. So for your example you'd have an area for SSDO on the outside area of your level and SSAO on the inside bit of your level. I suspect you could do this now with a bit of interaction with the framework and placing markers in the editor. Just an idea...

No, all you have to do is have a sphere big enough to cover the camera. It's an illusion with the sky dome as you place it in the background world. So you have: - background - for sky dome normal - for all other rendering foreground - for transparency

You could try EntityCulled but last time I tried to use it didn't work as expected. You may have to do your own field of view maths like line of sight maths then do foreachentityAABB.

PS If your aiming for a car sound check this out - my all time favorite car: -

Nice reply... cars with motorbike engines are nice - however going just in a straight line is waste of time and money. Cars are most fun on the loose (or snow) in corners. The best vid ever:

I can't believe you've said that and your a Fin aren't you - the gods of driving real cars. Go straight to youtube now and watch your country men driving real cars, and repent.

Thought I'd supply code anyway because I'm away from the forum for a few days. Code snipit: - It uses the height and min/max frig to cope with different size of terrains.

Use TerrainElevation. Raycasts are expensive I would get the TerrainElevation, unless you want to cope with models as well which would require you to do raycasts. I could supply example code if you can't find any.

The 50/50 split said it all for me. It really shows the difference. Nice work. Thanks Josh.

Is this going to be a multi-player game only with no bots?

I have very specific ideas for a game. However I never mention it because I don't want to be yet another indie game forum dreamer. Until I have a very extensive game engine in place I shall not start making a game. The forums are full of - I'm going to make a game like Crysis, but better - oh yeah, dream on. This often comes from people who don't even know how to do the basics.

If that was at me, I've already done this so sounds etc are stored against the entity key and are used when hit.

I do raycasts with my stuff. When I find a hit I apply a body force to the object hit. For bigger things like missles etc I might use bodies but I'm not onto that bit yet. My C++ code: - #include "gun/include/bullet.h" #include "gun/include/bulletHit.h" #define DEBUG_BULLET Bullet::Bullet( TVec3 pos, TVec3 dir, TScene *scene, float speed, int life ) : m_force( 100 ) { m_scene = scene; m_position = pos; m_origin = pos; m_life = life; m_direction = dir; m_speed = speed; if (!g_bulletEmitterMaterial) { g_bulletEmitterMaterial = LoadMaterial("abstract::dust.mat"); } HookUpdateEvent(m_scene->updateEvent); #ifdef DEBUG_BULLET HookRenderEvent(m_scene->renderEvent); #endif } Bullet::~Bullet() { UnhookUpdateEvent( m_scene->updateEvent ); UnhookRenderEvent( m_scene->renderEvent ); } void Bullet::moveBullet() { m_position.X += m_direction.X*m_speed; m_position.Y += m_direction.Y*m_speed; m_position.Z += m_direction.Z*m_speed; } void Bullet::Render( float gameLoopTime) { #ifdef DEBUG_BULLET if (m_life) SetColor( Vec4(1,0,0,1) ); // red else SetColor( Vec4(1,1,1,1) ); // red TVec3 nextPos = Vec3( m_position.X+m_direction.X*m_speed, m_position.Y+m_direction.Y*m_speed, m_position.Z+m_direction.Z*m_speed); tdDrawText( m_scene->cam, m_position, "1"); tdDraw( m_scene->cam, m_position, nextPos ); tdDrawText( m_scene->cam, nextPos, "2"); #endif } void Bullet::Update(float gameLoopTime) { TPick pick; m_life--; if (m_life<=0) { //delete (this); return; } moveBullet(); // Look speed metres ahead TVec3 nextPos = Vec3( m_position.X+m_direction.X*m_speed, m_position.Y+m_direction.Y*m_speed, m_position.Z+m_direction.Z*m_speed); if(LinePick(&pick, m_position, nextPos,0.0,0)) { builtHitForce( pick ); bulletHitEffect( pick ); // Create a decal if(pick.surface) { // Add decal if less than 20 metres away /* if(PointDistance(Vec3(pick.X,pick.Y,pick.Z), m_origin) < 20) createBulletDecal( pick, decal ) */ } //delete this; m_life = 0; return; } } void Bullet::builtHitForce( TPick& pick ) { TBody body; body = GetMeshModel( pick.entity ); if(body) { AddBodyForceAtPoint( body, Vec3(m_direction.X * m_force, m_direction.Y*m_force, m_direction.Z*m_force), Vec3(pick.X,pick.Y,pick.Z) ); // SendEntityMessage( topParent(pick.entity), "bullethit", body, 0 ); TEntity e = pick.entity; BulletHit *hit = new BulletHit; hit->m_direction = m_direction; hit->m_force = m_force; hit->m_origin = m_origin; hit->m_speed = m_speed; hit->m_pick = pick; while (e) { SendEntityMessage( e, "bullethit", (byte*)hit, 0 ); e = GetParent(e); } } } void Bullet::bulletHitEffect( TPick &pick ) { TEmitter emitter; TWorld world = CurrentWorld(); //loadBulletSounds //If Not emittermaterial emittermaterial=LoadMaterial("abstract::dust.mat") SetWorld(m_scene->foregroundworld); //Richochet emitter emitter = CreateEmitter(20, 500, Vec3(0,0,1), 1); PositionEntity( emitter, Vec3(pick.X,pick.Y,pick.Z),1 ); AlignToVector( emitter, Vec3(pick.NX, pick.NY, pick.NZ) ); PaintEntity( emitter, g_bulletEmitterMaterial ); SetEmitterVelocity( emitter, Vec3(0,0,3), Vec3(1,1,0) ); SetEmitterAcceleration( emitter, Vec3(0,-9.8,0) ); //Dust emitter emitter = CreateEmitter(10,2000,Vec3(0,0,1),1); PositionEntity( emitter, Vec3(pick.X,pick.Y,pick.Z),1 ); AlignToVector( emitter, Vec3(pick.NX, pick.NY, pick.NZ) ); PaintEntity( emitter, g_bulletEmitterMaterial ); SetEmitterVelocity( emitter,Vec3(0,0,0.2),Vec3(0.1,0.1,0) ); SetEmitterRadius( emitter, 0.25, 0.25 ); EntityColor( emitter,Vec4(1,1,1,0.1) ); SetEmitterRotationSpeed( emitter,0.1 ); //Impact sound //bulletimpactsound.EmitNPCSound( "bullet", "bullet1", emitter ) SetWorld( world ); }

I believe a few games use similiar to what you are doing ie character controller points of accessibility/expansion. But they do it offline to build a navmesh from the results. Good example with FO3 and Unreal, however I beleive FO3 was a semi-auto/semi hand drawn navmesh. Unreal/UDK has now abounded waypoint graphs for nav meshes. Check out:- http://www.ai-blog.net/archives/000152.html Hope this helps. Chris

Actually my description may have been a bit misleading. In a square 2d grid the links to each square is the centre of each edge. Instead of square a navmesh is made of convex polygons, where the polygons touch (the edge) the centre is used. This page:- http://theory.stanford.edu/~amitp/GameProgramming/MapRepresentations.html#S9 does lots better than me at describing it.