Quote: Original post by RedDrake
Stall the pipeline in what way ?

Are you speaking of the cost of reading from video memory ?
I think this is an AGP related issue, and with PCI Express cards this should not be a problem.

No, it's not about the lack of bandwidth, it's about how rendering pipelines work. When you are sending pixel 200 to the gfx card, pixel 1 might not even have been rendered yet, never mind pixels 2-199. That's what makes the cards so fast - while one thing is being transformed, the next is being lit, the next is being projected, blended, checked against a z-buffer, etc. They incur a little bit of latency in return for maximum output bandwidth. If you then want to take a snapshot, but want an accurate depiction, you have to wait for everything in that pipeline to make its way to the end. Then the whole pipeline has to stop while you copy data from the render surface back to main memory, because you don't want new data overwriting what you're reading. So you start incurring that latency once per read, rather than potentially just once per program.

If you're interested in how many pixel of an object/character are visible from an AI's point of view, you could do a hardware occlusion query ( IDirect3DQuery9 interface in Direct3D, not sure about OpenGL ). If you're using shadow mapping, you could also see if the character is visible from a light when your rendering the shadowmap by also doing an occlusion query. If you're using stencil shadows, I'm not sure but the occlusion query might take into account pixels rejected due to failing the stencil test as well, might be worth looking into.
As for the idea in general, the idea of AI being able to spot a player realistically is hard to translate into behavior that will be at all noticable to the player. I'm sure it would be fun to program though. :)
Daniel

Quote: Original post by Kylotan
No, it's not about the lack of bandwidth, it's about how rendering pipelines work. When you are sending pixel 200 to the gfx card, pixel 1 might not even have been rendered yet, never mind pixels 2-199. That's what makes the cards so fast - while one thing is being transformed, the next is being lit, the next is being projected, blended, checked against a z-buffer, etc. They incur a little bit of latency in return for maximum output bandwidth.

I know that pixels are rendered parallel trough multiple units, but other stuff you said does not make any sense to me.

Quote: Original post by Kylotan
If you then want to take a snapshot, but want an accurate depiction, you have to wait for everything in that pipeline to make its way to the end.

Don't you always have to wait everything to get to the end ?? Before you flip your buffers, back buffer needs to be rendered fully. I don't get this part.

Quote: Original post by Kylotan
Then the whole pipeline has to stop while you copy data from the render surface back to main memory, because you don't want new data overwriting what you're reading. So you start incurring that latency once per read, rather than potentially just once per program.

This makes even less sense than the last one to me. Why would the pipeline stop while i read the data back to main memory. Once I render the AI scene frame in to custom render target, it's in video memory not in back buffer as far as i know, and from there it's only a bandwidth issue.

Maybe I am wrong at something hear, so please correct me.

Quote: Original post by FBMachine
If you're interested in how many pixel of an object/character are visible from an AI's point of view, you could do a hardware occlusion query ( IDirect3DQuery9 interface in Direct3D, not sure about OpenGL ). If you're using shadow mapping, you could also see if the character is visible from a light when your rendering the shadowmap by also doing an occlusion query. If you're using stencil shadows, I'm not sure but the occlusion query might take into account pixels rejected due to failing the stencil test as well, might be worth looking into.
As for the idea in general, the idea of AI being able to spot a player realistically is hard to translate into behavior that will be at all noticable to the player. I'm sure it would be fun to program though. :)
Daniel

Wouldn't it be faster to render the scene with light's only enabled on character then do occlusion query for AI view, and then from each light point, and then sum the amount of light character receives ?

Or even faster, using SM3 just test from Pixel Shader if the character pixel is receiving enough light. And then draw only the pixel's that received enough color in constant color ?

As for the player noticing AI acting realistically – IMO it gets quite frustrating when enemy sees you in “full” dark, and you can't even see him.

Quote: Original post by RedDrake
Wouldn't it be faster to render the scene with light's only enabled on character then do occlusion query for AI view, and then from each light point, and then sum the amount of light character receives ?

Or even faster, using SM3 just test from Pixel Shader if the character pixel is receiving enough light. And then draw only the pixel's that received enough color in constant color ?

Sounds good to me. Even better, don't retrieve the results of the queries until the next frame so you don't have to wait for each query to be finished rendering. You'll be a frame behind, but my brain is usually a few frames behind. ;)

Quote: Original post by RedDrake
As for the player noticing AI acting realistically – IMO it gets quite frustrating when enemy sees you in “full” dark, and you can't even see him.

Shadowed areas can be precomputed though. And you can do antiportal tests for dynamic lights. That said, I'm not trying to discourage anyone from trying this. ;)
Daniel