Environmental Audio Extensions (EAX) in TDM

[Tels]

Had problems getting the pk4 to work. It wouldn't appear in the list of missions to install, instead I got patently dangerous twice. Huh?

 

Anyway, after installing output, then moving it simply over outpost.pk4 I could try it out. Only to discover that when you try to enable EAX 4.0 D3 sayz:

 

"EAX is not available for your platform". Damn you, Creative! How much more must you destroy? Grrrr...

[SiyahParsomen]

watched the vid a moment ago and I'm stunned! Great work!

[SneaksieDave]

Note that it's not an install, just a demo PK4 to drop in the darkmod folder.

 

Still haven't found the problem, after a complete hard shutdown overnight and not yet hooking up any of my devices or VMs. I don't know what's wrong, but I'm still on it. The video demonstrates this was not a problem before. Hope my soundcard isn't the problem, but I strongly doubt it. EAX still works, it's just not resetting the EAX settings after the tunnel or cavernous room. As soon as I go to the outdoor area, all is fine again. Hmm...

[Tels]

Note that it's not an install, just a demo PK4 to drop in the darkmod folder.

 

Still haven't found the problem, after a complete hard shutdown overnight and not yet hooking up any of my devices or VMs. I don't know what's wrong, but I'm still on it. The video demonstrates this was not a problem before. Hope my soundcard isn't the problem, but I strongly doubt it. EAX still works, it's just not resetting the EAX settings after the tunnel or cavernous room. As soon as I go to the outdoor area, all is fine again. Hmm...

 

Hope you figure it out! And document it all on the wiki, esp. the presets are quite importannt, I don't think we need more than say 20 different one to cover 95% of all locations and mappers need not to redo them over and over again. Could we somehow ship them with TDM? Or could/should DR create them?

 

Btw, your video is great! It really really gives me back the tingling spine I had when playing Thief with EAX first.. wow! It is a real shame it doesn't work on Linux. Wish we had the source, so we could rip EAX out and replace it with something crossplatform (even if it isn't that powerful).

[rich_is_bored]

I just recently purchased an ASUS Xonar DX (not a fan of Creative Labs) under the impression that it supported EAX 5.0 via software emulation in the driver and was looking forward to trying this out. Unfortunately it's EAX support is spotty.

 

It seems to work so long as the EAX version supported is 1.0, 2.0 or 5.0. Unfortunately Doom 3 uses 4.0. It also might have something to do with OpenAL but I'm still trying to figure it out. It's a shame the game doesn't fall back to supported extensions the way a video card would.

 

Otherwise I'm happy with the card. Sound quality is much improved over the onboard sound I was using.

 

OpenAL does have an EFX extension that could be used instead of EAX. Better yet it's not Creative specific so it should work for everyone.

[SneaksieDave]

I've managed to clear the problem on my system (described above -- EAX settings not being reset between zones) by removing all copies of the map and the EFX files, then re-downloading my own PK4 from the link. My guess based on that is that Doom3 does not like having multiple EFX files with duplicate definitions in the /efxs folder. For example, if you have an area named "hanger13" you shouldn't have any other definition with the same name in any other EFX file, regardless of if that different file is named for and used by a different map. I would have thought Doom3 would only load what's needed per map but I guess it reads them all in?

 

Anyway, this is speculation, but it's probably a good idea to give your EFX entries unique names. One idea would be to preface your definitions by author and/or mission identifier, like "fid_heart_grandhall" or "biker_bau_alleyway". Giving your areas generic names like "grandhall" or "bathroom" may invite trouble.

[demagogue]

Sounds a little like the general paradigm, also with sound_shaders and readables... You can put them in any file with the right extension and the engine will find it and apply it by name. You could technically have every readable in its own .xdata file and every sound in its own sound_shader file and the engine doesn't care; it looks into all of them and grabs anything it can. Sounds like a similar situation here.

 

Edit: BTW another thing to look into. I noticed in reading the documentation (IIRC) that you can set EAX settings individually to a visLeaf by something like its visLeaf-number, so you could have a location name that sets an EAX for the whole location, but then individually derogate for one leaf inside the location to have its own EAX (like derogating closets and bathrooms in a big mansion), surrounded by the location EAX. It can also be done by digging it out as a new named location, of course, but just a bit simpler. The thing is, we didn't know how to find the leaf-number for any given leaf. Something to look into.

 

Edit2: PS, I did have a thread on EAX stuff, but I can't find it on a search just now ("EAX" isn't a proper search term!). Not even sure what sub-forum it was in. I'll try to keep looking for it.

[New Horizon]

