NAP 0.8.0

Major release that introduces new features, general improvements and the usual set of fixes. This is release is almost backwards compatible with NAP 0.7.X and shouldn't require major changes when upgrading.

Download

• NAP-0.8.0-Win64-x86_64.zip
• NAP-0.8.0-Linux-x86_64.tar.bz2
• NAP-0.8.0-Linux-arm64.tar.bz2

New Features

Wayland, SDL3 & High DPI Rendering

Bump and integrate SDL 3; primarily because of the improved, now uniform, cross platform handling of high DPI displays. As a consequence, NAP applications now scale correct on every supported platform. This resolves the High DPI scaling Linux/X11 issue. It also gave me the opportunity to introduce a video back-end driver selector, which is shared between the editor and applications. Native wayland applications are now supported.

You can now ask NAP to run applications explicitly in X11 or Wayland on Linux. By default the system default is used, which selects the most appropriate video driver for your platform. On Ubuntu 24.04 this is XWayland on Raspberry Pi OS this is most likely Wayland, unless you revert to X11. The new VideoDriver option is a property of the nap::RenderServiceConfiguration, configurable in Napkin.

Note that native wayland apps cannot be positioned programmatically. The system will issue an error when the nap::RenderWindow::setPosition call fails. There are also other constraints you should be aware of before going full wayland, outlined in the SDL3 Wayland wiki.

Applets

Complete NAP applications that run inside another host process, alongside each other, thread safe.

Multiple applets can run at the same time, without interference unless requested. They're all bound to their own thread and all resources are local to that thread, including: core, the resource manager, spawned objects, services, the render engine etc. Currently, Napkin uses applets primarily for previewing assets like textures and meshes, but they can also be launched in any host environment as fully functional, standalone NAP applications. And you’re not limited to just one—you can run as many as you need.

Applets in Napkin enable developers or end-users to preview and inspect content before it is fully integrated into the main application, giving them a better understanding of what they are authoring (such as textures, meshes, materials, and more) and helps ensure the data is compatible with the application. The texture and mesh preview applets demonstrate this functionality, running inside Napkin. #81

System

Background & Threading

For this to work we had to re-work all the parts of the core system that are currently not thread safe, ie: not intended to be part of another process, which included services tied to imgui, sdl, the nap::RenderEngine and the nap::ModuleManager. We also improved the caching and handling of modules - resulting in much faster load times on Linux and Windows.

While working on module resolve for applets (including shared modules), I added a dependency list for each module in the project. This helps identify and flag redundant modules that were loaded earlier, making it easier to clean up the project. The introduction of this nap::ModuleCache, alongside the dependency tracking, leads to faster startup times. Napkin now launches in less than 3 seconds in release mode, with 3 NAP instances loading concurrently.

Integration

It is relatively straight forward to add a new applet to Napkin or another host environment: Every applet is spawned, initialized and run by an AppletRunner. API events are used to communicate with the applet without stalling the host application. Applets behave for the most part like a regular NAP application: they are sourced from an app.json and load all required modules and data (sequentially) using the standard core de-serialization and init procedures. You can even author your applet inside Napkin, like a regular application!

The applets inside Napkin run at 60fps but process events immediately when detected, without waiting. When an applet is disabled or minimized (hidden), it becomes inactive—stopping all processing and entering sleep mode to save resources. This behavior can be customized to suit specific needs, including the option to only render a frame when input is received.

Window & Events

Each applet that is spawned (via the RenderPanel widget hosting it) is bound to a Vulkan-compatible QWindow, rather than a Vulkan-compatible window created by SDL. Upon initialization, the nap::RenderWindow is set up using a window handle from Qt, instead of being created directly using SDL, which is achieved by registering a render window creation function prior to applet initialization.

The RenderPanel QWidget intercepts input events and converts those into NAP events using an AppletEventConverter. This is very similar to how the default SDLEventConverter works. All other remaining SDL functionality is confined to the applet thread, except for video subsystem initialization, which happens on the main thread before applet creation, as outlined in the official SDL documentation. I’ve disabled most SDL events and periodically pull to clear potential entries in the queue. Applets can be resized and undocked, like regular QDock widgets.

Texture Preview Applet

Allows you to inspect a 2D texture and cubemap in 2D and 3D, including all of it's properties such as: resolution, channels, bit depth etc. Every type of 2D texture and cubemap is supported, including the nap::ImageFromFile and nap::CubeMapFromFile.

• 2D textures can be previewed flat (orthographic, aspect-corrected) or on 3D meshes.
• Cube maps are applied to a skybox and reflected on a 3D (custom) mesh.
• The applet also provides detailed information about the texture, including available attributes, bounds, etc.

The last loaded object is tracked, and any property changes are detected and re-uploaded. The object is always framed correct, regardless of size, using its actual bounds to compute camera offsets and planes.

