Skip to content

Releases: napframework/nap

NAP 0.7.0

30 May 12:20
Compare
Choose a tag to compare

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

nap_interface

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

Screenshot 2024-01-04 140502

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:

Screenshot 2024-01-04 135833

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:

333270933-de32081a-e1ef-4bf6-9bf9-e376697ec1c1

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

Read more

NAP 0.6.3

01 Feb 13:00
Compare
Choose a tag to compare

'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

16 Jun 12:29
aa2e6b1
Compare
Choose a tag to compare

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.

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

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

Read more

NAP 0.5.7

15 Jun 12:10
Compare
Choose a tag to compare

'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

New Features

Bugs

Download

Special thanks to @lshoek @stijnvanbeek @TimGroeneboom @cklosters @cheywood


NAP 0.5.5

15 Nov 13:38
Compare
Choose a tag to compare

'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

10 Aug 08:17
a32c322
Compare
Choose a tag to compare

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.2

25 Jul 08:05
Compare
Choose a tag to compare

Minor release that introduces a couple of new features, improvements and general bug fixes.

Download

New Features

Grouping

Group together resources of a specific type with the nap::Group<T>. Use Napkin to to create and author groups:

napkin_grouping

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:

sequencer_resizing

  • 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

Fixes

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

26 Apr 13:24
Compare
Choose a tag to compare

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.0

07 Apr 16:27
2c4f4dd
Compare
Choose a tag to compare

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

Download

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 demo
  • computeparticles demo

01-03-NAP-screen
Compute Flocking 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 a Sampler
    • Buffer can be read and set inside a shader program.
  • Bind any type of nap::GPUBuffer to a shader using a generic nap::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.
  • nap::PortalWebSocketServer (mod_napportal)

Demos:

webportal demo

01-05-NAP-screen
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)
  • Support for GPIO pins (mod_nappipins)
  • For better performance, consider turning off SampleShading and lowering the amount of Samples 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.

2022-04-06-165653_1920x1080_scrot
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)

01-02-NAP-screen
Sequencer demo with new audio track & light theme

01-07-NAP-screen
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 to UpdateSignal (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...
Read more

NAP 0.4.5

23 Nov 17:35
Compare
Choose a tag to compare

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

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