Skip to content

OpenGL/OpenCL/CUDA/OptiX and soon OpenGL ES/Vulkan Modular Rendering Framework for PC/Linux and soon Android

License

Notifications You must be signed in to change notification settings

Crisspl/Nabla

 
 

Repository files navigation

IrrlichtBAW

License

IrrlichtBAW is a new renovated version of older Irrlicht engine. The project currently aims for a thread-able and Vulkan-centered API, but currently works on OpenGL only. This framework has been kindly begun by the founder @devshgraphicsprogramming of Devsh Graphics Programming Sp. z O.O. and almost entirely sponsored by Build A World Aps. in it's early days, and now picked up by the Ditt company. The stable-ish branch is used in production releases of Build A World EDU, since 2015. The framework has been used both for game development and ArchViz.

Contracting

The members of Devsh Graphics Programming Sp. z O.O. (Company Registration (KRS) #: 0000764661) are available (individually or collectively) for contracts on projects of various scopes and timescales, especially on foreign frameworks, codebases and third-party 3D frameworks. We provide expertise in OpenGL, OpenGL ES, WebGL, Vulkan, OpenCL, CUDA, D3D12 and D3D11, computer vision, Audio programming, DSP, video encoding and decoding as well as more generalized High Performance Computing. Our language of choice is C++17 with C++11 and C11 coming in close second, however we're also amenable to Java, Python and related languages.

Contact @devshgraphicsprogramming (e-mail available in the GitHub profile) with inquires into contracting.

Showcase

Videos

Tonemapping with AutoExposure and Temporal Adaptation

Screenshots

Screen Shots

Pseudo Spectral rendering

Thindielectric

Over 10 area lights

Raytracing sample

Raytracing sample

1 Megapixel, 1 Million Samples

Raytracing sample

BRDF Explorer

.OBJ Loader with MTL pipeline integration

Different Shape Area Light emitters

Main Features

  • Asset management pipeline
  • Automatic pipeline layout creation
  • Shader introspection
  • Using SPIR-V shaders in OpenGL
  • Libraries of GLSL shader functions
  • Compute shaders
  • Virtual Texturing
  • CUDA and OpenGL interop
  • OpenCL and OpenGL interop
  • CPU image filtering

Main Delivered Extensions

  • Mitsuba scene loader (auto-generated shaders)
  • Tonemapper
  • Fastest blur on the planet
  • Bullet physics beginner integration
  • OptiX interop
  • Radeon rays interop

Platforms

  • Windows

  • Linux

  • Android 7.0 +

  • Mac OS

  • iOS

Required Build Tools and SDK's

Vanilla Build - most extensions disabled

Vanilla + CUDA Build

IrrlichtBAW only supports CUDA interop using the Driver API not the Runtime API. We use the runtime compiled CUDA.

Because CUDA needs its own version the GeForce (Quadro or Tesla) Driver, its often a few minor versions behind your automatically updated Windows driver, the install will fail even if it prompts you to agree to installing an older driver.

So basically first remove your driver, then install CUDA SDK.

CMake warnings in reference CUDA and notes

On Windows CMake has trouble finding new packages installed after CMake, so its the perfect time to visit it's website and check for a new version installer after installing CUDA SDK.

You can also thank NVidia for making the CUDA SDK a whole whopping 2.5 GB on Windows.

Vanilla + CUDA + Optix Build

After dealing with CUDA installing just install Optix SKD.

External Dependencies

  • gl.h header for OpenGL (possible to obtain even on headless servers from mesa-libgl-devel)
  • OpenCL SDK (can get rid of it by compiling without the two OpenCL files)

Future Boost Library Dependencies

IrrlichtBAW uses or will use the following Boost libraries:

The maybe's depend on how xplatform and easy to operate the boost::context is, esp w.r.t. Linux, Windows and Android. We will not use boost::fibers as we need our own complex scheduler.

Building IrrlichtBAW library

Cloning the project

Begin with cloning IrrlichtBAW with:

git clone --recurse-submodules -j8 https://github.com/buildaworldnet/IrrlichtBAW.git

If you haven't cloned recursively, you have to also perform:

git submodule init
git submodule update

CMake config script will try to initialize submodules for you however as well, but it doesn't mean the initialization attempt will be successful.

Submodules

If you haven't initialized the submodules yourself before the CMake configure step, and out CMake submodule update script destroyed them (badly/half initialized), you can run the following set of commands, but beware - it will completely wipe any changes to submodules.

git submodule foreach --recursive git clean -xfd
git submodule foreach --recursive git reset --hard
git submodule update --init --recursive

Weird CMake behaviour, notes

Sometimes it may appear that there won't be any files in submodules directories. If so, you have to bring them back by using:

git reset --hard

on each submodule's directory required! Furthermore you have to:

git checkout tags/glew-cmake-2.1.0

in glew directory that you can find in 3rdparty/CEGUI/glew directory because of glew commiting politics. Having done it you can switch to your master/root directory and commit those changes if you want, but it isn't necessary to compile entire library.

CMake notes

Make sure Python's executable is found

  • The paragraph concerns Windows system only

Unfortunately on Windows there are often troubles with Python 3.0+ versions, because it isn't able to find and determine PYTHON_EXECUTABLE variable, so you have to fill it manually. If you use CMake-GUI you will find it in advanced options.

Consider CMake and Visual Studio version, important!

  • The paragraph concerns Visual Studio only

Make sure you have installed the latest version of Visual Studio and CMake. Within older versions sometimes there may occur that Visual Studio outputs an error associated with compiler heap space. If you don't get any error, just skip the point. It's because having x64 project opened the solution still uses 32 bit compiler exe and cannot allocate more than 4G of memory, therefore IrrlichtBAW is unbuildable. Furthermore Visual Studio doesn't provide any option to change that. Because of that you have to manually modify .vcxproj xml and add x64 to PropertyGroup nodes. Pay attention that CMake generates a standard PropertyGroup node, but it isn't enough, because you need to put it into the target where building type is directly specified. It should look for instance as following:

<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'" Label="Configuration">
    <PreferredToolArchitecture>x64</PreferredToolArchitecture>
    <ConfigurationType>StaticLibrary</ConfigurationType>
    <CharacterSet>MultiByte</CharacterSet>
    <PlatformToolset>v142</PlatformToolset>
</PropertyGroup>

Current example above shows Release mode, but you should consider Debug as well. Having it done, 64bit cl.exe binary usage will be assured. When u get this problem, don't bother with editing all the .vcxprojs. It will probably only matter while building the engine, so the only thing you have to do is edit that .vcxproj you actually use - Irrlicht.vcxproj for instance and that's it.

If you know a way to make CMake generating .vcxprojs already having those changes that will solve the issue, it will be great if you let us know about it :)

