0
0

Currently it takes an incredibly long time to rebuild a project even if very little has changed. We use the command line to build FMOD projects automatically as part of our regular build process.

Would it be possible to add some sort of ‘incremental’ flag to the command line and have FMOD check whether anything relevant has changed before rebuilding an FSB?

For instance, the FSB file or the FEV file could store the wave file timestamps and file sizes, along with the settings used to create the wave bank. Then if we only change an event defintion the build process could verify that nothing in the wave banks has changed and not rebuild them. Or, if we only added one wave file to the project it could rebuild only the FEV file and the affected FSB.

This would be a huge improvement to our asset pipeline. The long build times are a current source of much frustration for our sound designers.

  • You must to post comments
0
0

We already have FSB caching, what version of fmod designer are you using? It says in the revision how compressing xma banks has gone from 20 seconds down to 1 second or something like that.

You also have the option of un-ticking .fsb files to be build in the build dialog if you know they havent changed.

  • You must to post comments
0
0

We can’t use the checkboxes because we do builds from the command line, either via an automated process or interactively by executing a console command from our game editor.

The caching does make a difference but the builds are still very slow. Currently each of our platforms takes about 50 seconds to build the project – even if nothing has changed. The number of sound files will be increasing as the project continues and towards the end I could see the total build time being upwards of 15 minutes. This is not acceptable if only our sound designers need to tweak and test one event.

Even with the cache our larger wave banks, such as those that contain streaming music files, can still take up to 10 seconds each. The file is recreated each time even if the contents have not changed and simply writing all that data takes a while. If FMOD could add some additional checks to not rebuild specific wave banks if their contents have not changed that would help considerably.

  • You must to post comments
0
0

I’ll look into what more we can do to speed things up. For now, if you know in your editor that banks don’t need to be rebuilt then specify "-s 2" on the command line to stop fmod_designercl from building any banks.

Cheers,

  • You must to post comments
0
0

Andrew,

Thanks for the reply. I would like to point out that this is a major issue for our sound designers. Our previous sound engine could deploy changed files almost immediately if only a few .wavs had changed, and this wait is quite a hardship for them.

Here is my suggestion on how building FSBs should work. We could add two FSB building options to the command line and GUI.

[b:2ut7bxzt]Enable/disable FSB caches[/b:2ut7bxzt][list:2ut7bxzt]Honestly, caching seems like a waste of disk space and still leaves performance lacking. FMOD always recreates .fsb files. Even reading from a cache this still can take a long time when several hundred MB of data is unnecessarily written to disk. The compressed sample data is already in the .fsb, correct? If we need a cache why not just use any existing .fsb files instead of duplicating the data in another file?[/list:u:2ut7bxzt][b:2ut7bxzt]Enable/disable an incremental process that works as follows. Note that this assumes the existence of previously created .fsb files.[/b:2ut7bxzt][list:2ut7bxzt]The .fev file can be rebuilt every time, that doesn’t take long at all.
Each .fsb file could be processed as follows.[list:2ut7bxzt]Keep some sort of counter or GUID that can be used to determine if the wave bank settings are in sync with the .fev file. When these settings change we rebuild the entire .fsb file.
Keep a list of individual sample files with their timestamps and file sizes. If none of the data files have changed don’t recreate the .fsb at all. If files have changed, recreate the file, rebuilding only that data which has changed and reusing any data already in the .fsb file.[/list:u:2ut7bxzt][/list:u:2ut7bxzt]

  • You must to post comments
0
0

"Keep some sort of counter or GUID that can be used to determine if the wave bank settings are in sync with the .fev file. When these settings change we rebuild the entire .fsb file.
Keep a list of individual sample files with their timestamps and file sizes. If none of the data files have changed don’t recreate the .fsb at all. If files have changed, recreate the file, rebuilding only that data which has changed and reusing any data already in the .fsb file."

DITTO!!!…Foir instance, we have all of our dialog in one sound bank. Every time we need to make a small change, the whole thing has to recompile. That takes a very long time when we have 13 languages with just one wav/parameter to correct in each language. I set my programmer off every time I want to make a small change. It has become a big problem for me as a sound designer. Sometimes, I have to decide wether a change is worth the recompile time. That reall limits me at time.

It would be great if only the wav(s) that were changed would get recompressed and if none of the wave bank is changed then only the parameters are recompiled.

  • You must to post comments
0
0

[quote="misterite":2ft1oha4]
It would be great if only the wav(s) that were changed would get recompressed and if none of the wave bank is changed then only the parameters are recompiled.[/quote:2ft1oha4]

Have you considered breaking your sounds up into more banks? That would allow you to selectively update only the bank that has changed, and the more banks you have, the shorter it would take to update one since the size would be smaller.

  • You must to post comments
Showing 6 results
Your Answer

Please first to submit.