tags[pbr]
INFO: Physically Based Rendering (PBR) is a rendering technique that aims to simulate the interaction between light and materials more accurately, resulting in more realistic visuals.
- Traditional rendering methods often relied on baked specular highlights, where the shine of surfaces was pre-computed and stored in the texture maps, leading to less realistic and static effects.
- PBR however, uses separate texture maps for different material properties; albedo/diffuse (base color), metallic, roughness, and normal maps. This separation allows for more precise control over how materials react to lighting conditions in real time.
Implementation of PBR material system is based on Rend2 renderer from OpenJK
Adding the ability to apply normal, roughness, metallic or specular texture maps by introducing the .mtr file extension, which is an override for .shader
tags[inspector]
tags[pbr]
INFO: IBL cubemaps use a six-sided texture to capture the surrounding environment of a point in world space. Basicly a 360° photo.
Cubemaps are generated during map-loading and are later used to reproject on 3D surfaces in real-time, allowing for more realistic specular reflections, diffuse and ambient light sampling.
Being pre-computed during map-loading makes cubemaps static, but efficient. In combination with PBR, cubemaps provide a fast way to light scenes by sampling reprojected pre-computed (static) environmental textures.
Implementation of IBL is based the on Rend2 renderer from OpenJK.
256x256 pixel dimensions are used.
tags[inspector]
Dear ImGui is a bloat-free graphical user interface library for C++. It outputs optimized vertex buffers that you can render anytime in your 3D-pipeline-enabled application. It is fast, portable, renderer agnostic, and self-contained (no external dependencies).
Dear ImGui is designed to enable fast iterations and to empower programmers to create content creation tools and visualization / debug tools (as opposed to UI for the average end-user). It favors simplicity and productivity toward this goal and lacks certain features commonly found in more high-level libraries. Among other things, full internationalization (right-to-left text, bidirectional text, text shaping etc.) and accessibility features are not supported.
Dear ImGui is particularly suited to integration in game engines (for tooling), real-time 3D applications, fullscreen applications, embedded applications, or any applications on console platforms where operating system features are non-standard.
- Minimize state synchronization.
- Minimize UI-related state storage on user side.
- Minimize setup and maintenance.
- Easy to use to create dynamic UI which are the reflection of a dynamic data set.
- Easy to use to create code-driven and data-driven tools.
- Easy to use to create ad hoc short-lived tools and long-lived, more elaborate tools.
- Easy to hack and improve.
- Portable, minimize dependencies, run on target (consoles, phones, etc.).
- Efficient runtime and memory consumption.
- Battle-tested, used by many major actors in the game industry.
tags[inspector]
tags[inspector]
Legit profiler: ImGui helper class for simple profiler histogram
Repository -
License
tags[inspector]
ImGuiColorTextEdit: Syntax highlighting text editor for ImGui
Repository -
License
ImNodeFlow: Node-based editor/blueprints for ImGui
Repository -
License
NetRadiant-custom: The open-source, cross-platform level editor for id Tech based games.
- As Inspiration for auto-complete -
Commit -
Repository -
License
tags[rtx]
NOTE This is Work-in-progress, and is unstable. \
I wanted to learn more on the topic of RayTracing.
The current implementation is not yet complete, but the essential functionality should be there.
It needs more TLC, due to time constraints I have decided to put this project on hold.
I believe its a waste to let this codebase collect dust, and decided to share it.
Because the Jedi Knight community remains highly active, with further development, this project could become stable and playable, either through my efforts or with your involvement.
I used Quake-III-Arena-R as a starting point, however transitioned to Q2RTX relativly quickly.
Q2RTX is active and receives frequent updates.
Also the code base is very clear plus I like the RayTraced result!
I can highly recommend you to give their great effort a try if you have not done so already.
Main differences in this codebase:
Q2RTX implemented their own material system.
However I wanted to use the native .shader and support the .mtr material system from Rend2
I did a quick mockup of that, I have not added multistage support yet.
Ghoul2 support is added (No MD3 yet), and uses the same IBO's and VBO's used for Beta and PBR branch with minor tweaks.
Q2RTX uses a single buffer for the IBO and VBO and does not have Ghoul2 support.
I did port this method, but it is define guarded and can safely be removed.
GETTING STARTED
Set cvar r_normalMapping 1, r_specularMapping 1, r_cubeMapping 0, r_hdr 0, r_fullscreen 1 and r_vertexLight 2 Everything is define guarded using USE_RTX in the codebase
IMPORTANT Requires assets from Q2RTX on Steam
Download and locate the install folder and open baseq2 folder
Locate and open blue_noise.pkz and copy the folder "blue_noise" to the base folder of your Jedi Academy install folder.
Do the same for the folder "env" in q2rtx_media.pkz.
You should now have the following file structure: GameData/base/blue_noise and GameData/base/env
*~ Give Q2RTX a try as well*
Sources:
Quake-III-Arena-R
Q2RTX - License
References:
Vulkan Specification
SaschaWillems - Vulkan
tags[all]
r_DynamicGlow
r_DynamicGlowAllStages - Vanilla renderer skips certain collapsed glow stages. Render these anyway (3e62987)
r_DynamicGlowPasses unused
r_DynamicGlowDelta unused
r_DynamicGlowIntensity Controls intensity/brightness
r_DynamicGlowSoft unused
r_DynamicGlowWidth unused
r_DynamicGlowHeight unused
r_DynamicGlowScale unused
tags[all]
- high-quality per-pixel dynamic lighting
- very fast flares (\r_flares 1)
- anisotropic filtering (\r_ext_texture_filter_anisotropic)
- greatly reduced API overhead (call/dispatch ratio)
- flexible vertex buffer memory management to allow loading huge maps
- multiple command buffers to reduce processing bottlenecks
- reversed depth buffer to eliminate z-fighting on big maps
- merged lightmaps (atlases)
- multitexturing optimizations
- static world surfaces cached in VBO (\r_vbo 1)
- useful debug markers for tools like RenderDoc
- fixed framebuffer corruption on some Intel iGPUs
- offscreen rendering, enabled with \r_fbo 1, all following requires it enabled:
-
screenMaptexture rendering - to create realistic environment reflections - multisample anti-aliasing (\r_ext_multisample)
- supersample anti-aliasing (\r_ext_supersample)
- per-window gamma-correction which is important for screen-capture tools like OBS
- you can minimize game window any time during \video|**\video-pipe*- [x]recording
- high dynamic range render targets (\r_hdr 1) to avoid color banding
- bloom post-processing effect
- arbitrary resolution rendering
- greyscale mode
Source: Quake3e
tags[all]
Refraction method ported from Rend2
tags[all]
INFO: An offscreen FBO (Frame Buffer Object) is used to render to a separate image or texture that is not directly displayed on the screen. This allows for techniques like post-processing effects or rendering to textures for later use. On the other hand, a non-FBO approach involves rendering directly to the swapchain (screen), which is suitable for simple rendering scenarios without the need for offscreen rendering or additional processing.
Enable for:
- Dynamic glow
- Multisample anti-aliasing (MSAA)
- Bloom
- Refraction
- PBR branches have this enabled hard-coded
r_fbo
tags[all]
INFO: VBO (Vertex Buffer Object) caching is a technique used to optimize rendering performance for static surfaces. By storing vertex data in a VBO on the GPU, it can be efficiently reused across multiple draw calls, reducing the overhead of transferring data to the GPU. This is particularly beneficial for surfaces that do not change frequently, as it minimizes the CPU to GPU communication and improves overall rendering efficiency.
PBR branches have this enabled hard-coded
- Native master branch implements VBO caching for static world surfaces.
PBR branches have this enabled hard-coded \
r_vbo - Cache static surfaces:
0 : off
1 : world
tags[all]
INFO: Lightmaps are baked textures used to simulate lighting in 3D environments. They store information about how light interacts with surfaces, such as shadows and color variations. By applying these lightmaps to static world surfaces, it can achieve a more visually appealing environment.
- Vanilla renderer uses individual lightmaps.
- Copies of a .shader entry (material) live in memory seperately for surfaces not sharing a lightmap.
- Only surfaces sharing a .shader entry (same lightmap) in memory, can be merged.
Vulkan renderer merges multiple lightmaps into texture atlases, increasing mergeability of surfaces thus reducing GPU drawcalls
tags[all]
In addition to static world surfaces support for Ghoul2 (player) and MD3 models is added.
- Bone matrices are transformed on the GPU.
- Use indirect drawing instead of indexed
- Colors and deformed texture coordinated, are no longer pre-calculated by the CPU but happen on the GPU directly.
Enabled hard-coded on PBR branches
r_vbo_models - Cache static surfaces:
0 : off
1 : models
tags[all]
r_bloom
r_bloom_threshold - Color level to extract to bloom texture, default is 0.05
r_bloom_intensity - Final bloom blend factor, default is 0.15
r_bloom_threshold_mode - Color extraction mode:
0 : ( r | g | b ) >= threshold
1 : ( r + g + b ) / 3 >= threshold
2 : luma( r, g, b ) >= threshold
r_bloom_modulate - Modulate extracted color:
0 : off (color = color, i.e. no changes)
1 : by itself (color = color * color)
2 : by intensity (color = color * luma(color))
tags[all]
