버전

menu_open
Wwise SDK 2023.1.3
플러그인 라이브러리 형식 저작하기

This page describes the plug-in format as well as the parts that compose a Wwise Authoring plug-in.

Library Plug-in Container

A Wwise plug-in dynamic library is a library that exports a plug-in container, listing all plug-ins provided by the library. This container is added to your plug-in library using a set of macros, as shown below:

// Library "MyPlugin.dll"
// MyPluginLib.h
// MyPluginLib.cpp

These macros take a container name as argument that must match your library name without prefix or extension. Each plug-in can then be added using the macro AK_ADD_PLUGIN_CLASS_TO_CONTAINER. This is all done for you when creating a plug-in using the wp.py development tool.

A plug-in created using the command wp.py new will have a sound engine part that can be built as a static library and will be automatically linked into the Wwise Authoring plug-in dynamic library. This same sound engine static library can be reused for linking in your game.

For details on the sound engine plug-in implementation, refer to 오디오 플러그인의 사운드 엔진 부분 작성하기.

Authoring Plug-in Structure

The Wwise Authoring plug-in comes in two parts: a mandatory backend part, implementing the logic behind how the properties of the plug-in are written to SoundBanks and manages any custom data. A frontend part is optional and is created as a separate class. The latter part is responsible for implementing custom graphical user interface. Both parts are added to the plug-in container independently with the AK_ADD_PLUGIN_CLASS_TO_CONTAINER macro.

Details on how to implement those two parts are described in more details in the following sections:

See also Model of an Authoring Plug-in to learn how to work with the plug-in properties.

Request Components and Services

Components providing a service such as your plug-in model can be requested using "Request" interfaces, e.g., AK::Wwise::Plugin::RequestPropertySet (refer to Property Set). These services are provided to the plug-in instance by the Wwise Authoring application at instantiation time.

Some interfaces add pure virtual methods that must be implemented and that will be called by Wwise. For example, deriving from AK::Wwise::Plugin::Source requires to implement the method AK::Wwise::Plugin::Source::GetSourceDuration, which tells the Wwise Authoring the minimum and maximum duration that can be expected from the source.

Components to use as services in your plug-in are all prefixed by "Request". When these services deal with objects that are owned by your plug-in, they provide an instance added as a member variable in your plug-in for use with the service methods (e.g., AK::Wwise::Plugin::RequestPropertySet is used with the m_propertySet object). Here is the list of components that can be requested:

참고: Some of those services add notification handler methods that can be optionally overridden.

Interfaces intended to be implemented are not prefixed. Here is a list of interfaces that can be added:

Troubleshooting

If you run into any problems, Help is available in the Wwise 음원 플러그인 및 효과 플러그인 문제 해결 안내.

#define AK_EXPORT_PLUGIN_CONTAINER(ContainerName)
(C++) Exports the plug-in container for a shared library.
#define AK_DEFINE_PLUGIN_CONTAINER(ContainerName)
(C++) Defines the unique plug-in container.
#define AK_DECLARE_PLUGIN_CONTAINER(ContainerName)
(C++) Declares the plug-in container.

이 페이지가 도움이 되었나요?

지원이 필요하신가요?

질문이 있으신가요? 문제를 겪고 계신가요? 더 많은 정보가 필요하신가요? 저희에게 문의해주시면 도와드리겠습니다!

지원 페이지를 방문해 주세요

작업하는 프로젝트에 대해 알려주세요. 언제든지 도와드릴 준비가 되어 있습니다.

프로젝트를 등록하세요. 아무런 조건이나 의무 사항 없이 빠른 시작을 도와드리겠습니다.

Wwise를 시작해 보세요