Video from old build:

texture_mesh_preview_LQ.mp4

Mesh Preview Applet

Allows you to inspect a mesh in 3D, including all of it's properties such as: light information, triangle count, available vertex attributes, connectivity, topology, bounds etc. Every type of mesh is supported, including triangular and non-triangular meshes.

The last loaded object is tracked, and any property changes are detected and re-uploaded. The object is always framed correct, regardless of size, using its actual bounds to compute camera offsets and planes.

Module Descriptor

Every NAP object now knows which module it originates from. This is achieved by registering a static function local to the translation unit that has a handle to the module descriptor, which is registered and resolved automatically when you define your type. You can access the module for any given type by using nap::rtti::getModuleDescription(T). #81

Zoom & Pan Controller

The new nap::ZoomPanController allows for freely moving around and zooming into a scene or 2D texture using an orthographic camera. Use the frameTexture function to adjust the scale and position of your texture, ensuring it fits perfectly in the viewport. #81

Improvements

• Group resources by module in Napkin instead of a flat list #81
  • Making it easier to search for and find specific resources.
• New icons for common types, including nap::Texture, nap::IMesh, nap::Material, nap::Window, nap::Shader etc.
• New nap::UVTestTexture, nap::TestCubeMap and nap::SunsetCubeMap for demo, debug and test purposes. #81
• New nap::HumanoidMesh, nap::ToyMesh, nap::ShaderBallMesh and nap::LucyMesh for demo, debug and test purposes.
• Displays are no longer cached #104
  • RenderService::getDisplays now returns a list of currently connected displays
  • Added new display properties, including Display::EOrientation
  • Moved nap::Display into it's own header (display.h), included by renderservice.h
• The content scaling factor is now window relative, and no longer tied to the display #104
  • Use nap::RenderWindow::getDisplayScale to get the actual (final) content display scale
  • Use nap::RenderWindow::getPixelDensity to get the window pixel density
  • Use nap::Display::getContentScale to get the content scale of a display
• High DPI mode is made implicit and always enabled #104
  • As a result, RenderService::getHighDPIEnabled is deprecated and always returns true
• Default window icons (Windows, X11..), using SDL::createSurface #104
• Implement depth resolve attachments (MSAA) for depth render texture resources #90
• Improved setup of nap::BoxFrameMesh #90
• Add nap::ColorDepthRenderTarget to renderadvanced, restoring the simplicity of nap::RenderTarget
• Remove Vulkan version check from renderadvanced #90
• Remove nap::BufferBindingUVec4 #90
• Many new SDL helper functions #104
• Initialize shader compilation using provided (default) config. #107
• Allow initialization of render service...

NAP 0.7.7

Incremental release that adds support for new platforms, introduces some new features and fixes some outstanding issues. This is the final incremental release before NAP 0.8.

Download

• NAP-0.7.7-Win64-x86_64.zip
• NAP-0.7.7-Linux-x86_64.tar.bz2
• NAP-0.7.7-Linux-arm64.tar.bz2

New Features

Support for multiple Visual Studio versions

• The system default version of Visual Studio is selected as generator for cmake, together with it's toolchain. #68
• Both Visual Studio 16 (2019) and 17 (2022) are now supported. #68

FFT Support

audiovisual_demo_720.mp4

• New napfft system module (napfft) #38
• New audiovisualfft demo, using new FTT possibilities & GPU Compute (napfft & naprender) #38
• Implements real-optimized FFTs (positive half-spectrum: nfft/2+1 complex frequency bins) using Kiss FFT.

Improvements

• Add shadow spread property to LightComponent (naprenderadvanced) #63
• RenderBloomComponent refactor (naprender) #65
• Improved render obect sorting and filtering (naprender) #66
• Simplified the build script interfaces (build) #68
  • No longer are arguments specific to a platform - they are shared.
  • Replaced platform specific build commands (make, xcode etc.) with the more generic cmake --build command.
• Removal of (a lot of) string literals in tools/buildsystem (build) #68

Fixes

• Smoothdamp fix (napmath) #64
• Napkin is only installed on Windows when the build config is Release (build) #68
• Fixed the build environment check on Linux (build) #68
  • Uses the packaged version of python instead of system default
  • Removes the loose (deprecated) version check for Qt
• Fix crash in OSCSender when UdpTransmitSocket throws uncaught exception (naposc) #74
• Start audiofile playback manually (audiovisualfft) #77
• Assert compute workgroup count on dispatch (naprender) #78
• Hot reload fix for files in sub directories on linux (core) #79

I'd like to thank @TimGroeneboom, @stijnvanbeek, @lshoek, @cheywood and @cklosters for their contributions

NAP 0.7.5

Incremental release that adds support for new platforms, bumps various dependencies, introduces some new features and fixes some outstanding issues.