CMake on 64bit Windows

  • Best to use cmake-gui

Run cmake-gui and, as usually, give CMake root IrrlichtBAW directory and where you want CMake to put project files and click "Configure" field. When CMake asks you to choose compiler/IDE, make sure to check whether there's a distinct option for 64bit mode and, if this is the case, choose this one.

For single-config IDEs (Code::Blocks) you'll have to manually set CMAKE_BUILD_TYPE to Debug or Release. Release is default.

You also have options BUILD_EXAMPLES and BUILD_TOOLS which do exactly what they say. By "tools" you should currently understand just convert2baw.

For Windows MSVC required, MinGW build system maintenance will be delegated to the community.

CMake on 64bit Linux

Same as Windows, except that currently we have no way of setting the correct working directory for executing the examples from within the IDE (for debugging). If you care about this please submit an issue/PR/MR to CMake's gitlab.

We recommend the Codelite IDE as that has a CMake-gui generator and has been tested and works relatively nice.

Visual Studio Code suffers from a number of issues such as configuring the CMake every time you want to build a target and slow build times. Here are the issues:

  1. microsoft/vscode-cmake-tools#771
  2. microsoft/vscode-cmake-tools#772
  3. microsoft/vscode-cmake-tools#773

Clang toolset is unmaintained and untested on Linux.

First examples launching, significant notes

Remember you have to set up starting target project in Visual Studio before you begin to launch your example. To do that click on Solution Explorer, find the example name, hover on it and click on Set as StartUp Project. You can disable building examples by IRR_BUILD_EXAMPLES option in CMake.

Use IrrlichtBaW in your project!

To get IrrlichtBaW to be used by an external application without adding it as a subdirectory,but still using a submodule, you should perform following:

list(APPEND IRR_CMAKE_ARGS "-DIRR_BUILD_DOCS:BOOL=OFF") # enable only if you have doxygen installed and detectable by cmake
list(APPEND IRR_CMAKE_ARGS "-DIRR_BUILD_EXAMPLES:BOOL=OFF")
list(APPEND IRR_CMAKE_ARGS "-DIRR_BUILD_TOOLS:BOOL=OFF") # the tools don't work yet (Apr 2020 status, might have changed since then)
list(APPEND IRR_CMAKE_ARGS "-DIRR_BUILD_MITSUBA_LOADER:BOOL=OFF") # you probably don't want this extension
list(APPEND IRR_CMAKE_ARGS "-DCMAKE_INSTALL_PREFIX:PATH=${IRR_INSTALL_DIR}") # because of https://gitlab.kitware.com/cmake/cmake/-/issues/18790
ExternalProject_Add(IrrlichtBaW
    DOWNLOAD_COMMAND  ""
    SOURCE_DIR        "${IRR_SOURCE_DIR}"
    BINARY_DIR        "${IRR_BINARY_DIR}"
    CMAKE_ARGS        ${IRR_CMAKE_ARGS}
    TEST_COMMAND      ""
)

