Jump to content
The Dark Mod Forums

A Problem Existent In Past Thief Games


woah

Recommended Posts

Is there a compelling gameplay reason to have sound that only spreads in one direction? In the physical simulation, that would only happen for the first wavefront, but after that an echo-ey room would just reflec that all around into a diffuse reverb field in a few millisecons, which would be psychoacoustically indistinguishable from a sound that had spread in all directions. So it's not really realistic indoors.

 

An asymmetric sound like this would only keep the angular dependence if it occured in a large open area with very far away walls, but even then you'd get some reflection and redirection off of the ground. Also, there's the question of whether the sounds we're modeling (footsteps, dropping things, explosions, yells, etc) ever have a strong asymmetry?

 

If there's a compelling gameplay reason I could maybe hack it in to the soundprop system by having AI and portals in the first room of propagation (i.e., the room that the sound occurs in) check their angle to the source and compare it with some arc in which the sound is supposedly spreading, then modify the amplitude at that point appropriately. That would give the amplitude in the first room some angular distribution, then portals hit by that angular distribution would just continue to propagate normally, but with different amplitudes than if the sound had spread spherically.

Link to comment
Share on other sites

  • Replies 186
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

Thanks for answering my questions Ish.

 

Is there a compelling gameplay reason to have sound that only spreads in one direction?

 

yes, the sound travelling in one direction is filling the role of the light waves travelling from the lamp, from behind the thief. In the first map, the lamp is on the wall on the western end. Its light would only travel east, well mostly east with some to the n east and some to the s east. So in order to mimic the lights travel path, the sound would only move from west to east. The purpose of the zones is to move the sounds origin up the yard, west to east, as the thief proceeds. That way a guard behind the thief would not hear the noise, which would be analogous to a guard behind the thief not being in a line of sight to see the backlit thief.

 

In the physical simulation, that would only happen for the first wavefront, but after that an echo-ey room would just reflec that all around into a diffuse reverb field in a few millisecons, which would be psychoacoustically indistinguishable from a sound that had spread in all directions. So it's not really realistic.

 

Is it possible to make the sound only travel once? In other words, the noise is emitted, it travels one path across the yard, and then quits, no echoing, no bouncing?

 

If there's a compelling gameplay reason I could maybe hack it in to the soundprop system by having AI and portals in the first room of propagation (i.e., the room that the sound occurs in) check their angle to the source and compare it with some arc in which the sound is supposedly spreading. That would give the amplitude in the first room some angular distribution, then portals hit by that angular distribution would just continue to propagate normally, but with different amplitudes than if the sound had spread spherically.

 

 

Hmmm , to my thinking the AIs should not have to check their angles, they would merely be alarmed if they happened to be in the pathway of the soundwave. But maybe I dont understand what you mean by checking angles. If the Thief is in one of the zones, the sound would be emitted, moving in a quarter of a circle sized wavefront in front of him, but not behind or to the sides, again this mimics the travel path of the light. AIs that are within the target zone will receive the signal and be triggered by it, those that are outside of it will hear nothing and therefore not react.

Link to comment
Share on other sites

I guess I was talking in terms of sound only. You're talking about utilizing the existing soundprop to do fake light stuff, and I think I understand why it happens in your silhouetting simulation, but what I was saying is that that spreading only in one direction functionality is not in the current sound propagation system. If there's no reason to put it in based on sound propagation requirements (what the system is designed for), I probably won't put it in.

 

If we were to use your system, it would make more sense to just do those calculations in the silhouetting system, i.e., on the "requires silhouetting" entity itself, rather than add something to the soundprop system just so that it could be used to fake a light system.

 

I'm still skeptical of that solution though, because first of all it would require mappers to place a brush at every single bright surface to work consistently, and those kinds of solutions are usually too cumbersome in practice. It also wouldn't be able to take dynamic lighting into account. You might be able to link it to a light so that the surface stops being bright when that light goes out, but there's no way you'll be able to account for people placing objects to block lights or animated texture lights on the wall.

Link to comment
Share on other sites

It seems to me the best way to do sillhouettes justice is, as was previously mentioned, by rendering the vision of the AI and doing image analysis to compare the difference between an image with the player rendered, and an image without the player rendered. This image need only be say 64x64 pixels 8 bit, but it seems the problem with this is that passing even such a small amount of data back over the AGP/PCIx16 bus is not practical, due to limitations on this bus. Correct so far?

 

So, what I want to know is: how much data can be passed back to the CPU from the GPU, and at what rate, and how much will this affect performance, and would it be playable on an extreme high-end machine.

 

Could you do this image differential analysis in software without using too many CPU cycles?

 