Download

• NAP-0.7.5-Win64-x86_64.zip
• NAP-0.7.5-Linux-x86_64.tar.bz2
• NAP-0.7.5-Linux-arm64.tar.bz2

New Features

Raspberry Pi 5 (arm64)

• Adds support for the Raspberry Pi 5 & 4, running arm64 Raspbian 12 (Bookworm, 64 bit). #50
• Removes support for armhf Raspbian 11 (Buster, 32 bit).

This means that NAP, from this release forward, only supports 64 bit platforms.

Ubuntu 24.04 (x64)

• Ubuntu 24.04 LTS is now supported as an official target, next to Ubuntu 22.04 LTS #43
• Removes support for Ubuntu 20.04 LTS (incompatible with Qt6)

Qt6

Updates Napkin to Qt6 for all supported platforms and implements various style & rendering changes.

• Bumped version from 5.15.2 to 6.7.2 (napkin) #47
• Add pre-compiled, self-hosted Qt6 download instructions (napkin) c12da46
  • Available through .readme, simplifies setup and installation from source
• Fixed all deprecation warnings (napkin)
• Fixed RTTR compatibility msvc (C7510)
• Added a mono space font (Inconsolata) (napkin)
• Added support for varying font weights (napkin)
• Added support setting and replacing a QFont based on font key from theme (napkin)

Note that you must clear your cmake cache after you download Qt6 and attempt to generate your solution. You can do this by calling generate_solution -c, where the -c argument (new) clears the cache before the solution is generated.

Improvements

• Sequencer improvements (napsequence) #29
  • added undo / redo / rollback system
  • added coloring of segments
  • adding the ability to lock segments, preventing them from moving on the track
  • adding the ability to hit CTRL and move complete track from the drag position or just dragging one segment
• Bumped rapidjson to latest version (core) #43
• Fixed check_build_environment.sh on Linux (build) #43
• Optimized package check and download (build) #43
• Bumped libsndfile to latest version (napaudio) #43
  • Removed libFLAC dependency
• Prevent data races in napaudio (napaudio) #31
• Bump recommended version of vulkan to 1.1 (naprender) a302075
• Allow napkin to be build from source directory (build) 2d40eb7
• Don't enable x86 SSE instructions on ARM (napaudio) b36b67b
• Bump SDL2 to latest version (naprender) 96bcb07
• Remove libjack dependency Linux (napportaudio) #51

Fixes

• setFullScreen fix Linux & Windows (naprender) #48
• Allow deep copy of both rtti::Object* types and copy constructable rtti structs (napkin) #41
• nap::RenderableMesh duplication fix & improvement (naprender) #34
• Fix portaudio incorrect PortAudio openStream errors (napportaudio) #32
• Video looping (napvideo) #28
• Window alignment on init() of multiwindow demo #53

I'd like to thank @TimGroeneboom, @stijnvanbeek, @lshoek, @CasimirGeelhoed and @cklosters for their contributions

NAP 0.7.0

Major release that introduces new features, general improvements and the usual set of fixes.

Download

• NAP-0.7.0-Win64-x86_64.zip
• NAP-0.7.0-Linux-x86_64.tar.bz2
• NAP-0.7.0-Linux-armhf.tar.bz2

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 and linemorphing
• 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 and naprender/data/shaders
• nap::RenderSkyBoxComponent and nap::SkyBoxShader
• nap::RenderFrustumComponent
• Shader #include system with lots of utils naprenderadvanced/data/shaders
• nap::DepthRenderTexture2D & nap::DepthRenderTarget - separate depth texture / target
• nap::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

• NAP-0.6.3-Win64-x86_64
• NAP-0.6.3-Linux-x86_64
• NAP-0.6.3-macOS-x86_64
• NAP-0.6.3-Linux-armhf

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:

1. Open a terminal
2. Change into your NAP framework directory
3. 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:

1. Open a terminal
2. Change into your NAP modules directory
3. Clone the repository

cd modules
clone https://github.com/naivisoftware/napdatabase.git

4. 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:

1. Reduce differences between the two build contexts
2. 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:

• napopencv
• napdatabase
• napsoem
• naptween
• napyoctopuce
• napetherdream
• nappipins

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

• NAP-0.5.7-Win64-x86_64
• NAP-0.5.7-Linux-x86_64
• NAP-0.5.7-macOS-x86_64
• NAP-0.5.7-Linux-armhf

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)
  • Moved to https://github.com/napframework/nap-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

• NAP-0.5.5-Win64-x86_64
• NAP-0.5.5-Linux-x86_64
• NAP-0.5.5-macOS-x86_64
• NAP-0.5.5-Linux-armhf

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 regular nap::Group<Parameter>

Fixes

• Fix access violation in getParent of PropertyPath 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 of nap::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() and nap::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