Anyway, this is speculation, but it's probably a good idea to give your EFX entries unique names. One idea would be to preface your definitions by author and/or mission identifier, like "fid_heart_grandhall" or "biker_bau_alleyway". Giving your areas generic names like "grandhall" or "bathroom" may invite trouble.

 

Could we include a bunch of preset efx files that would suit most areas? Provide small/medium/large hallways...etc...and the mapper can assign what is available in the mod?

[SneaksieDave]

I noticed in reading the documentation (IIRC) that you can set EAX settings individually to a visLeaf by something like its visLeaf-number, so you could have a location name that sets an EAX for the whole location

Yes, it looks like that from the method id used; they have 'reverb "31"' or whatever all over the place, presumably for zone 31 in a map (I guess... hard to believe these maps all have such limited zone counts though). Though if they have more than one "31", which they do, then why did I run into the problem with multiple zone definitions? Unless, when it's a numbered zone, it uses only that entry in the file and not any others.

 

Could we include a bunch of preset efx files that would suit most areas? Provide small/medium/large hallways...etc...and the mapper can assign what is available in the mod?

Perhaps if the numbered method works, but we don't know a way to get the zone numbers currently. If only the named method works, they'd have to be unique names or they'd possibly hit the problem I did. That said, we can certainly do the following:

 

Establish a bunch of room reverb templates, and then mappers copy the values they need into their EFX files under the desired zone names.

 

E.g.,

TDM templates:

 

reverb "big metal room"

settings ...

settings ...

 

Mapper then copies these values into:

 

mymap.efx:

 

reverb "joe_mymap_big_metal_room"

settings ...

settings ...

 

Then, in the map, Joe identifies the zone as "joe_mymap_big_metal_room". He doesn't actually use the TDM template, but copies the values into his own definition.

[demagogue]

Perhaps if the numbered method works, but we don't know a way to get the zone numbers currently. If only the named method works, they'd have to be unique names or they'd possibly hit the problem I did.

 

Just a quick clarification, and maybe you meant this, but just remember (as I understood it) that the number method only applies to a single visLeaf, whereas the name method applies to an entire "location" zone which can cover many visLeafs and is defined by a info_location marker (an in-game entity).

 

But there does seem to be more to the number system, as that "31" example suggests, which I don't really understand myself since I haven't been able to find where a visLeaf number is stored.

 

