AI Color coding
Author
i was trying to think of a newer, and possibly easier, form of enemy AI. would it be feasible to draw every element the player uses in one color, maybe the common alpha pink. the character is drawn in pink, and maybe even the flashlight he/she projects is colored pink. all of the player elements are drawn in one color, and its only visible to the enemies. then maybe every quarter second the enemy gets a new render (maybe 128x128 or even 64x64) of everything its looking at. after the render is captured, its run through a loop looking for the pink color. if its found the enemy spots the player and does it's thing.
i posted this here because i will be using opengl to render it. how feasible do u think this would be?
Intresting idea.. Probably deadly slow though.. Reading from the videocard just isn't fast.. Could be quite cool though I suppose.. But think about 20-30 AI bots.. Not sure, but I kinda doubt your comp would like it.. I encourage you to try though..
yeah, readbacks would probably be too slow. perhaps you could manage to have the ai running on the gpu as well... i don't think gpus have become general enough yet though. but who knows. maybe reading back a single 64x64 texture each frame (and switch between units each frame) isn't that bad at all if your api calls are ordered correctly (ie the gpu has stuff to do while you're reading back)... it might even work. but you should probably put more information into that texture than just if there is someone there or not. alternatively you could render it in software, which would make including extra information (player id etc.) easier as well.
it seems someone else already had a similar idea (although also only the idea apparently) http://www.movesinstitute.org/Publications/AI-on-the-GPU.pdf
it seems someone else already had a similar idea (although also only the idea apparently) http://www.movesinstitute.org/Publications/AI-on-the-GPU.pdf
Author
i read that article, but i think they are talking about using two textures to track the movement of objects. that is definitely cpu/gpu intensive. my idea is simplay an activation of the AI. usually AI tracks the player by use of their position and maybe the bounding box. if you are walking down a hallway, casting shadows and pointing your flashlight, a normal person would hide and do a surprise attack. bots cant see the lights or shadows. it also makes it much harder for the player to hide by peeking around corners.
then again this is an idea thats going to take a bit of work to get going since i havent even started AI programming yet lol
then again this is an idea thats going to take a bit of work to get going since i havent even started AI programming yet lol
i think they are talking about using a player id texture and one texture which is rendered normally to determine (using computer vision algorithms which to a large extent can be executed on gpu) if the player can be visible.
...
you might well be using OpenGL to render it but the discussion isnt OpenGL related, thus moved to the AI forum.
you might well be using OpenGL to render it but the discussion isnt OpenGL related, thus moved to the AI forum.
I don't see the value of this. The math to determine the visibility of these objects might be less intense than actually rendering then reading. Locking buffers and reading will slow down all your other rendering as well. Maybe when shaders that output data become available (maybe 4.0!!!!) we could do stuff like this.
why not use simple occlusion testing? Draw all the occluding geom from the AI POV and then test the flashlight and the player. That would eliminate the read from textures?
Actually, JSoftware, Occlusion Culling would be perfect for this. 1) Setup a render target (128x128 or whatever) 2) Disable color writes, enable zbuffer read/write (saves bandwidth, some cards will render at 2x fill) 3) Render everything NOT attached to the player into your buffer 4) Render things attached to the player wrapped in an Occlusion Query. 5) Continue on with the game (in the previous state) until the query completes, then use the number of pixels visible to guage visiblity.
This would only have the cost of the render which will be mostly transform cost since the pixel shading will be very cheap. Framebuffer bandwidth would be a non-issue (due to simple pixel shaders, small resolution and z only rendering). And because the occlusion query is asynchronous no stalls or readbacks are needed.
This would only have the cost of the render which will be mostly transform cost since the pixel shading will be very cheap. Framebuffer bandwidth would be a non-issue (due to simple pixel shaders, small resolution and z only rendering). And because the occlusion query is asynchronous no stalls or readbacks are needed.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