If the GPU did the image analysis (and my understanding is that GPUs are now so programable you can run all kinds of code on them - some people have found a way to use graphics cards as DSPs for audio processing), is it practical to simply return a simple yes/no answer to the CPU (yes images with player is diffferent to image without player = player visible?

 

If the GPU can work out whether the AI have seen the player or not, it would take a load off the CPU, and then the question becomes one of whether it is too much of a burden for the GPU.

 

 

This option, if it could somehow be made to give acceptable performance would be the most consistent and easy to work with option for mappers, as it would be an inherent property of the engine per se.

I'll gladly go and buy a top of the range pair of SLI 7800 GTX cards if that is what I neeed to have sillhouettes at playable framerates, it would be well worthwhile IMO.

Edited by obscurus
Link to comment
Share on other sites

I guess I was talking in terms of sound only. You're talking about utilizing the existing soundprop to do fake light stuff, and I think I understand why it happens in your silhouetting simulation, but what I was saying is that that spreading only in one direction functionality is not in the current sound propagation system. If there's no reason to put it in based on sound propagation requirements (what the system is designed for), I probably won't put it in.

 

If we were to use your system, it would make more sense to just do those calculations in the silhouetting system, i.e., on the "requires silhouetting" entity itself, rather than add something to the soundprop system just so that it could be used to fake a light system.

 

I'm still skeptical of that solution though, because first of all it would require mappers to place a brush at every single bright surface to work consistently, and those kinds of solutions are usually too cumbersome in practice. It also wouldn't be able to take dynamic lighting into account. You might be able to link it to a light so that the surface stops being bright when that light goes out, but there's no way you'll be able to account for people placing objects to block lights or animated texture lights on the wall.

 

 

I see what you are saying. And yes it would be a pain to place zones everywhere a lighted surface lay in a map. I just thought it might be able to do an end run around the power gobbling you guys were discussing earlier. Thanks for reviewing it though!

Link to comment
Share on other sites

Another question. Can the Thief block sound? What if the light sources emitted a silent sound, only the AIs hear it and when they DONT hear it because the Thief is in between a line of sight with the source and the guard, they react? I realize such a scheme faces power consumption problems amongst a host of others, just curious.

Edited by Maximius
Link to comment
Share on other sites

It seems to me the best way to do sillhouettes justice is, as was previously mentioned, by rendering the vision of the AI and doing image analysis to compare the difference between an image with the player rendered, and an image without the player rendered. This image need only be say 64x64 pixels 8 bit, but it seems the problem with this is that passing even such a small amount of data back over the AGP/PCIx16 bus is not practical, due to limitations on this bus. Correct so far?

 

AFAIK the problem is, that when you transfer something from the card RAM to the system RAM, the whole render queue is excecuted and the GPU is only fast when it gets batched data.

 

The main problem is not the transfer rate.

 

I'm curious wether transferig a 1x1 textur 2-5 times a second (I don't know how many enemies there are) won't slow the system down to much. Someone has to do some tests ;) Unfortunately I haven't yet programmed a shader. It's pure theory for me ;)

Link to comment
Share on other sites

I got T3 re-installed last night and all the tweakers/Min. installed. Started playing Lord Raven's Mansion and damned if I didnt instantly notice all the places where backlighting dangers existed. There are shitloads of them, to put it mildly. I almost wish I hadnt got involved in this discussion because now I cant get it out of my game-head.

Link to comment
Share on other sites

Where do they mainly occur?

I just suggested the door stuff 'cos of a) people look through doors more than in corners and B) because that's where I reckon the majority of backlighting problems happen inside.

 

Outside there will be problems where the thief blocks a distant light from an AI, however inside in small corridors and rooms it usually works that the room is either lit on or off. And if you stand in a doorway...

____________________

| D

L T AI

_________|___D______

 

L is lit room. Thief T is in the doorway. D is dark room. AI is an AI looking at the door. The thief is blocking the light.

Also: openable windows.

Edited by bob_arctor
Link to comment
Share on other sites

Where do they mainly occur?

 

 

Everywhere. Anywhere there is a lightsource and an AI pretty much. It had bothered me in the past but suddenly its everywhere. And if its not a lightsource, its one of those stained glass window jobs that are everywhere. At least one suggestion I can think of is for mappers not to put stained glass or anything similar at Thief height, keep such things at least above the Thiefs head.

 

I think that mappers could make a lot of difference too by taking care where and when they place AIs and lightsources. Obviously this is not the complete answer, but the creator of Lord Ravens had one scenario that could have been avoided and it was an obvious backlighting problem. A guard is seated at a table, and Garrett has to sneak between him and a lit candle. It was a textbook example of backlighting and it really did blow the immersion. I almost expected him to react anyway, but of course he didnt and it was a little stale as a result.

Edited by Maximius
Link to comment
Share on other sites

I said if we inclde silhouetting there should be an indicator for your silhouette, just like the lightgem for how much local light your in, but everyone lses disagreed and it would be cheating, everbn though ti 10 times harder to keep track of your silhouette as it is to keep track of how much light you're standing in.

Civillisation will not attain perfection until the last stone, from the last church, falls on the last priest.

- Emil Zola

 

character models site

Link to comment
Share on other sites

Everywhere.

 

And that's the problem. Implement silhouetting and suddenly the whole stealth advantage goes out of the window.

 

If you want it that realistic, it would be easier just to scrap the stealth code and let any AI see you if it is looking in your direction, like vanilla D3. In real life this is more or less what would happen.