My gut impression from that example is that a visLeaf number is set just for the individual .map file, i.e., during the dmap process (it would have to -- the "map" couldn't even know a visLeaf is sealed and valid until you dmap), whereas of course a location_marker is an in-game entity that, like any entity like speakers, grabs any (global) data that fits the name. If this is the right way to think about it, then you'd expect the visLeaf number is going to be somewhere in the .map file where the visLeaf itself is defined, and of course one .map file can't know what's in another .map file (they dmap separately), so that explains why you can have 2 of the same visLeaf numbers in two different .maps with different EAX data, but not 2 of the same location names with EAX data.

 

Do you understand? I was thinking it out as I typed, so it might not be clearly worded. Well, anyway, I'm going to look in a .map file to see anything like a visLeaf number to see if that's on the right track.

[ungoliant]

yeah i seem to remember reading about this somewhere. When ID made D3, they had tons of visleafs everywhere, and they would all be either assigned to the same location, or else each location was named the same(one or the other). In the EFX file, because all the visleafs shared the same name, (or were in the same location), they'd use the number instead. Where these numbers come from....? dont know

 

edit: as far as TDM goes, i don't think we need this numbering system anyway. Separate all the visleafs to their own location and name them differently. After all, there isn't going to be a PDA or HUD feature that tells you that you are in: "Bathroom", or "Front Yard" like in D3 all of the visleafs needed to say "mars underground" or "alpha labs" or whatever and all be matching.

Edited May 20, 2010 by ungoliant

[demagogue]

It's still worth figuring out just to understand what's going on.

 

Edit: tl;dr update -- this is wrong, and the post below this one is right.

 

Ok, just looked at a simple .map file with a working visLeaf. NO visLeaf information, only the visPortals are defined. So since there's no visLeaf info anywhere at all, that suggests that it's not the dmap that defines the visLeafs, but it has to be the "map" process that loads/initializes the .map into the engine, it builds the leafs then. If that's true, then you'd expect that it's going to define each visLeaf sequentially as it goes through the queue of definitions in the .map file.

 

In other words, if you actually open up the .map file, you see all the visPortal brushes being defined in the order you create them (probably also the order in the "j" menu, right?). My new hypothesis is that whenever all the brushes enclosing a leaf get sealed, the "map" process defines a new leaf for that area and it gets the next sequential number. So, e.g., visLeaf #1 is going to be the first leaf that is sealed by the brushes listed by the .map queue, #2 is going to be the next leaf sealed, etc (i.e., you're not going to find the number itself; you have to work it out in the same order that "map" does). Well, it's possible that an internal variable is set that you can script to print on the console, but short of knowing what that variable is (maybe we can find out), the next best thing is to get the number in the same way the "map" process probably does.

 

Fortunately, many mappers probably seal a visLeaf with all the relevant visPortals together, or at any rate they have a good idea of the last brush they used to seal a leaf, so the first group of visPortals (or that key brush) will probably define visLeaf #1, the second group/key brush defines leaf #2, etc. (What if one brush seals 2 leafs at the same time? It'd pick one over the other, but anyway even then you know the two numbers and just have to confirm which is which by a quick-test.) One problem (I'm imagining) is of course that this doesn't have to be the case. You can imagine someone setting all the visPortals for an area, but leaving a crack that doesn't create a leaf, then like 500 steps later they seal that crack and *now* the leaf is made, so it'd have a high number even though the VPs around it were all created earlier (so you'd expect a smaller number if you weren't careful), though again mappers usually know the brush that finally seals a leaf even if it comes much later.

 

Anyway, this is my new hypothesis. If this is right, then you could test it by creating a small test map with, say, only two visLeafs, with EAX set to #1 and #2, and confirm that the first leaf sealed (in the order you create the brushes, cf. the "j" menu) gets EAX #1, the second #2, then add a third leaf and test again, etc. This should confirm the theory or not pretty quickly. I can't do it myself since I don't have EAX capability.

 

Edit: Or were the same numbers leafs shared in the *same* .map? I don't have a Doom3 map to look at just now. Then that would bring up my previous idea that the leaf number would have to be in the .map somewhere, like set by hand.

[OrbWeaver]

"visLeafs" almost certainly refer to objects in the compiled .proc file, not the .map file. For example, using "visportalTest.proc" in the maps directory:

 

interAreaPortals { /* numAreas = */ 2 /* numIAP = */ 1

/* interAreaPortal format is: numPoints positiveSideArea negativeSideArea ( point) ... */
/* iap 0 */ 4 1 0 ( -176 -83 104 ) ( -120 -83 104 ) ( -120 -83 0 ) ( -176 -83 0 )
}

 

What this seems to be saying is that there is a single visportal which divides the map into two, with "_area1" being on the positive side of the plane and "_area0" being on the negative side. My guess is that "visleaf" refers to these areas, which are defined previously in the .proc file inside "model { }" blocks.

[demagogue]

Ah, of course. I said .map, but I meant the files compiled during dmap. Good find.

 

Edit: looking at it, it looks like it. Each area in the model { } format defines like, e.g., 30 surfaces, then defines each surface individually by brushes (with opaque textures) and portals. Sounds like just what a visleaf is. So, like you say, maybe the visleaf number is the _area#, which is the "name" of the area. I think we have a winner.

 

model { /* name = */ "_area33" /* numSurfaces = */ 32 /* surface 0 */ { "textures/darkmod/stone/brick/interlocking_angled_grey" /* numVerts = */ 14 /* numIndexes = */ 36 ( 744 808 392 10 9 0 0 1 ) ...

 

Edit2: And an easy way you could find that number for a visleaf in your map is temporarily set a unique texture on the facing surface of any brush making up the leaf, dmap, then search the .proc file for the texture's name, then search *up* for "area" and take the _area# at the head.

[SneaksieDave]

Do you understand?

Actually, I understand very little of this. Even less now.

[demagogue]

Do you think you (Dave) could test our theory by these directions:

 

- First, might be a good idea to turn off all the location stuff with a new version of the testmap and a clean EAX file, so you're only working with visleafs.

- Pick any arbitrary visleaf (portal-enclosed area) in the test map.

- Change the facing texture on any textured brush that serves as a "wall" to the visleaf (i.e., not an internal brush but one that's forming the boundary "skin" of the visleaf) to a unique texture that's only used on that wall and nowhere else on the map.

- Dmap it (from experience, it might be a good idea to delete the .proc file before you dmap to make abs sure a new one is made.)

- Open up the new .proc file in something like notepad.

- Search for the exact name of that unique texture. When it highlights, search *up* for "_area" or "area" to get the area/visleaf number for the area that that texture is used in. When it highlights, take the number, e.g., _area15 as the portal number for that visleaf.

- Go into the EAX file and set the EAX setting for that number on the model of the Doom3 usage.

- Map it, get in game, and see if the EAX setting registered properly for that visleaf area.

 

 

Edit: If it does work, then you might try experimenting with other ideas, e.g., make sure it works for other areas; try setting a multi-leaf location to one EAX setting by name but one visleaf inside it to another setting by number to see if both areas register properly; try setting multiple EAX settings to the same visleaf number and see what happens in that visleaf (does it pick one over the others?), etc...

[ungoliant]

Edit: If it does work, then you might try experimenting with other ideas, e.g., make sure it works for other areas; try setting a multi-leaf location to one EAX setting by name but one visleaf inside it to another setting by number to see if both areas register properly; try setting multiple EAX settings to the same visleaf number and see what happens in that visleaf (does it pick one over the others?), etc...

 

chances are that this idea will work. after all, if you check the original doom3 .efx files, at the end of each, there is a "default" definition, which i assume assigns environment properties to any visleafs that don't have their own explicit environment defined. So if there is one info_location comprised of 5 visleafs, and you explicitly define environments for 3 of them, and then define an environment for the info_location itself with the name "default", it is likely that the 2 visleafs that weren't defined in the EFX file explicitly will adopt the properties of the "default" settings for the entire info_location.

 

If that didn't make sense, then just know that I've drank about 4 pints of beer

[OrbWeaver]

I somewhat doubt that it would be necessary to manually inspect the .proc file for visleaf numbers in order to get EAX zones working correctly. If the .efx files refer to these numbers, presumably they were constructed using some sort of automated editing tool (isn't there an "editSounds" command in Doom 3?).

 

If setting EAX properties for named locations works, then the manual visleaf approach seems like a dead-end to me. Besides, who's to say that the visleaf numbers are even going to be the same between different compilations of the same map?

[demagogue]

I get that. I guess I was just personally interested in understanding how it works, even though I agree it's not the most useful thing.

 

One thing though, locations and leafs aren't exactly the same thing and there are times you might want to differentiate them (e.g., so you can have one location with 10 EAX in it), and using leaf numbers for EAX lets you do that.

 

(As for different compiles using different numbers, I thought about that too. The mapper would have to check the numbers after the last compile, and testing might be hell. It is annoying, I agree.)

 

Anyway, since I'm pretty sure we already figured out all there is to figure out, I'll leave it at that. You probably don't need to bother testing it, Dave. It might be worth putting a very short blurb in the wiki on it, though, like a parenthetical aside just to have it documented for completeness sake.

 

Edit: Ok, I put a side-box in the EAX wiki entry to cover it, with a note that the mapper is better off using the location-name method, directing them to the "location" wiki entry to make it, and this is just for the record. I'm satisfied.

[SneaksieDave]

If setting EAX properties for named locations works, then the manual visleaf approach seems like a dead-end to me. Besides, who's to say that the visleaf numbers are even going to be the same between different compilations of the same map?

That's my thinking as well.

 

I built a few rooms in a chain to test the above steps, and while I could identify the rooms, and it does appear that arbitrary numbered EAX definitions were applied to each room (each was different), as soon as I added more rooms to the chain (at the beginning and the end, in an attempt to mix up any ordering that might exist in the .map file) the EAX effects applied changed. Two big cavernous rooms were adjacent, but after the additions and re-compile, no longer. Might be the deal breaker.

 

Anyway, as the location naming system works, if mappers are careful not to duplicate names (for the problem I ran into) we should be good.

 

 

Edit: Odd, I didn't see that last post. Thanks for the wiki entry; I added a link back to this thread for full info.

[LEGION]

So, is it working now? Are the mappers aware?

 

I just ran the testroom and I´m not sure, but I think the player-footsteps are a little bit affected and it felt ok. Also, isn´t it realistic that sounds, that are more far away are more affected than sounds nearby?

Anyway, the sound effects I heard were wonderful!!

[SneaksieDave]

EAX in TDM maps by the method in the demo map above is fully working from what I have been able to determine.

[Tels]

EAX in TDM maps by the method in the demo map above is fully working from what I have been able to determine.

 

Except on Linux. Course you, creative

[SneaksieDave]

Not at all? Is that the result of driver limitations, or lacking hardware?

[Tels]

Not at all? Is that the result of driver limitations, or lacking hardware?

 

I think drivers. It says "not supported on your platform".

 

http://connect.creativelabs.com/openal/Lists/OpenAL/Flat.aspx?RootFolder=%2Fopenal%2FLists%2FOpenAL%2FEAX%20and%20Linux&FolderCTID=0x0120020001C624363C8DD3449DE26D1760F0364A

 

Reading this it means that EFX could work instead, but I think D3 doesn't support it? These things are hazy to me at best.