Chris Paulson
-
Posts
134 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Posts posted by Chris Paulson
-
-
If your doing threaded stuff in C++ may I suggest the BOOST libraries.
I have examples code if you need it.
-
Just thought of another thing that would be great for making "thread safe". Raycasting (linepick), basically a working game will be doing 49% rendering, 29% pyhsics, 20% line pick and 2% other stuff IMHO. Linepicks are expensive so it would be great to be able to split them into a thread taking requests off a queue.
-
The idea here is that running non-mutable code in a secondary thread shouldn't cause problems. Now, I could see the issue of say, calling PositionEntity, RotateEntity, etc. in a secondary thread, or whatever. Actually, if you use semaphores and mutexes correctly, you wouldn't need to worry, threading would basically take care of itself...[/font]
I found everything to do with LE is not thread safe, even simple stuff like EntityPosition.
I would really like LE (or bits of) to be thread safe so I could sub-divide up my AI stuff into threads. It would be a big bonus if a single place like RenderWorld or RenderLights which are intensive were made thread safe.
-
Yeah, character controllers are hard on the physics engine it looks like. For that many characters dump the player controller and just do raycasts for whatever you need. I've had 200+ NPCs moving around at 20-30FPS, but they were only doing a raycast downwards to find out the terrain height, playing 2 animations and moving around. Are they all on screen at the same time? If not, maybe turn off their player controllers when they're not on screen or > than a certain distance away and enable them when it makes a difference?
I was worried that doing that many line picks would be just as slow. But with your evidence I'll drop the controller. I was going to in the future anyway as I wanted to do foot placement and IK as I think floaty NPCs on slopes/stairs looks "old hat".
For far off characters (not viewed by players eyes) I could use the navmesh as it knows an estimate of where the floor is and recast is very fast.
However footplacement my be beyond me and will be out of reach for a lot of leadwerks users, so the controller does need to be sorted.
-
Just to add to this I've recently done a test with 20 AI controlled NPCs. Each one uses a character controller to move about.
The update world statement takes 20 - 30 seconds
Hoping this can be improved on as I would like on a level >100 AI characters.
My machine spec is: -
GW-265 GAINWARD GEFORCE GTX260 "GOLDEN SAMPLE" *216 STREAM PROCESSOR* 55NM SLI 896MB DDR3 TV-OUT/DUAL DVI PCI-EXPRESS
250 GB SATA-II HDD UDMA 300 7200 8MB
Motherboard Integrated 5.1 Sound
Motherboard Integrated Ethernet Lan (Broadband Ready)
450W PSU
Motherboard Integrated Graphics
Corsair XMS2 4GB PC2-8500 1066 MHZ (2 x 2 GB) - Lifetime Warranty (DDR2)
Intel Core 2 Duo E7500 (2 x 2.9 GHZ) 1066FSB - 3 MB
ASUS P5Q 1600FSB (Intel P45)
-
This is the bit of code that works out teams: -
... pos = EntityPosition( m_entity, 1); box.X0 = pos.X - m_viewRange; box.Y0 = pos.Y - m_viewRange; box.Z0 = pos.Z - m_viewRange; box.X1 = pos.X + m_viewRange; box.Y1 = pos.Y + m_viewRange; box.Z1 = pos.Z + m_viewRange; ForEachEntityInAABBDo( box, (BP)checkIfEnemy, (byte*)this, ENTITY_MODEL ); ... int _stdcall checkIfEnemy( TEntity e, byte* extra ) { Vision *vis = (Vision*)extra; if (GetEntityType(e) != 3) return 1; // Not a NPC/Player string team = GetEntityKey(e,"team"); if (team == vis->m_team) return 1; // On same team vis->m_nearbyEnemy[ EntityDistance(vis->m_entity,e) ] = e; return 1; } -
Does this mean that using this method I would have to tell my AI Manager class how many enemies are around them and if they are within visible range? I ask this because I plan to have more than one "good player", like teammates following the player around.
Also, what if I want to check the amount of a character is visible? Like if only an arm or hand is seen, then I want the AI to be suspicious and investigate, etc.
The view cone is done by the viewangle bit of code: -
// observer vector TVec3 pos = EntityPosition( m_head,1); PositionEntity( m_pivot, pos,1); TVec3 tform = TFormVector( Vec3(0,0,1), m_body->pivot, NULL); AlignToVector(m_pivot, tform, 3, 1); TVec3 observerPos = EntityPosition( m_entity, 1); // pick vector float angle = angleToDest( m_pivot, m_targetPos ); if(angle <= (m_viewAngle/2.0)) {The bit about the box ie ForEachEntityAABB is getting a list of nearby enemies. I base it on the idea of NPC/players being in teams for example red team, blue etc. I store the team in a entity key. Anyone in a different team is considered to be an enemy.
Currently my code has only seen/not seen logic and I exits at the first line pick success. You could do all of them and work out a % visible but this would effect the FPS serverly.
-
Dear lord does that look confusing.
I tried to follow through the code but I ended up getting lost and confused. I'm not sure at which part he does the actual ray casting to check if anything is seen or not.
Tell me the bit your stuck on and I'll help...
Here's an overview: -
for each enemy in view range check if enemy in FOV for each bone of enemy do line pick at pos of bone if can see then exit end end endI use the bones as this will give me the different important parts of a body. This way if only a head or a hand etc is visible a linepick will succeed.
-
Well, the GMF SDK has a C/C++ API according to the page. And he might have some compelling reason to need to be able to generate them dynamically at runtime. I can't think of what it would be, but he might
It might even be possible to skip the export to file part and just use the SDK to load the model directly, but not sure.I've managed to make GMF files from C++ with the GMF library, so this would possibly be a good way to do it. Doubt you'd be able to skip the file part though.
-
+1 one for this. It would be nice if they had switchable viewmode (wireframe etc) as well.
Big ask... if you did CSG in the editor too you'd be closing the gap on UDK
. -
I'll put in a zip file all my code so far and put on my blog. I just need to tidy the VC++ project a little to strip out the third party libraries into LIB files.
It's a bit WIP rats nest a the moment so I may have give lots of explanations.
I did attempt to get recast to compile from with blitzmax but failed, that's why I moved onto C++. However I now realise I could have just compiled recast with VC++ into a LIB file and than use it from within blitzmax. I believe the failure was probably to do with compiler differences in the minGW and how into inits variables.
-
pick.X Y Z are the position
pick.NX NY NZ are the normals
-
This game?:
Sorry, couldn't resist. This looks really interesting. Maybe I can integrate it into the engine.
That would be brill!
It took me quite a long time, but only because I'm not very bright and I do all this between my wife nagging and finding me DIY to do.
Every game AI has it failure point see: -
http://aigamedev.com/open/articles/bugs-caught-on-tape/
For what it's worth I'll help anyway I can, but that would be like me trying to give Stephen Hawkins tips on black holes.
-
Yes, it now takes the absolute coordinates X1 Y1 and X2 Y2, each pair is its own endpoint.
Thanks that did the trick.
Thnaks Lumooja, I'll convert over.
-
My function: -
void tdDraw( TCamera cam, TVec3 s, TVec3 e ) { TVec3 p1; TVec3 p2; p1 = CameraUnproject( cam, s ); p2 = CameraUnproject( cam, e ); if (p1.Z < 0 || p2.Z < 0) return; DrawLine( p1.X, p1.Y, p2.X-p1.X, p2.Y-p1.Y ); }Seems not to work correctly anymore, one end of the line seems to be in the correct place but the other is always top left.
Has it changed?
-
Is that code meant for realtime use, or is it for precalculating navigation waypoints? It's very interesting.
Both.
Have you worked much with this system?
I have done a lot with it. I’ve got it to process levels created from the sandbox and I have used to for my NPCs to move around, going from A to B. The path finding is really fast, enough to handle many requests per frame. The generation of the static mesh can take a while, for example the island level as I remember took about 10 minutes. However when I wrote my own navmesh stuff it took in excess of 24hours to do the island level. For a level the size of the island it would take a lot longer to do manually lacing AI nodes I guess.
The generation can be refined with different config such as voxel size, slope angle, agent size etc. A Larger voxel size would speed the mesh generation.
Generation of a tile using the tile mesh method depends on the size of tile, you could probably only get away with doing 1 -2 tiles per frame. I guess this where threading would be really useful.
I’ll try and do a video of it working, however my AI stuff is still very flawed so I wasn’t proud enough of it yet to show it off. I’ll also publish all my code for anybody who wants to use it.
-
Chris is Recast your handy work?
I've been writing my own navigation mesh generator that runs in realtime, but its a long way behind the quality and speed of recast at the moment!
Word of warning, I spent six months working on my navmesh generation before I chucked my stuff for recast. You might be more successful as your probably brighter (thats not hard), however recast is done and working...
I'll share all my C++ code happily.
-
i was just searching for that Rick... i remembered you had done some work along these lines a lil ways back...
this might work here...
Chris... is Recast your work...
--Mike
Sorry for the delay, I didn't have access to the this forum. Recast is NOT my work, I've intergrated the library with Leadwerks. Recast is the work of chap who did the AI for crysis, so fairly good pedagree.
-
In the config it's an on/off option.
What I was after was the intensity, size etc.
-
Are you using C++ or Bmax?
I'm using C++
-
Not quite sure what you mean but this is what is in my sbx file: -
Model {
path="environment_atmosphere.gmf"
position=-2.00000000,0.000000000,1.00000000
rotation=-0.000000000,-0.000000000,0.000000000
scale=1.00000000,1.00000000,1.00000000
id=416742776
"backgroundcolor"="127,127,127,255"
"camerarange"="0.100000001,1000.00000"
"class"="Model"
"fogangle"="0.000000000,15.0000000"
"fogcolor"="234,233,215,255"
"fogrange"="0.000000000,200.000000"
"gravityforce"="0.000000000,-20.0000000,0.000000000"
"intensity"="1"
"name"="atmosphere_1"
"range"="10"
"reloadafterscript"="1"
"skymaterial"="FullskiesBlueClear0016_2_L.mat"
"volume"="1"
}
it has a "class", it has a "name" which is not fixed, it doesn't have a "classname".
-
For Bmax and C++ thats is necessary yes.
It would be nice if the sbx file had a classname in for atmosphere and ambient light otherwise I haven't got anything to look for against the model.
-
Just need to find out how to make my skybox appear now.
Guess I need to process the atmosphere model.
-
The only thing I can think of with the controller not moving is you have to add mass to it.
Correct solved my problems:
1) Line Pick - if you specify the radius param other than zero it is very very slow. Set param to zero and FPS returned to 120. Param didn't do anything pre 2.3.
2) val = (flt)atof(GetEntityKey(e,"mass","60"));
Was setting mass to zero not 60? Guess the default on entity key is broken. Editted my .sbx file and added mass and controller started working.
I guess these are things for Josh to fix in the future.
.
Game WIP
in Programming
Posted
File Name: Game WIP
File Submitter: Chris Paulson
File Submitted: 05 Jan 2010
File Category: C/C++ Code
Hi,
a few people have been asking for access to my code so here it is.
It's WIP so not tidy, as weeks/months go on it will hopefully improve and I'll post updates.
Credits go to:-
Pixel Perfect for the player controller
Lumooja for Gamelib (however I have hacked it to bits)
Mikko Mononen for recast
AIGamedev.com for A++
Click here to download this file