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