A question about DSPs (plugin and core) when combined with the geometry engine

FMOD Engine
1

Hi all,

I was looking at the FMOD docs, but I couldn’t find anything on this.

Say I generate a geometric mesh using MC33[1] or marching cubes. I have a couple questions:

  1. Is it safe to just pass in the vertices directly into FMOD? Is there some way of determining if a polygon should be double-or single-sided, or should I just usually do double-sited unless I need to do something special?
  2. How does the geometry engine work when combined wit hspatializer DSPs or other plug-ins which take 3D attributes and other data parameters? Does the geometry occlusion occur before being handled by DSPs/effects, or is that something the DSP would need to do?

[1]: Vega, D., Abache, J., Coll, D., A Fast and Memory-Saving Marching Cubes 33 Implementation with the correct interior test, Journal of Computer Graphics Techniques (JCGT), vol. 8, no. 3, 1–18, 2019. http://jcgt.org/published/0008/03/01/

2

Hi,

Once you’ve created the geometry (FMOD Engine | Core API Reference - Geometry) it will be passed to FMOD using FMOD Engine | Core API Reference - System::createGeometry(). Passing the same objects to the geometry system and your renderer is the suggested workflow.

  • Double sided is fine
  • Any face that you would expect to apply occlusion should be passed to the system
  • The geometry system will apply occlusion to the signal which is then passed onto DPS to process.
  • So any DSP will be working with an occluded signal

Hope this helps.

3

Isn’t this backward? I create the geometry (with System::createGeometry) and then fill it with polygons?

And to confirm: I do pass the exact vertices that I’d get from algorithms like MC33, without modification or anything like that, to Geometry::addPolygon?

The rest of your post was very helpful – thank you!

4

Here is an example of the mesh struct used:

struct Mesh
{
	int numVertices;
	FMOD_VECTOR *vertices;
	float (*texcoords)[2];
	int numPolygons;
	Polygon* polygons;
	int numIndices;
	int *indices;
	FMOD::Geometry *geometry;
};

which you will then pass the polygons and vertexes to

mesh.geometry->setPolygonVertex(poly, i, &vertex);

Then passed to the FMOD system:

fmodSystem->createGeometry(mesh.numPolygons, mesh.numIndices, &mesh.geometry);

Hope this helps

5

It… Kind of does.It sort of does, I just need to figure out the best way to transform the grid into a mesh (I thought I had it nailed down but… Apparently I didn’t :-().

6

Sorry to bump this topic, but I’m getting confused again. (It might be helpful to maybe expand the docs with a lot more info on how geometries work to get rid of this confusion in future, perhaps.)

When looking at third-party spatializers, they all have occlusion and similar parameters. Ones like SteamAudio do their own geometric occlusion. In my confusion I reached out to atmoky (since I’m very interested in getting the most out of their plug-in) to try to understand things better and I got this response:

If I want to, for example, simulate geometric/acoustic occlusion, do I need to (manually) feed those values to the atmoky Spatializer plug-in’s Occlusion parameter (parameter 12)?

FMOD does not currently offer a builtin way to pass geometry information to a plugin, apart from listener and source coordinates. For this reason, the plugin can only perform the audio processing, any geometric occlusion/ray tracing calculations have to be done on the game engine side and mapped down to a float value. We do have some scripts in our trueSpatial FMOD Unity integration that we consider blueprints/starters on how to perform these calculations, but as there are a lot of performance/game specific considerations, we can not offer an end-all solution for this. If you need a place to start though, the Occlusion Probe Group system we implemented in the trueSpatial FMOD Unity integration would probably be a good place to start.

So I’m just confused on which is accurate. If occlusion is done on the audio signal before the DSP receives it, then are occlusion parameters only for custom ray-tracing or for adding extra occlusion?

Again, sorry for bumping this topic, I really hope I can at least master this somewhat soon-ish! And thank you for all the help!

7

Hi,

Thank you for the information.

Apologies, I am slightly confused on your question. What are the parameters you are referencing here? Where are you getting confused?

8

Hi there,

Apologies. I wrote a plug-in introspection tool that dumps all of the parameters for DSP-based plug-ins. For things such as Atmoky TrueSpatial, these plug-ins have their own occlusion parameters. For example, in Atmoky TrueSpatial, my tool outputs, in the parameter list:

12:
  Name: occlusion
  Label: 
  Description: 
  Type: float
  Range: [0, 1], Default: 0
  Mapping: auto

So hence my confusion.

9

Thanks for the information.

In regards to our Unreal Integration. The occlusion parameter is used to drive occlusion on your events: Unreal Integration | Settings - Occlusion Parameter. However, this is just a value driven by a raycast to the player, the value itself is not applying occlusion.

So I believe each implementation would have their own way of using this parameter and what it means specifically for them. In our UE integration that means driving a parameter which you apply in studio and for Atmoky I am not sure how they are using it.

Let me know if I have misunderstood.