With this it is now possible to enable atlasing of shadow maps, which solves the existing limitation of 4 lights in a scene. This is done by
grouping the rendering of shadow maps, that currently are drawn into their own images for each light, into one or several big textures. This was
done because the openGL and webGL version Armory targets do not support dynamic indexing of shadowMapSamplers, meaning that the index that
access an array of shadow maps has to be know by the compiler before hand so it can be unrolled into if/else branching. By instead simply
using a big shadow map texture and moving the dynamic part to other types of array that are allowed dynamic indexing like vec4 and mat4, this
limitation was solved.
The premise was simple enough for the shader part, but for the Haxe part, managing and solving where lights shadow maps should go in a shadow map
can be tricky. So to keep track and solve this, ShadowMapAtlas and ShadowMapTile were created. These classes have the minimally required logic
to solve the basic features needed for this problem: defining some kind of abstraction to prevent overlapping of shadowmaps, finding available
space, assigning such space efficiently, locking and freeing this space, etc. This functionality it is used by drawShadowMapAtlas(), which is a
modified version of drawShadowMap().
Shadow map atlases are represented with perfectly balanced 4-ary trees, where each tree of the previous definition represents a "tile" or slice
that results from dividing a square that represents the image into 4 slices or sub-images. The root of this "tile" it's a reference to the
tile-slice, and this tile is divided in 4 slices, and the process is repeated depth-times. If depth is 1, slices are kept at just the initial
4 tiles of max size, which is the default size of the shadow map. #arm_shadowmap_atlas_lod allows controlling if code to support more depth
levels is added or not when compiling.
the tiles that populate atlases tile trees are simply a data structure that contains a reference to the light they are linked to, inner
subtiles in case LOD is enabled, coordinates to where this tile starts in the atlas that go from 0 to Shadow Map Size, and a reference to a
linked tile for LOD. This simple definition allows tiles having a theoretically small memory footprint, but in turn this simplicity might make
some functionality that might be responsibility of tiles (for example knowing if they are overlapping) a responsibility of the ones that
utilizes tiles instead. This decision may complicate maintenance so it is to be revised in future iterations of this feature.
Windows Settings:
Visual Studio Version - select the studio version for which the project will be exported. Options: 2010, 2012, 2013, 2015, 2017, 2019. Default: 2019.
Update - checks the installed versions of Visual Studio on the PC and adds (installed) to the version in the list if available (for information). Example:
sample_vs_2
Action After Publishing - select an action after a successful publication. Options:
Nothing - do nothing. Default value;
Open In Visual Studio - open the project in the corresponding studio version;
Compile - compilation of the project;
Compile and Run - compile and run the project. Then the executable file will be copied to the windows-hl folder (where the resources are located).
Mode - compilation mode. Options: Debug, Release. Default: Debug.
Architecture - the architecture for which the application will be built. Options: x86, x64. Default: version of the user’s PC architecture.
Compile Log Parameter - setting the output of messages during compilation:
Summary - show the error and warning summary at the end. Default value;
No Summary - don \ 't show the error and warning summary at the end;
Warnings and Errors Only - show only warnings and errors;
Warnings Only - show only warnings;
Errors Only - show only errors.
More details can be found here - MSBuild command-line reference (I took only part of the settings).
Count CPU - specifies the maximum number of concurrent processes to use when building. More details can be found here - MSBuild command-line reference. The default is 1. Maximum value: the number of CPUs in the system (function multiprocessing.cpu_count()).
Open Build Directory - open the folder with the application after a successful build. If the Compile and Run option is selected, then the executable file will be copied to the windows-hl folder (where the resources are located) and this folder will open. Otherwise, the folder where the given Visual Studio file is going will open.
The user will also receive a message if the studio version selected for export and for opening in the studio or compilation is not on the PC. And a list of installed ones will be issued. Example:
Visual Studio 2017 (version 15) not found.
The following are installed on the PC:
- Visual Studio Community 2019 (version 16.8.30711.63)
To obtain information about the installed versions of Visual Studio, use the vswhere.exe utility (open source) included in Kha (located in the …\ArmorySDK\Kha\Kinc\Tools\kincmake\Data\windows).
First version:
- Dynamically checking the correctness of an expression in the IDE (Blender).
- The task is divided into 2 parts: checking the correctness through python in the Blender interface and when performing calculations when the application is running in haxe.
The following decisions are taken as a basis:
python - http://repl.it/3xv/1
haxe - https://github.com/maitag/formula (added all the necessary classes to the node code)
- Fixed a bug with updating the list of emulators if they are not there.
- Fixed a bug with enabling/disabling options when changing links to Android SDK.
- Fixed display of settings in the form of open panels. When collapsing panels appear incorrect display.