# replace with whatever you need ${PROJECT_NAME}
target_include_directories(${PROJECT_NAME}
    PUBLIC
        $<$<CONFIG:Debug>:${IRR_INSTALL_DIR}/debug/include>
        $<$<CONFIG:RelWithDebInfo>:${IRR_INSTALL_DIR}/relwithdebinfo/include>
        $<$<CONFIG:Release>:${IRR_INSTALL_DIR}/include>
     # these are needed because we haven't cleaned up the API properly yet
        $<$<CONFIG:Debug>:${IRR_INSTALL_DIR}/debug/source/Irrlicht>
        $<$<CONFIG:RelWithDebInfo>:${IRR_INSTALL_DIR}/relwithdebinfo/source/Irrlicht>
        $<$<CONFIG:Release>:${IRR_INSTALL_DIR}/source/Irrlicht>
)
target_link_libraries(${PROJECT_NAME} 
	 $<$<CONFIG:Debug>:${IRR_INSTALL_DIR}/debug/lib/Irrlicht_debug.lib>
	 $<$<CONFIG:RelWithDebInfo>:${IRR_INSTALL_DIR}/relwithdebinfo/lib/Irrlicht_rwdi.lib>
	 $<$<CONFIG:Release>:${IRR_INSTALL_DIR}/lib/Irrlicht.lib>
)
function(link_irr_dependency DEPENDENCY_NAME)
	target_link_libraries(${PROJECT_NAME} 
		 $<$<CONFIG:Debug>:${IRR_INSTALL_DIR}/debug/lib/${DEPENDENCY_NAME}d.lib>
		 $<$<CONFIG:RelWithDebInfo>:${IRR_INSTALL_DIR}/relwithdebinfo/lib/${DEPENDENCY_NAME}.lib>
		 $<$<CONFIG:Release>:${IRR_INSTALL_DIR}/lib/${DEPENDENCY_NAME}.lib>
	)
endfunction()
function(link_irr_dependency_ DEPENDENCY_NAME)
	target_link_libraries(${PROJECT_NAME} 
		 $<$<CONFIG:Debug>:${IRR_INSTALL_DIR}/debug/lib/${DEPENDENCY_NAME}_d.lib>
		 $<$<CONFIG:RelWithDebInfo>:${IRR_INSTALL_DIR}/relwithdebinfo/lib/${DEPENDENCY_NAME}.lib>
		 $<$<CONFIG:Release>:${IRR_INSTALL_DIR}/lib/${DEPENDENCY_NAME}.lib>
	)
endfunction()
link_irr_dependency(glslang)
link_irr_dependency_(jpeg)
link_irr_dependency_(IlmImf-2_4)
link_irr_dependency_(IexMath-2_4)
link_irr_dependency_(Iex-2_4)
link_irr_dependency_(IlmThread-2_4)
link_irr_dependency_(Half-2_4)
link_irr_dependency_(Imath-2_4)
link_irr_dependency(libpng16_static)
# OpenSSL only ever exists in the Release variant
if(WIN32)
	target_link_libraries(${PROJECT_NAME} 
		 ${IRR_INSTALL_DIR}/lib/libeay32.lib
		 ${IRR_INSTALL_DIR}/lib/ssleay32.lib
	)
else()
	target_link_libraries(${PROJECT_NAME} 
		 ${IRR_INSTALL_DIR}/lib/libcrypto.lib
		 ${IRR_INSTALL_DIR}/lib/libssl.lib
	)
endif()
link_irr_dependency_(shaderc)
link_irr_dependency_(shaderc_util)
link_irr_dependency(SPIRV)
link_irr_dependency_(SPIRV-Tools)
link_irr_dependency_(SPIRV-Tools-opt)
link_irr_dependency(OGLCompiler)
link_irr_dependency(OSDependent)
link_irr_dependency(HLSL)
link_irr_dependency(zlibstatic)

If you want to use git (without a submodule) then you can use ExternalProject_Add with the GIT_ properties instead.

I recommend you use ExternalProject_Add instead of add_subdirectory for IrrlichtBaW as we haven't tested its use by 3rdparty applications that use CMake to build themselves yet (BaW EDU uses it directly from MSVC/make like it's still the stone-age of build systems).

License

IrrlichtBAW is released under the Apache 2.0 license. See LICENSE.md for more details.

API documentation, help and extra improvements

If you would like to take care of documenting some files, please click it. If you feel like you'd be interesting in improving and maintaining this repository's wiki, contact @devshgraphicsprogramming on Discord.

Official Support (Discord)

Permament members of Devsh Graphics Programming Sp. z O.O. use this to organise publicly visible work. Join to the server to get into more details. There's also a skype support group, reach @devshgraphicsprogramming for a private invite.

Credits and Attribution

The authors of IrrlichtBAW are:

Past Authors and Contributors:

Words of appreciation for developers whose software has been used in IrrlichtBAW, currently and in the past:

About

OpenGL/OpenCL/CUDA/OptiX and soon OpenGL ES/Vulkan Modular Rendering Framework for PC/Linux and soon Android

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages

  • C++ 92.7%
  • GLSL 4.6%
  • CMake 1.1%
  • C 1.0%
  • JavaScript 0.5%
  • Python 0.1%