Link to comment
Share on other sites

And that's the problem. Implement silhouetting and suddenly the whole stealth advantage goes out of the window.

 

If you want it that realistic, it would be easier just to scrap the stealth code and let any AI see you if it is looking in your direction, like vanilla D3. In real life this is more or less what would happen.

 

 

I disagree. There is a stealth advantage still in sticking to shadows where you are more or less indistinguishable from the background. In very low light conditions, only the rods in your eyes function, and they are more responsive to movement than still images, so if you move slowly, you have much less chance of being detected. You also have more rods in your peripheral vison, so you are more likely to notice movemnet out of the corner of your eye than you are if you are directly looking at someone in a dark area.

 

This effect is even more pronounced if the person looking into a dark area is themselves standing in light - it is for the same reason you can't see stars during daylight - the sun drowns out all weaker light sources.

 

i don't know how hard it would be to have the AI's vision succeptable to light bloom effects and adjusting from bright to dark, but it would sure make the AI more realistic...

 

Conceptually for me, the ideal solution is to render an image of what the AI sees twice, once with the player and once without, and compare the two for luminance difference. A big luminance difference means you have been seen. You could tweak the sensitivity, ie how big of a difference between background and player triggers the AI to detect you, so if you found a realistic setting made the game too hard, you could tone it down a bit.

 

You could actually take this to another level using colour images - then you can get into the whole area of camouflage - even in full daylight you could be hard to see if you closely match your surroundings.

 

The only problem with this approach as I see it is that might not be achievable performance wise on current hardware, and if you have a lot of AI, it will get very choppy.

 

But I see this as the way it might be done in the future when hardware is a bit more advanced - having the AI see youas you see them, rather than in an abstract way.

Link to comment
Share on other sites

By current hardware, do you mean top of the line as fast as you can get consumer hardware, or do you mean mid range, what most users will have hardware?

 

Does the Doom 3 engine make use of SMP? Could you run the AI image analysis in a separate thread on another CPU core (rather than on the GPU)? Not much seems to make use of dual core CPUs at the moment, this looks like a perfect example of another core coming in handy, provided the game engine supports it (no idea if the second (third/fourth if you are lucky enough to have a dual CPU mobo with twin dual core CPUS)? core would be able to do it fast enough though, but if you dedicate the core purely to AI vision, maybe it can).

Link to comment
Share on other sites

I don't think that another CPU woul dhelp you here much. It might be better with a second GFX card and a second CPU, so that one can do the renderings needed for the analzying while the other does the regular game mechanics. The actual analysis is pretty fast so that would be no problem, only getting the image is the problem.

Gerhard

Link to comment
Share on other sites

Is a dual core CPU help with games at any rate?

Too late to save us but try to understand

The seas were empty -- there was hunger in the land

We let the madmen write the golden rules

We were just Children of the Moon

We're lost in the middle of a hopeless world

Children, Children of the Moon watch the world go by

Children, Children of the Moon are hiding from the Sun and the Sky

 

© The Alan Parsons Project - Children of the Moon

Link to comment
Share on other sites

Our current lightgem is likely going to be more accurate than the existing Thief games, I don't think we need to spend so much time worrying about silhouetting. By the time we get all of the major systems in place, I'm pretty sure it's going to take a damn good system just to run that. :) I know I'll be upgrading sometime in the new year as I expect that once the AI really start taking off, we'll see our systems challenged.

 

Thankfully we're working with an engine that is already fairly well optimized. If we were trying to do this stuff in the T3 engine, it would be chugga chugga land.

Link to comment
Share on other sites

Actually a lot of the AI stuff we can afford to branch off into a low-priority thread, because its believable for humans to take a second or two to think about how they're going to do something before they do it (search a room for example), so it's acceptable if it takes these AI thinking threads a few seconds to run to completion.

 

There's also tricks like doing only rough pathfinding when you're far away from your goal, and then doing more detailed pathfinding the closer you get. So I would say that if we're careful, we can write the AI without a big performance hit.

Link to comment
Share on other sites

I don't think that another CPU woul dhelp you here much. It might be better with a second GFX card and a second CPU, so that one can do the renderings needed for the analzying while the other does the regular game mechanics. The actual analysis is pretty fast so that would be no problem, only getting the image is the problem.

 

 

So without a fundamental change in the way the aGP/PCIx16 bus works, it is not likely to work? Is there any scope for optimisation? Would an additional CPU not be fast enough, or is it just that you couldn't get the game engine to run it as a separate thread?

 

Some googling indicated that D3 does indeed support SMP, but I don't know to what extent you have control over it - whether you could assign particular threads to particular things, like AI vision processing.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Ansome

      Finally got my PC back from the shop after my SSD got corrupted a week ago and damaged my motherboard. Scary stuff, but thank goodness it happened right after two months of FM development instead of wiping all my work before I could release it. New SSD, repaired Motherboard and BIOS, and we're ready to start working on my second FM with some added version control in the cloud just to be safe!
      · 0 replies
    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
×
×
  • Create New...