A small commit that improves the quality of the current PBR implementation. Changes include Gamma correction to ensure the color and brightness of materials. I also made some changes to the demo scene that includes, pre-filtered skybox and zone texture along with a new floor texture that prefer.

Would be nice to separate graphics backend and allow the possibility to choose on Windows platform DirectX, OpenGL or even Vulkan in the future, now we can compile only one backend per library.

• Existing functionality that has been provided by kNet is still available.
• Added NAT punchtrough functionality.
• Added LAN discovery
• Added client-server authentication (clients can connect only with password if server has enabled it)
• Angel script bindings added to support new functionality

Things still in my to-do list:

• Add samples for LAN discovery
• Add samples for NAT punchtrough
• Do code cleanup & style fixes
• Add github wiki documentation later to describe new functionality

I need feedback from @weitjong about building system. I'm not sure I made right changes in CMake configuration files. I just made it work somehow.

I have version with automatic generation classes and functions, but code still dirty, so I PR minimal version which binds only enums to get tips about the build system.

But this minimal version may also be useful, as it fixes some detected problems with existing bindings (MouseButton incomplete, TileObjectType2D instead TileMapObjectType2D, etc)

With URHO3D_GENERATEBINDINGS=1:

1. Call doxygen to generate XMLs
2. Build https://github.com/1vanK/Urho3D/tree/master/Source/Tools/BindingGenerator
3. Generate https://github.com/1vanK/Urho3D/blob/master/Source/Urho3D/AngelScript/Generated.cpp
4. Build engine

Some notes:

1. Automatically binds all enums from Urho3D namespace
2. Ignored header files need to specify in https://github.com/1vanK/Urho3D/blob/master/Source/Tools/BindingGenerator/Tuning.cpp
3. Single ignored enums are marked in source code: https://github.com/1vanK/Urho3D/blob/master/Source/Urho3D/Graphics/GraphicsDefs.h#L116
4. Manual written bindings which require special treatment: https://github.com/1vanK/Urho3D/blob/master/Source/Urho3D/AngelScript/Manual.cpp

Problems:

1. Currently XMLs and bindings is regenerated every time when engine is compiled. Not sure I can fix it. How force doxygen regenerate xmls only when engine source code is changed? I do not consider this a big problem, since in most cases users does not need to enable URHO3D_GENERATEBINDINGS at all. Generated.cpp already pregenerated and can be automatically generated by server side.
2. Currently server does not send commit with changed Generated.cpp to repo.
3. I do not touched existed URHO3D_BINDINGS option

EDIT: Not sure static void GetXmlFiles(string dirPath, vector<string>& result) works under linux. I tested only Win version

Initial work on Nuklear UI:

I took https://github.com/rokups/Urho3D-nuklear-ui's work on Nuklear UI and moved it into the engine code.

Having problems with migrating to pure urho3d graphics pipeline though. There's some commented code that shows where the progress is. The Nuklear UI code uses OpenGL 3 and only works on OpenGL 3.

It is currently missing:

• [x] urho3d graphics pipeline integration
• [x] DirectX 11 integration.
• [x] fonts
• [x] maybe urho3d resource system for images

If someone could help me with the graphics pipeline. It'll unstick me. Please look at 074e7b0699fd158f63bc6bd6070877d3aa0005d9.

@yushli There's two samples here for Nuklear UI. One is the overview and the other is a node editor.

It can be configured to use C++ Core Guidelines checks. A place holder Lint build stage has been added in our primary CI configuration for a few weeks already. The Clang-tidy has an auto fix it feature, if the corresponding check support it. So, in the background we can also use this tool to check and fix our code base. Initially we will the let the warnings in the CI passed but eventually once we have configured which checks we want to enforce and after our code base has passed those checks in flying colors then a flag will be switched on to treat the warning as error. That is, PRs and commits will be subjected to those checks automatically and only accepted when they produce no errors.

This pull request is a fix for issue reported in #2606

The problem is caused by the bilinear texture sampling filter used on the cubemap used to index into the cube depthmap render for point lights. It seems that the default mode for cubemaps in desktop OpenGL implementations will sample textures across cubemap faces, but because the content of the indirectionCubeMap is positional information and therefore should not be interpolated across cube faces otherwise it results in shadow anomalies where the projections of edges of the light's cubemap hit the scene.

Note that I have only implemented the ability to disable seamless cubemap mode for OpenGL as I do not experience the issue in DirectX9. I can only assume that in DirectX9 seamless cubemap sampling is disabled by default in DirectX9, and therefore not exhibiting the issue?

Current emscripten fullscreen functionality is broken, this is an attempt to fix it by using custom HTML shell and one additional JS to C++ function which tells the Engine current canvas size. The sample now uses all the available viewport in the browser to display the content and the canvas/renderer resolution is automatically updated on resize.

@eugeneko @weitjong @Modanung @rokups and everyone else interested in this.

Bugs:

• [x] Mouse tracking and grabbing when switching browser tabs
• [x] Wrong resolution detected in the browser
• [x] Loading app in background tab doesn't detect input when tab is activated
• [ ] Pointer lock is lost when canvas resizing happens, user must click on canvas to re-enable it
• [x] UI cursor issues when resolution is changed
• [x] UI cursor position wrong in 125% DPI screens

Hi!

This is initial release of RaycastVehicle component, which is wrapping of Bullet btRaycastVehicle.

