Releases: napframework/nap
NAP 0.7.0
Major release that introduces new features, general improvements and the usual set of fixes.
Download
New Features
Advanced Rendering Operations
NAP 0.7+ introduces a new render module: the naprenderadvanced
module. With a set of tools that expand (supplement) the default renderer, including: lights, shadows, cube maps, various new shaders and several rendering-related utilities. The nap::RenderAdvancedService
creates and manages internal resources such as render targets and textures that are bound to materials that use these advanced features.
Lights & Shadows
The naprenderadvanced
module includes a light system that can be used to create consistent lighting setups using: spot, point and directional lights. Every light is derived from a nap::LightComponent
and can cast shadows using shadow maps. On initialization, each light component sets up its own light uniform data and registers itself with the render advanced` service.
Check out the lightsandshadow
demo for a complete demonstration of the light system:
lightsandshadow.mp4
You can utilize the standard nap::BlinnPhongColorShader
to efficiently render a lit object. Alternatively, you can create a custom shader compatible with the lighting system. For instructions on setting this up, refer to the "Custom Lights" section in the documentation. Material settings can be configured in Napkin using the new shader inspection model introduced in version 0.6.5. For the BlinnPhong
shader, these settings include ambient, diffuse, reflection, and specular parameters.
Cube Maps
nap::CubeMapFromFile
takes an equirectangular image as input and turns it into a cube map which can be used to - for example - render a sky box using the nap::SkyBoxShader
or add environmental reflections to objects using the nap::BlinnPhongShader
, which has an environment map and reflection input for this purpose.
Check out the skybox
demo to see how to work with cube maps:
skybox.mp4
Render Layers
Render layers allow you to group render components and set the sequence in which they are rendered. These layers are organized and prioritized in a nap::RenderChain
where a layer's position in the list specifies its rank
: 0 is the frontmost position (rendered first), and the last index is the rearmost. Components without an assigned layer automatically default to the front (index 0).
One useful approach for layers is to render a skybox
or another background-filling object first, regardless of its position in the world. To achieve this, add a layer to the render chain named Background
(rank 0) and assign it to the component responsible for rendering the background. Then, assign all other objects in the scene to the subsequent layer called Scene
(rank 1). This setup ensures that the background is rendered before any other objects in your scene. Note that all objects in a layer are still sorted based on the assigned blend mode.
Render Tags
Render tags can be used to categorize render components. They are not ordered (unlike render layers) and multiple of them can be assigned to a render component. Each tag registers itself in the render service and receives a unique bitmask on initialization, allowing tags to be composited together into render masks
.
One useful example would be to tag specific components as debug, to distinguishing them as a visual aid for debugging purposes and separating them from regular objects in your scene with (for example) the SceneTag
:
auto scene_tag = mResourceManager->findObject("SceneTag");
mRenderService->renderObjects(renderTarget, camera, render_comps, scene_tag);
The above code excludes components tagged as debug because we only include objects with the SceneTag
. Tags can be combined (ORd etc.) to include objects from both sets, for example:
auto debug_tag = mResourceManager->findObject("DebugTag");
auto scene_tag = mResourceManager->findObject("SceneTag");
mRenderService->renderObjects(renderTarget, camera, render_comps, scene_tag | debug_tag);
The above call renders all components with a Debug or Scene tag.
Other Render Features
- 4 new demos:
lightsandshadow
,skybox
,spotlight
andlinemorphing
- The
nap::RenderAdvancedService
auto updates light uniforms for meshes that are rendered with a compatible material - Shadow mapping handled by
nap::RenderAdvancedService
- Many new shaders, available in
naprenderadvanced/data/shaders
andnaprender/data/shaders
nap::RenderSkyBoxComponent
andnap::SkyBoxShader
nap::RenderFrustumComponent
- Shader
#include
system with lots of utilsnaprenderadvanced/data/shaders
nap::DepthRenderTexture2D
&nap::DepthRenderTarget
- separate depth texture / targetnap::CubeDepthRenderTexture
&nap::CubeRenderTexture
nap::SamplerCube
- support for cube samplers- Depth sorting is updated to give higher priority to layers
- Shadow mapping handled by
nap::RenderAdvancedService
- All
nap::GPUBuffers
are now transfer sources and destinations by default (TRANSFER_DST
/TRANSFER_SRC
) - Aesthetic / performance improvements to
computeflocking
demo
Napkin
Shader Inspection & Mapping
Allows the user to create material bindings based on shader declarations. All existing shader input types are supported, including: uniform, sampler, buffer and vertex bindings. Uniform resolving works for every type of nap::BaseMaterial
and nap::MaterialInstanceResource
, in combination with any type of shader. If no shader is linked or the shader can't be compiled the editor reverts to it's default (uniform creation) behaviour.
shader_inspection.mp4
Because of this change Napkin now depends on the naprender
module. The engine is initialized when the project is loaded using nap::RenderService::initShaderCompilation.
The added benefit of this change is that we can start using the render engine for more advanced render operations, in the editor, in the future. I introduced a couple of standardized property names to make sure the editor and engine are always in sync.
Toolbar & Shortcuts
The new toolbar displays items for the most common user actions, such as loading a project, opening a file, saving a file, creating a new resource, and accessing the documentation page. Additionally, new keyboard shortcuts have been added for many actions, including opening a project (ctrl+k) and creating a resource (ctrl+r). Pressing d
in the resource or scene panel now attempts to delete the selected item.
Special disabled
icons have been introduced to better inform users about available options. Actions are now unified between the menu and toolbar using a new (basic) napkin::ActionModel
, which creates and groups common actions. Many actions, including all file and configuration actions, remain disabled until a project is loaded.
Reorder Items
You can rearrange items in a list by choosing move .. up
or move .. down
from the context menu in the resource and inspector panel. The introduction of the new MenuOption
and MenuOptionController
simplifies the process of registering, creating, and managing context menu options, providing a more straightforward approach compared to the complex if/else structure previously employed.
Clear Links
Entity, component and resource pointers can now be cleared, resetting them to NULL
. Attempting to clear a required link triggers a warning. Required but invalid links (pointers) are colored red, optional links yellow:
Resource & Property Tooltips
Added documentation to all serializable and configurable NAP Objects, including: Resources, Entities, Components and Services. The documentation is displayed as a tool-tip (help) in Napkin before creating a new resource (for inspection) and when hovering over an item in the resource, inspector and service panel:
Documentation is completely optional, but when given directly compiled into the object using RTTI:
RTTI_BEGIN_CLASS_NO_DEFAULT_CONSTRUCTOR(nap::ImageFromFile, "2D image that is loaded from disk and uploaded to the GPU. Holds the CPU (bitmap) and GPU (texture) data")
RTTI_CONSTRUCTOR(nap::Core&)
RTTI_PROPERTY("ImagePath", &nap::ImageFromFile::mImagePath, nap::rtti::EPropertyMetaData::Required, "Path to the image on disk")
RTTI_PROPERTY("GenerateLods", &nap::ImageFromFile::mGenerateLods, nap::rtti::EPropertyMetaData::Default, "If lower levels of detail (LODs) are auto-generated for the image")
RTTI_END_CLASS
Napkin automatically detects and displays it as a tooltip when hovering over a resource, service or property.
Object Duplication
Added option to duplicate (deep copy) an object - including regular resources, components and ...
NAP 0.6.3
'Minor' release, with a couple of new features, various improvements and bug fixes. This will be the last official 0.6.X release before bumping main to 0.7.
Download
New Features
- Shader inspection and automatic binding of uniforms, samplers and vertex attributes (napkin) d4b7248
- Toolbar for common actions (napkin) 88ae722
Improvements
- Added dropdown parameter (napparameter) bf20942
- Added portal dropdown item (napportal) bf20942
- Vulkan renderservice available in editor (napkin) d4b7248
- UDP demos now use api callbacks (napudp) 38fc453
- New popup for editing track settings (napsequencegui) 5ce9f71
- New keyboard shortcuts for common actions (napkin) 6d9755e
- Replace default msg box icons with nap icons (napkin) 2249211
Fixes
- Fix MeshShape RTTI construction (naprender) a03e971
- Fix build environment check (build) fcd9b2b
- Fix point values becoming NaN (napsequence) fcd9b2b
- Fix transform update (napscene) ac8fc2f
- Windows module installation fix (build) d0ea5d2
- Fix drawing from old cache (napsequenceeditorgui) 8f42946
- Fix check_build_environment arch check for AMD (build) cee23ce
- Fix potential document reload crash (napkin) 17bce95
- Fix return code when no demo is deployed (build) 66e2b27
- Explicitly delete UDP socket (napudp) 0e1b99a
Special thanks to @lshoek @TimGroeneboom @cklosters @cheywood
NAP 0.6.0
Major release that introduces new features, general improvements and the usual set of fixes.
Download
Warning
This release is not compatible with older NAP projects - version 0.5 and below. A new 0.5 branch has been created for legacy purposes that will continue to receive critical updates and fixes (for the time being). A porting guide will be made available to help you port your existing project to NAP 0.6.
- NAP-0.6.0-Win64-x86_64.zip
- NAP-0.6.0-Linux-x86_64.tar.bz2
- NAP-0.6.0-macOS-x86_64.zip
- NAP-0.6.0-Linux-armhf.tar.bz2
New Features
We have reworked the entire build system to provide a more streamlined project management and build experience. The NAP compiled framework release and source context are now more unified, making it possible to create, share and deploy the same module to both contexts without providing additional (arcane) build instructions. This lowers the amount of friction as it reduces the number of hoops a developer has to jump through trying to integrate a new set of features or third party dependency.
The project management documentation has been updated (rewritten) to reflect these changes.
User Modules
Users can now share their modules with others!
A list of publicly available user modules can be found at modules.nap.tech.
These modules are created, maintained and shared by NAP users, independent of NAP Framework.
Download & Install module
User modules can be installed from a zip or repository.
From zip
Download the module as .zip
archive from (for example) Github and install it into the nap modules
directory:
- Open a terminal
- Change into your NAP framework directory
- Install the module
./tools/install_module.sh ~/Downloads/napdatabase-main.zip
From repository
Clone the repository and set up the module in the nap modules
directory:
- Open a terminal
- Change into your NAP modules directory
- Clone the repository
cd modules
clone https://github.com/naivisoftware/napdatabase.git
- Set it up
./../tools/setup_module.sh napdatabase
Share your module
You can share your module on modules.nap.tech by following this registration procedure.
A typical module has the following content, which will be included when the module is shared:
Content | Directory | Required |
---|---|---|
source code | src | yes |
thirdparty dependencies | thirdparty | no |
demo application | demo | no |
Unified Contexts
The NAP (pre-compiled) package and source context now share - to large extent - the same layout, build instructions and tools. Subsequently: user modules and applications can now be deployed and used in both. Because of this change user modules (can) now include their own demo and third-party dependency, sitting directly in the root of the module directory. This simplifies the packaging, sharing and installation of a module substantially. It also helps developers track and understand dependencies better because everything is now more local to the code that uses it.
CMakeLists.txt
files has been moved into framework-space. That framework-space logic is an evolution of what was previously used for Framework Release and is now located at cmake/nap_app.cmake
and cmake/nap_module.cmake
.
Custom logic belongs in module_extra.cmake
and app_extra.cmake
within the root of the module/app (not under dist
like before). This logic is integrated after the target has been defined. In rare cases it might be desirable to execute extra logic before the target is defined. A new hook for that has been provided via optional files module_extra_pre_target.cmake
and app_extra_pre_target.cmake
.
Basic module structure
A super simple module with no third party library and no added CMake logic will look exactly as it would have before in Framework Release context:
src/...
module.json
Any extra CMake now also appears in the module root:
src/...
module.json
module_extra.cmake
If the module has a demo that will appear under demo
:
demo/<DEMO_NAME>/...
src/...
module.json
With the <DEMO_NAME>
appearing in the DemoApp
element of module.json
eg.:
{
"Type": "nap::ModuleInfo",
"mID": "ModuleInfo",
"RequiredModules": [
"napmath"
],
"WindowsDllSearchPaths": [],
"DemoApp": "tween"
}
Third party libraries live under /thirdparty
in their own directory and are paired with the CMake find module within /thirdparty/cmake_find_modules
, eg:
demo/lineblending/...
src/...
thirdparty/etherdream/...
thirdparty/cmake_find_modules/Findetherdream.cmake
module.json
module_extra.cmake
Each module should also contain a .gitignore
, used to prepare it for sharing etc (and one is provided when the module is created). System modules with third party libraries remain special in that they're provided compiled in Framework Release context. As a result there's more complexity in their build logic. See the module_extra.cmake
for system modules.
Thirdparty deprecated
The thirdparty repository is no longer required because all (pre-compiled) dependencies are included (merged) in this repository. The priorities which determined where those libraries ended up located were:
- Reduce differences between the two build contexts
- Where possible locate the library within the system module using the lib
So in the majority of cases the libraries end up located at system_modules/<USING_MODULE_NAME>/thirdparty/<THIRDPARTY_LIB_NAME>
, eg. system_modules/naprender/thirdparty/SDL2
The CMake find modules for those libraries are located within eg. system_modules/naprender/thirdparty/cmake_find_modules
.
Libraries that aren't specific to a module are located under <NAP_ROOT>/thirdparty
with their CMake find modules in <NAP_ROOT>/cmake/find_modules
.
Module Deprecation
The following modules are no longer part of the core framework:
They have been moved to dedicated reposities and are listed on modules.nap.tech. They will be maintained by others, independent of the core release.
Custom CMake
We've focused on providing a streamlined build environment for people to start making applications and modules, together with trying out some demos. But sometimes that's not enough: you need to add your own build logic. For that purpose we've provided additional easy to integrate hooks that you can use to add custom CMake to your project and include third-party library dependencies.
Module naming consistency
Previously modules were prefixed with mod_
, which was present in the module directory name under Framework Release context but not Source context. As discussed that now changes. All modules are prefixed with nap
but mod_
is removed. Pascal case is no longer enforced in the module and app creator, the user can enter whatever they want, and whatever they enter is used everywhere (eg. class names, directory names, etc).
Build output dir consolidates to BUILD_TYPE-ARCH
Before this was different between contexts, and then in Source context it was also different between multi build type systems (macOS, Windows) and single build type (Linux). Now, as planned, it's just <BUILD_TYPE>-<ARCH>
eg. Linux-x86_64
.
/dist
gone, /build_tools
moved
/dist
became a little irrelevant as the contexts consolidated. /build_tools
roughly moved to /tools/buildsystem
.
/tools/*.(sh|bat)
in Source Context
Hinted at in the previous, but whether you're in Framework Release or Source context all of the tools/
scripts are accessible. Naturally some of these vary a little across context, eg. a ./tools/regenerate_app.sh someapp
is just going to regenerate the whole solution in Source context.
App & Module directory shortcuts
Similarly whether from either context you can use the same module or app directory shortcuts.
For apps:
regenerate
build
package
(Framework Release only)
For modules
regenerate
prepare_to_share
(not for system modules)
.sh
for all Unix scripts
In a concession against convention (Unix scripts shouldn't have extensions, it's bad practice) due to having Unix wrapper scripts visible in Source context on Windows .sh
extensions were added to the Unix scripts. Then for consistency this was applied across contexts. As a result the minor changes were made to switch the scripts to POSIX sh
from bash
(in case somebody goes all odd and explicitly calls the interpreter to run the script). The other option, using .bash
suffixes for a...
NAP 0.5.7
'Minor' release, with various improvements and bug fixes. This will be the last official 0.5.X release before bumping main to 0.6
Improvements
- Simplify property path validation (napkin)
- Cache objects for faster lookup (napkin)
- Option to link in service configuration after generating it (core)
- Make napkin a win32 app - removing the console (napkin)
- add normalmatrix to mvp struct to avoid mat inversion in vert shader (naprender)
- changed AudioServiceConfiguration::Settings to AudioServiceConfiguation::DeviceSettings (napaudio)
- Search for audio device by name specifying input or output (napaudio)
- Safer parameterbool floating point epsilon comparison
- Improve render window restore information
New Features
- Add support for multi-finger touch input & events - separate from mouse input. (napinput)
- Get cursor position in window (naprender)
- Toggle cursor visibility. (naprender)
- Uniforms can be shared between vertex and fragment shader stages (naprender)
- Bind license to unique machine ID (naplicense)
Bugs
- Fix window coordinate caching (naprender)
- Fix spawning of napkin by making it a win32 app (napkin)
- MidiInputComponent-interface-fix (napmidi)
- Fix crash when overriding unsupported instance property type (napkin)
- Disconnect audio stream without driver selection (napaudio)
- Fix shader linking and mapping error logging (naprender)
- Fix component instance getter
- Fix incorrect stringification property path (napkin)
Download
Special thanks to @lshoek @stijnvanbeek @TimGroeneboom @cklosters @cheywood
NAP 0.5.5
'Minor' release with various improvements and bug fixes.
This release addresses one of the most common causes of frustration when working with Napkin: The Inspector view losing focus and being rebuild after editing a property. This was introduced, at the time, as a shortcut to not having to handle and properly implement all the data model changes. Many temporary hacks were introduced to restore state, but none were truly satisfactory.
This release addresses this shortcoming. It ensures that the inspector view and property items keep their state when an edit is made. It only redraws the part that is required. This means that item selection, item collapse / expand state and the scroll position are maintained. It also improves performance because only the items that change are updated / redrawn. Other improvements, fixes and new features include:
Improvements
- Property changes in Napkin are handled locally (napkin)
- Removes the need to rebuild the property model after a change to the data model is detected.
- Improves overall performance and ensures state of the view is kept between edits.
- Added icons for property edit actions (napkin)
- Improved property edit action labels (napkin)
- Better initial layout of properties when a resource is selected (napkin)
- Better visibility of embedded resource in array (napkin)
- Resource ID promoted to item index
- Ability to author ID of embedded resource in array at a specific index (napkin)
- Improved general handling of Instance Properties (napkin)
- Use RTTI to create and update instance properties
- Removed documentation generation from source code (docs)
- Removed all asio includes from udp header files (mod_napudp)
- Construction of
nap::SphereMesh
(mod_naprender) - UDP setup and layout (mod_napudp)
New Features
nap::TorusMesh
(mod_naprender)- Predefined torus mesh with additional normal, uv and color vertex attributes.
- Used in the
copystamp
demo
- Support for vec4 / ivec4 parameter and parameter tracks (mod_napparameter)
- Support for vec4 / ivec4 parameter blenders (mod_napparameter)
- Support for vec4 / ivec4 parameter editors (mod_napparametergui)
- Multicast support (mod_napudp)
Fixes
- Potential memory leak when allocating Instance Properties (napkin)
- Incorrect behaviour when hovering over curve (mod_napsequencegui)
- Wrong initialization of audio file resources when previous errors occurred during initialization (mod_napaudio)
- Ensure windows sdk version is set when asio is included in packaged env (mod_napasio)
- Replaced broken failed preset load popup with log warning message (mod_napparametergui)
- Storage buffer binding update of flock system render material (flocking demo)
- Thread could potentially exit before
mRun
is set to true (mod_napudp) - Remove adapter before calling
onStop
, fixing a potentiol error where adapter could get called while its internal implementation is already stopped or discarded (mod_napudp) - Properly export parameter group (mod_napparameter)
- Synchronization of storage buffers when using multiple
onCompute
calls within a single frame (mod_naprender) - Remove double binding changed callback in numeric binding instance
- Imgui enter key remap fix, thanks to @andras-v
Thirdparty
- Bumped
glslang
to latest master
Download
Special thanks to @lshoek @TimGroeneboom @cheywood @bmod @cklosters @andras-v
NAP 0.5.3
Minor release that fixes a critical bug in Napkin and unifies parameter group behavior.
Improvements
- Converted
nap::ParameterGroup
into a regularnap::Group<Parameter>
Fixes
- Fix access violation in
getParent
ofPropertyPath
when property is nested.
Breaking Changes
The new parameter group is backwards compatible with the old parameter group. The property names (in json) are the same. But because nap::ParameterGroup
is now a regular nap::Group<Parameter>
, the mGroups
and mParameters
members have been renamed to mMembers
and mChildren
. If you directly access these members in your code you must refactor them accordingly.
Download
- NAP-0.5.3-Win64-x86_64.zip
- NAP-0.5.3-Linux-x86_64.tar.bz2
- NAP-0.5.3-macOS-x86_64.zip
- NAP-0.5.3-Linux-armhf.tar.bz2
NAP 0.5.2
Minor release that introduces a couple of new features, improvements and general bug fixes.
Download
- NAP-0.5.2-Win64-x86_64.zip
- NAP-0.5.2-Linux-x86_64.tar.bz2
- NAP-0.5.2-macOS-x86_64.zip
- NAP-0.5.2-Linux-armhf.tar.bz2
New Features
Grouping
Group together resources of a specific type with the nap::Group<T>
. Use Napkin to to create and author groups:
Grouping in NAP
- There is currently 1 catch all group:
ResourceGroup
. This group can have any type ofnap::Resource
as member. - Adding an existing item to a group does not break your app structure
- Groups can be nested inside other groups of the same group type. This allows you to build group hierarchies.
- Define your own group, that holds members of a specific type, using the
DEFINE_GROUP
macro.- Automatically recognized by Napkin as a new group type.
- Groups internally use
nap::ResourcePtr
, ensuring groups work in combination with hot-reloading. - Find an object in a group using
nap::Group<T>::findObject()
andnap::Group<T>::findObject<M>()
Grouping in Napkin
- Allows you to create and edit groups of type
nap::IGroup
(as seen in the example GIF)- Uses RTTR to figure out what type of items the group can hold
- Move items to a different group, if that group supports holding that item
- Move items from group to group (reparent)
- Reparent a group under another group
- Remove an item or group from a group
- Create and add new items to a group
- Delete groups and all children in that group
- Link to groups and child groups from existing resources and components
Sequencer
Resize Track Height:
- start & stop playback using the spacebar
- ability to select segments and save/load them as presets into tracks, presets are saved in sequencer/presets folder
- ability to resize trackheight
- remove vertical zoom
- tan point handlers are now zoom level independent, making them better manageable at greater zoom levels
- reformatted all sequencer related code to make style consistent
- added minimize / extend button above inspector
- replaced all maps containing member function pointers with maps contain std::function<...> and lambdas
- segments can have names
Improvements
Napkin Optimizations
During the process of implementing groups we optimized a lot of procedures in Napkin, smashed numerous bugs, optimized various code paths, removed dynamic_cast & fixed the ordering and display of entities and components. These changes apply to the data model and resource panel.
Misc
- Don't export symbols for Clang & GCC by default, use the NAPAPI to selectively export symbols instead
- Improve zoom controls on orbitcamera
- Added 16 byte aligned fixed point ubo structures ivec4 and uvec4
- Make numeric constants scale with gui scaling factor
- Expose renderwindow title
- Adding seconds, minutes and hours to timer.
- Better display validation
- Fixed cameracontrol required components and improved style
- Added space to ImGui key mapping
- Allow to specify ArtNet packet data size per controller
- Let pybind find python libs and python includes
Fixes
- Pybind memory compile time debug assert
- Caused packaging to fail on Windows (msvc64, latest version of Visual Studio 2019)
- Ensure calendar path consistency using (enforced) separator instead of using comparable file names
- Revert to default DPI if DPI information is not available
- Vulkan swapchain (various)
- Crash & icon fix in sequencecurvetrackview_template.h
Third Party
Updating pybind to pybind11-2.9.2
Deprecation
macOS
Unfortunately, after a lot of internal debate, we decided to deprecate macOS as an official NAP target. This means that from version 0.5.2 we will no longer actively develop or support macOS. CMake will issue the following warning if you build NAP from source on macOS:
CMake Deprecation Warning at CMakeLists.txt:60 (message):
[01:32:26] [Step 2/2] macOS (as a target) is no longer in active development or supported
[01:32:26] [Step 2/2]
[01:32:26] [Step 2/2]
[01:32:26] [Step 2/2] -- NAP version: 0.5.2
We will continue to compile, test and validate the current x86-64 macOS (Catalina) build until it breaks, but that’s pretty much it. We will not update and maintain the macOS third party dependencies, support newer versions of macOS or add support for the M1.
That said: we encourage passionate MAC users to contribute, maybe even take over maintenance. There has been some effort already. We’re not planning on removing the macOS directives from the build system so supporting it remains completely possible.
Why? This is not because we don’t like the hardware, but because of the continuous tightening of restrictions of macOS, including: aggressive gate-keeping, required app singing, forcing specific data structures upon developers and vague, forever changing and breaking , requirements and policies. It’s simply not in line with our policies and what we stand for and goes against the FOSS mindset that NAP embraces.
We cannot sign the binaries and expect our users to do the same, subsequently, we cannot present our clients with apps that Apple flags as ‘damaged’, even if the application runs completely fine. We tried to work around & implement features to tackle these requirements but in doing so we wasted valuable time, time we’d like to spend on new features and general improvements. The problem is not only that requirements change from macOS release to release, but figuring out what those changes entail and how to properly address them is often poorly documented (looking at you code signing!). Trust me, it’s a # time sink. Especially for larger platforms. For these reasons it’s time to say goodbye to Apple and focus on platforms that don’t get in our way and let us do our job.
Apple, here’s a thought: Instead of making the life of developers more difficult, consider making it more fun.
Python
Python integration using Pybind is now disabled by default, unless enabled explicitly by specifying the -p
or --enable-python
flag. This flag is available when generating a solution, building a project or packaging nap from source. Why? Support for python has never been implemented 'properly'. We don't use it in production and we (unfortunately) don't have the time to properly support it. Pybind is currently directly integrated into our RTTI system and only partially exposed, which in turn creates a non uniform python interface. We therefore decided to officially drop support and deprecate the feature. When a user enables python the following deprecation message is logged by CMAKE:
CMake Deprecation Warning at CMakeLists.txt:60 (message):
Python is no longer officially supported
NAP 0.5.1
Minor release that fixes some small annoyances:
- Improve installation instructions
- Set default build configuration, cross platform, to
Release
- Source & Package context
- Set default make configuration (Linux) to
Release
- Source & Package context
- Improve package validation
- Update documentation to reflect changes
Download
- NAP-0.5.1-Win64-x86_64.zip
- NAP-0.5.1-Linux-x86_64.tar.bz2
- NAP-0.5.1-macOS-x86_64.zip
- NAP-0.5.1-Linux-armhf.tar.bz2
NAP 0.5.0
Major release that introduces many new features, general improvements and the usual set of fixes.
Download
- NAP-0.5.0-Win64-x86_64.zip
- NAP-0.5.0-Linux-x86_64.tar.bz2
- NAP-0.5.0-macOS-x86_64.zip
- NAP-0.5.0-Linux-armhf.tar.bz2
New Features
New Look & Feel
We completely re-styled NAP and everything associated with NAP. Including the Logo, Icons, Colors & Fonts. We applied all of these changes to every part of the eco-system, including the NAP Website, applications, editor (Napkin), portal (new), sequencer, online documentation, readme etc. Big shout out to NEO-METABOLISM, the agency that helped us achieve pixel perfect results.
Vulkan Compute
Use the Vulkan Compute API to run general computation tasks on the GPU using a simple to use NAP interface. Integrates seamlessly into our graphics engine, where synchronization of buffers and compute / graphics commands is handled for you. Read, write, bind and sample from any type of buffer, texture and set of uniforms from anywhere in your custom Compute or Graphics pipeline.
New:
nap::ComputeComponent
(mod_naprender)- Sets up and dispatches the compute program
nap::ComputeShader
(mod_naprender)- Compute program
nap::ComputeMaterial
(mod_naprender)- Compute program bindings (uniforms, textures, buffers)
Demos:
computeflocking
democomputeparticles
demo
Bind nap::GPUBuffer
to Compute and Graphics shaders
- Create and bind any
nap::GPUBuffer
to Compute and Graphics shaders as a storage buffer (mod_naprender)- Similar to binding a
nap::Texture2D
using aSampler
- Buffer can be read and set inside a shader program.
- Similar to binding a
- Bind any type of
nap::GPUBuffer
to a shader using a genericnap::GPUBufferBinding
nap::StructBuffer
nap::GPUBufferFloat
etc.nap::VertexBuffer
nap::IndexBuffer
- Fill buffers on intialization using a
nap::Fillpolicy
Demos:
computeflocking
computeparticles
Web Portal
Automatically generates a web interface to control & monitor your NAP application, in real-time, from a web browser. Use the nap::PortalComponent
to expose the parameters and resources you want to view and edit in a browser. Use the (open-source) NAP Portal node module, in combination with the (open-source) NAP Dashboard to generate a website, based on those exposed items, for you. Simply connect to the portal inside a browser and control your application from anywhere on the network. Completely data-driven.
New:
nap::PortalComponent
(mod_napportal)- Handles communication between the NAP application and a web portal.
nap::PortalEvent
(mod_napportal)- Used for communication between the client and server side of NAP portals.
nap::PortalItem
(mod_napportal)- Represents a single item (e.g. slider, toggle, button) in a NAP portal.
nap::PortalItemTextArea
nap::PortalItemButton
nap::PortalItemRGBColor8
nap::PortalItemOperationalCalendar
nap::PortalItemVec4
- etc.
- Represents a single item (e.g. slider, toggle, button) in a NAP portal.
nap::PortalWebSocketServer
(mod_napportal)
Demos:
webportal
demo
NAP Dashboard (browser) communicating with the the NAP Web Portal demo
Raspberry Pi Support
Added full support for The Raspberry Pi 4, Raspbian Bullseye (11), armhf
, including access to the GPIO
pins & Vulkan Compute / Rendering. You can download the pre-compiled package right here or compile NAP from source, following the regular build instructions. To make life easier we pre-compiled QT for you. The entire engine and toolset is supported, including the compilation, packaging and running of all demos, apps and editor. We are already using it in production. Performance is quite impressive, most demo apps run at about ~80-90 fps.
New:
- Support for Raspbian Bullseye (11, armhf)
- Follow installation instructions when working from package
- Follow compilation instructions when working from source
- Support for GPIO pins (mod_nappipins)
- For better performance, consider turning off
SampleShading
and lowering the amount ofSamples
on render targets, including:nap::RenderWindow
nap::RenderTarget
Demos:
Every demo compiles and runs. pipins
demo is only available for the Raspberry Pi 4, demonstrates how to use the GPIO
pins in combination with the mod_nappipins
module.
Tutorials:
@TimGroeneboom wrote a great tutorial on how to develop and deploy NAP on the Raspberry PI 4 using CLion. Including general tips & tricks to get more out of NAP running on the Raspberry Pi.
Line Blending demo running on the Raspberry Pi 4 (Vulkan)
Known Issues:
The heightmap
and computeflocking
demos initialize / run but have render issues. Both show artefacts and are 'glitchy', sometimes giving different results each run. No Vulkan validation errors are logged or system incompatibility issues have been found. 'Could' be driver related, especially considering the demos work on all other platforms, both on integrated and dedicated GPUs. Please note that the Mesa Vulkan driver on the Pi is tagged as not production ready
.
GUI
New:
- Themes (napkin & mod_napimgui)
- Dark (default)
- Hyper Dark
- Light
- Classic
- New set of icons for editor & common actions (save, play etc.) (napkin & mod_napimgui)
- Support for drawing icons (
nap::Icon
) inside GUI elements (mod_napimgui) - Icons can be inverted based on theme preference (napkin & mod_napimgui)
- Updated theme handling (mod_napimgui & napkin)
- Introduction of
nap::gui::ColorPalette
struct (mod_napimgui)
Sequencer demo with new audio track & light theme
Multi Window demo with dark theme
Sequencer
- Audio Tracks (mod_napsequenceaudio, mod_napsequenceaudiogui)
- Stepped Curves (mod_napsequence, mod_napsequencegui)
- Manual!
Rendering
nap::RenderBloomComponent
(mod_naprender)nap::ColorAdjustmentShader
(mod_naprender)nap::BlurShader
(mod_naprender)
Module Data
Modules, similar to apps, can now have data associated with them. Module assets (data) can be located at runtime using nap::Module::findAsset
, which uses the DataSearchPaths
property of nap::ModuleInfo
to locate the asset. Examples: icons for mod_napimgui
and shaders for mod_naprender
.
Note: module data is not (yet) automatically copied by the build system when the application is packaged. Therefore it is required to add an install directive to module_extra.cmake
(under dist/cmake) to install the data when packaging an application for distribution:
mod_napimgui/dist/cmake/module_extra.cmake:
# install data directory
install(DIRECTORY ${CMAKE_CURRENT_LIST_DIR}/data DESTINATION modules/mod_napimgui)
.INI files
Introduction of .ini
files to cache state in between sessions
- Always tied to a specific module
- Used to store / restore state in between sessions
- Currently used to restore position of render windows and GUI elements.
- Can be constructed (based on your requirements) in any way, shape or form.
Improvements
- Add support for
qss
stylesheet global variables (napkin) - Optimize NAP Framework application font (mod_napimgui)
- Add labels to
SequenceTrack
inspectors (mod_napsequence) - Make
SequencePlayerAudioClock
register a process instead of connecting toUpdateSignal
(mod_napsequence) - Output nodes of
SequencePlayerAudioOutput
should be optional (mod_napsequence) - Add connectPin method to
SequencePlayerAudioOutput
(mod_napsequence) - Remove numeric pixel values from sequence gui views (mod_napsequencegui)
- Colors are set in
sequenceaudioguiservice
, derived from colors set in imgui service (mod_napsequencegui) - New thirdparty dependency folder structure, based on Arch & OS (build)
- More and better crypto signing schemes (mod_naplicense, licensegenerator), thanks to @jacwil
- Shaders are no longer hard coded but shipped as assets together with the module. (mod_naprender)
- Removed all references to Android as a potential build target (deprecated for long time)
- Updated documentation to use new style (docs)
- Documentation is now mobile-friendly (docs)
- Updated demos to use new style (demos)
- Automatic handling of service destruction through unique handle (core)
- Many more, large and small.
Fixes
- Cannot stop apps...
NAP 0.4.5
Minor release that fixes some annoyances and introduces a couple of new features and improvements.
New Features
- Project data is loaded automatically on startup (core)
- Removes the need to explicitly load a
data.json
file on application initialization - Similar to how
napkin
loads project data - Allows a user to change application data without recompiling code
- Removes the need to explicitly load a
It is recommended that you remove the 'following' line of code from your application init
procedure:
if (!mResourceManager->loadFile(helloworld.json, error))
return false;
This will ensure the file pointed to by the project.json
Data field is loaded instead:
{
"Type": "nap::ProjectInfo",
"Data": "data/helloworld.json"
...
}
- New UDP module (mod_napudp)
nap::UDPClient
&nap::UDPServer
- Receive & send UDP packages on a background or application thread
- Sorting of items in editor (napkin)
- Top level items only, including resources
- Most child items are not sorted because order of declaration = order of processing
Improvements
- RTTI type column (text) is now dimmed (napkin)
- Ask to update project defaults when a new file or configuration is opened that is not currently set (napkin)
- Rename filter model to proxy model (napkin)
- Utility to avoid costly inaudible denormal math in audio (mod_napaudio)
- Added
getTaskCount()
method to ThreadPool (core) - Improved notification messages (napkin)
- Add icon to group item (napkin)
Fixes
- Accept
ENOENT
(non existing file) (fileutils) - Ensure separator const correctness (fileutils)
- Fixing path forwarding when file link is set (napkin)
- Empty file links are forwarded to data directory instead of project (napkin)
- Fixing const correctness GCC (napkin)
- Don't declare FCurve twice just for export reasons (mod_napmath)
- Only forward declare and export specialized FCurve constructor (mod_napmath)
- Duplicate sequencer type declarations (mod_napsequence)
- Remove duplicate tween handle type declarations (mod_napsequence)
- Fix typo in RTTI_ENABLE documentation (core)
- Module exports (mod_napsequence)
- All napkin globals are now
inline constexpr
, instead of static (napkin) - Tween enumerator type definition