Many features are missing, which will be added later. The commit contains C++ code and AngelScript + Lua binding. But there is no Lua demo yet. The component is not able to save/load yet (don't know how to do it).

The purpose of this PR is to recieve feedback and review. Please remember that:

It is my first submission and many things can be wrong. Please have patience and explain to me what is wrong, I'll be more than happy to fix all things. Especially coding style errors might happen. I'm from C/Linux kernel/MCU scenery and have very little (VERY little) C++ experience. So please comment on general design errors, if I'm doing something wrong in general. I have very little experience with gamedev, so I might do things not efficiently because of lack of experience. Please point me on these, I want to learn. The motivation behind this PR is current vehicle example is not that effective, and also very rigid. I can't spawn 100 cars and have no frame drop. However with this component I can run 100 cars without slowdowns. Also the flexibility is very good. And it is easier than making everything from scratch.

The code is based on forum example by @Lumak edited and simplified by me to be minimal. I plan to implement all features provided by btRaycastVehicle and provide Lua demo too. Also I plan to do general cleanup.

This video demonstrates abilities: https://youtu.be/LKjzcN3s65Y With particles: https://youtu.be/zC0iSozwiLM

Sorry for spamming, but github did not allow me to reopen for some reason. A friend helped me to resove the issue with unreferenced symbols. This happens when btRaycastVehicle.h is included, so I had to reimplement RaycastVehicle class using opaque data, so no bullet headers are included with RaycastVehicle.h.

Remaining items (working on till weekend (till April 24)):

• [x] Remove CMAKE option, build with URHO3D_PHYSICS
• [x] Update AngelScript API to accomodate C++ changes
• [x] Update Lua API to accomodate C++ changes
• [x] Add Lua demo
• [x] Improve encapsulation (should not require wheel node hand-manipulation
• [x] Resolve motor wheels not rotating if no ground contact (Bullet behavior, but it is very annoying)
• [x] Fix save/load crash
• [x] Implement wheel dust in demo (use @Lumak offroad vehicle code for this)
• [x] Move component code to physics subdirectory
• [x] Check coding style consistency (is there some automatic tool?)

Well, current wheel handling code is adequate. The problem might arise when simulating vehicles with differentials, but I need to read more about this, but it could be implemented later. Wheel blocking by brakes can be easily implemented outside the component, as it is only a few lines and not needed to be put in FixedUpdate. So I put this on post merge "some time later" schedule.

Sometimes later TODO:

1. Block/slow down wheels on intense brakes (component code)
2. Implement skids. (demo code)
3. Implement side momentum (demo code)

Error when i press Configure

The C compiler identification is MSVC 19.0.23026.0
...
CMake Warning at CMake/Modules/Urho3D-CMake-common.cmake:128 (message):
  Could not use MKLINK to setup symbolic links as this Windows user account
  does not have the privilege to do so.  When MKLINK is not available then
  the build system will fallback to use file/directory copy of the library
  headers from source tree to build tree.  In order to prevent stale headers
  being used in the build, this file/directory copy will be redone also as a
  post-build step for each library targets.  This may slow down the build
  unnecessarily or even cause other unforseen issues due to incomplete or
  stale headers in the build tree.  Request your Windows Administrator to
  grant your user account to have privilege to create symlink via MKLINK
  command.  You are NOT advised to use the Administrator account directly to
  generate build tree in all cases.
Call Stack (most recent call first):
  CMakeLists.txt:21 (include)


CMake Error at CMake/Modules/FindUrho3D.cmake:322 (message):
  Could NOT find compatible Urho3D library in Urho3D SDK installation or
  build tree.  Use URHO3D_HOME environment variable or build option to
  specify the location of the non-default SDK installation or build tree.
  Change Dir: D:/MyGames/MiniGame/Build/CMakeFiles/CMakeTmp

Cmake found libraries but not detect lib_type

in condition

if (URHO3D_INCLUDE_DIRS AND URHO3D_LIBRARIES AND URHO3D_LIB_TYPE AND URHO3D_COMPILE_RESULT)

URHO3D_LIB_TYPE == "" URHO3D_COMPILE_RESULT == false

Maybe the error occurred for a long time. Last time I used an empty VS project to start new project.

Add support for GLES3 rendering API and it features:

• Instancing
• Uniform buffer object
• Multiple render targets
• Texture2DArray
• Texture3D
• Support for textures: ETC2, sRGB, floating point, depth, 1 & 2 channel (R & R/G). Worked render pathes - Deferred, DeferredHWDepth, Prepass, PrepassHWDepth.

Changes to get the Mac build working again. Mainly removing a lot of the tricks to speed up and/or workaround bugs with older versions of xcode that break the build the build on newer versions.

Привет! Отделил ресурсы редактора от всех прочих ресурсов, чтобы можно было из проекта игры запускать редактор без всех ресурсов сэмплов, вот таким образом: ${URHO3D_HOME}/bin/Urho3DPlayer${EXE_POSTFIX} "Editor/Scripts/Editor.as" -w -s -pp "${GAME_DIR}/bin" -p "${URHO3D_HOME}/bin/EditorData;Data;CoreData". Иначе страшно неудобно. А чтобы ресурсы редактора не путались с игровыми, всем им в путь добавил поддиректорию Editor. Заодно поменял шрифт на более читабельный (на мой вкус), надеюсь, всем тоже понравится.

После обновы https://github.com/urho3d/Urho3D/commit/724506fe48c174b1c720f12077c36d59c1654e84 в браузере ресурсов при выделении любой модели (или материала) не может определить тип ресурса (пишет Unknown)

Если скомпилировать движок с тулсетом Visual Studio 2022 (v143) в релизной версии пушка из примера https://github.com/urho3d-learn/editor при анимации сжимается в блин. В отладочной версии, а также с тулсетом Visual Studio 2019 (v142) анимация у пушки нормальная

At the moment we have a rule to put dot at the end of a doxygen comment:

/// Blah blah blah.

and do not put dot at the end of a regular comment:

// Blah blah blah

Doxygen automatically adds dots in some pages (example) and automatically removes dots in other places (example).

Is there any reason to use a different style for regular and Doxygen comments?