You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thanks for asking about ray tracing capabilities in PasVulkan. I am still actively working on integrating this feature. It's a complex task that requires careful implementation to meet the performance and functionality standards I've set for PasVulkan.
And I appreciate your question on why SDL is utilized in specific contexts within PasVulkan. Allow me to outline the reasoning behind its selective integration based on the operating system:
The integration of SDL is highly contingent on the operating system:
Linux: SDL is invaluable in this environment due to the complex and varied nature of the available APIs for different system functionalities, ranging from UI/visuals (X11, Wayland, Raw-Framebuffer) to audio (ALSA, OSS, JACK, PulseAudio, PipeWire, and so on) and input devices (jsapi, xinput, evdev, among others). The abstraction provided by SDL simplifies the process by managing this diversity. This is especially helpful considering that Linux does not always maintain backward compatibility with its APIs, which are subject to frequent changes and trends (e.g., systemd and the like). SDL, therefore, relieves developers of the considerable task of maintaining API wrappers by deferring this responsibility to the SDL and Linux distribution maintainers.
Windows: Contrary to Linux, PasVulkan does not use SDL on Windows. The consistent backward compatibility of Windows APIs allows for a more streamlined and stable native development process, making the need for the SDL layer unnecessary. As a result, PasVulkan runs smoothly and reliably on Windows without the need for SDL, utilizing the Windows native APIs for its operations in a direct way.
Android: SDL's role in PasVulkan for Android falls somewhere between its usage in Linux and Windows. While direct native API usage is generally smoother for certain tasks, such as handling display modes, SDL still provides a layer of abstraction that can be beneficial in managing the diversity of Android's system functions, since Android is also introducing new APIs and breaking old APIs often. It's a balancing act of leveraging SDL for its strengths while also recognizing scenarios where native APIs offer better performance or control.
Overall, SDL is integrated into PasVulkan where it offers significant advantages, which is mainly in the Linux environment. But for Windows, PasVulkan takes advantage of the robust native OS APIs, and on Android, it strikes a balance between SDL and native APIs based on what offers the best outcome for performance and control.
I hope this clarifies why SDL is used selectively in PasVulkan as cross-OS-API-wrapper, at least for Linux and Android.
Should you have further questions, feel free to ask.
At least, PasVulkan has its own quite feature-complete GUI framework, but it's a retained-mode GUI and not an immediate-mode GUI, because I personally don't like the idea behind ImGUIs.
In my opinion, retained-mode GUIs (RmGUIs) offer a superior approach to user interface design, particularly due to their robust handling of state and event management. The upfront layout and automatic state retention simplify the development process, making it far more convenient to handle user interactions and dynamic changes within the UI. This built-in efficiency is a significant advantage, enabling the creation of complex, responsive interfaces with less manual overhead.
Admittedly, immediate-mode GUIs (ImGUIs) can facilitate quicker development and more straightforward iteration of GUIs, often in a single pass, which can be particularly beneficial during prototyping or for simpler interfaces. However, it's important to weigh these advantages against the potential downsides, such as less efficient rendering and more complex state management, to determine if it's the best approach for a given project.
But tastes are different, after all. I myself favor RmGUIs. :-)
I want to see as soon as possible your rtx approach with RmGUI.
When it can be possible? It can be first rtx project on pascal.
One more question. Is in RmGUI can be changed font and font size?
SDL2 is for window creation, and OpenGL3 is a renderer.
But you can change the backend to anything you want
I'm currently working on implementing more of the ImGui backends in pure Pascal.
The current PasVulkan’s Scene3D based gltfviewer has been using ray_query for raytraced shadows for a long time. If a GPU with raytracing capabilities is detected, it enables raytraced shadows; otherwise, it falls back to shadow mapping. PasVulkan’s Scene3D also includes fairly complete raytracing support on the mesh side, including BVH BLAS refitting and rebuilds for animations and dynamic meshes, among other features. However, the code for BVH BLAS compaction (a two-pass method for creating BVH BLAS instances for static meshes that are smaller in VRAM than those built with a one-pass approach) is not yet complete. This feature is primarily for memory optimization and does not impact other functionalities.
Additionally, full raytracing/pathtracing support is planned for PasVulkan’s Scene3D in the near future, although this won’t be implemented until after I complete the current PasVulkan-based indie game project.
Regarding Vulkan on macOS, it’s a complicated topic. Apple does not support Vulkan natively, so you would need to use the MoltenVK Vulkan-to-Metal wrapper. However, MoltenVK cannot wrap all Vulkan features to Metal because Metal lacks support for some Vulkan features or supports them in a way that makes wrapping challenging or even impossible.
maybe exe can be smaller?
for example, switchable parameters.
also i have proposition - please add some indicator of loading file.
I try to load big gltf and where is no indicator
Unfortunately, the executable can’t be made smaller, as it’s now effectively a comprehensive game engine (currently powering two commercial games in development). The name "gltfviewer" might be misleading here, as it has evolved into a general 3D model viewer that runs on a full game engine. The gltfviewer is intended primarily as a starting-point example project for using the Scene3D stuff.
The performance slowdown could be due to raytracing but might also result from running out of video RAM, causing the system to swap in and out, which can be extremely slow—especially if you don’t have ReBAR-ready hardware (CPU, motherboard, or GPU).
And try CTRL+F8 for dumping the Vulkan-side memory usage, and Shift+F8 for Resource usage and just F8 for CPU+GPU profiler time values (it will get dump into the terminal console window).
Additionally, full raytracing/pathtracing support is planned for PasVulkan’s Scene3D in the near future, although this won’t be implemented until after I complete the current PasVulkan-based indie game project.
When you plan to implement fully path tracing support? I interested on this feature
please don't take it as impudence, but could you please give an example of path tracing with accumulation and use of tonemapper?
And save result of rendering to hdr or png?
Activity
BeRo1985 commentedon Nov 4, 2023
Thanks for asking about ray tracing capabilities in PasVulkan. I am still actively working on integrating this feature. It's a complex task that requires careful implementation to meet the performance and functionality standards I've set for PasVulkan.
And I appreciate your question on why SDL is utilized in specific contexts within PasVulkan. Allow me to outline the reasoning behind its selective integration based on the operating system:
The integration of SDL is highly contingent on the operating system:
Linux: SDL is invaluable in this environment due to the complex and varied nature of the available APIs for different system functionalities, ranging from UI/visuals (X11, Wayland, Raw-Framebuffer) to audio (ALSA, OSS, JACK, PulseAudio, PipeWire, and so on) and input devices (jsapi, xinput, evdev, among others). The abstraction provided by SDL simplifies the process by managing this diversity. This is especially helpful considering that Linux does not always maintain backward compatibility with its APIs, which are subject to frequent changes and trends (e.g., systemd and the like). SDL, therefore, relieves developers of the considerable task of maintaining API wrappers by deferring this responsibility to the SDL and Linux distribution maintainers.
Windows: Contrary to Linux, PasVulkan does not use SDL on Windows. The consistent backward compatibility of Windows APIs allows for a more streamlined and stable native development process, making the need for the SDL layer unnecessary. As a result, PasVulkan runs smoothly and reliably on Windows without the need for SDL, utilizing the Windows native APIs for its operations in a direct way.
Android: SDL's role in PasVulkan for Android falls somewhere between its usage in Linux and Windows. While direct native API usage is generally smoother for certain tasks, such as handling display modes, SDL still provides a layer of abstraction that can be beneficial in managing the diversity of Android's system functions, since Android is also introducing new APIs and breaking old APIs often. It's a balancing act of leveraging SDL for its strengths while also recognizing scenarios where native APIs offer better performance or control.
Overall, SDL is integrated into PasVulkan where it offers significant advantages, which is mainly in the Linux environment. But for Windows, PasVulkan takes advantage of the robust native OS APIs, and on Android, it strikes a balance between SDL and native APIs based on what offers the best outcome for performance and control.
I hope this clarifies why SDL is used selectively in PasVulkan as cross-OS-API-wrapper, at least for Linux and Android.
Should you have further questions, feel free to ask.
tigrazone commentedon Nov 4, 2023
Is no equivalents like ImGUI for Pascal for glfw/vulkan, no SDL?
I see in c++ world ImGUI now is standard
BeRo1985 commentedon Nov 4, 2023
At least, PasVulkan has its own quite feature-complete GUI framework, but it's a retained-mode GUI and not an immediate-mode GUI, because I personally don't like the idea behind ImGUIs.
In my opinion, retained-mode GUIs (RmGUIs) offer a superior approach to user interface design, particularly due to their robust handling of state and event management. The upfront layout and automatic state retention simplify the development process, making it far more convenient to handle user interactions and dynamic changes within the UI. This built-in efficiency is a significant advantage, enabling the creation of complex, responsive interfaces with less manual overhead.
Admittedly, immediate-mode GUIs (ImGUIs) can facilitate quicker development and more straightforward iteration of GUIs, often in a single pass, which can be particularly beneficial during prototyping or for simpler interfaces. However, it's important to weigh these advantages against the potential downsides, such as less efficient rendering and more complex state management, to determine if it's the best approach for a given project.
But tastes are different, after all. I myself favor RmGUIs. :-)
tigrazone commentedon Nov 4, 2023
I want to see as soon as possible your rtx approach with RmGUI.
When it can be possible? It can be first rtx project on pascal.
One more question. Is in RmGUI can be changed font and font size?
Coldzer0 commentedon Nov 16, 2023
I've been working on a binding for ImGui in Pascal ^_^
https://github.com/Coldzer0/ImGui-Pascal
You may find it interesting.
tigrazone commentedon Nov 16, 2023
did you use OpenGL3 or SDL?
Coldzer0 commentedon Nov 16, 2023
SDL2 is for window creation, and OpenGL3 is a renderer.
But you can change the backend to anything you want
I'm currently working on implementing more of the ImGui backends in pure Pascal.
tigrazone commentedon Nov 16, 2023
I wish not use SDL. Like in c++ version of ImGUI ;-)
Coldzer0 commentedon Nov 16, 2023
ImGui has a lot of backends, and SDL is one of them; you can use any of them.
What operation system are you targeting?
tigrazone commentedon Nov 16, 2023
I dont use Discord.
Preffered os for me is Windows and Linux. I like to use backends OpenGL/GLFW without SDL, maybe Vulkan
tigrazone commentedon Oct 29, 2024
ok. what about rtx usage after 1 year of my question.
is example with rtx pipeline and ray_query pipeline exists?
with SDL is not a problem.
one more question. Is this repo works on mac?
tigrazone commentedon Oct 29, 2024
one more idea is gltf viewer with ray_query pipeline. i interesed with build PBR raytracer
BeRo1985 commentedon Nov 2, 2024
The current PasVulkan’s Scene3D based gltfviewer has been using ray_query for raytraced shadows for a long time. If a GPU with raytracing capabilities is detected, it enables raytraced shadows; otherwise, it falls back to shadow mapping. PasVulkan’s Scene3D also includes fairly complete raytracing support on the mesh side, including BVH BLAS refitting and rebuilds for animations and dynamic meshes, among other features. However, the code for BVH BLAS compaction (a two-pass method for creating BVH BLAS instances for static meshes that are smaller in VRAM than those built with a one-pass approach) is not yet complete. This feature is primarily for memory optimization and does not impact other functionalities.
Additionally, full raytracing/pathtracing support is planned for PasVulkan’s Scene3D in the near future, although this won’t be implemented until after I complete the current PasVulkan-based indie game project.
Regarding Vulkan on macOS, it’s a complicated topic. Apple does not support Vulkan natively, so you would need to use the MoltenVK Vulkan-to-Metal wrapper. However, MoltenVK cannot wrap all Vulkan features to Metal because Metal lacks support for some Vulkan features or supports them in a way that makes wrapping challenging or even impossible.
tigrazone commentedon Nov 2, 2024
thank you for impressive work. I go to test it
tigrazone commentedon Nov 2, 2024
I'm try to compile gltfviewer but I have compiler error.
Before compile I call start.bat
Windows 10.
Lazarus 3.6
6 remaining items
tigrazone commentedon Nov 3, 2024
maybe exe can be smaller?
for example, switchable parameters.
also i have proposition - please add some indicator of loading file.
I try to load big gltf and where is no indicator
tigrazone commentedon Nov 3, 2024
big scenes rendered with 4-5 fps on my rtx 3060.
used rtx or why is slow?
BeRo1985 commentedon Nov 3, 2024
Unfortunately, the executable can’t be made smaller, as it’s now effectively a comprehensive game engine (currently powering two commercial games in development). The name "gltfviewer" might be misleading here, as it has evolved into a general 3D model viewer that runs on a full game engine. The gltfviewer is intended primarily as a starting-point example project for using the Scene3D stuff.
The performance slowdown could be due to raytracing but might also result from running out of video RAM, causing the system to swap in and out, which can be extremely slow—especially if you don’t have ReBAR-ready hardware (CPU, motherboard, or GPU).
BeRo1985 commentedon Nov 3, 2024
And try CTRL+F8 for dumping the Vulkan-side memory usage, and Shift+F8 for Resource usage and just F8 for CPU+GPU profiler time values (it will get dump into the terminal console window).
tigrazone commentedon Nov 3, 2024
Delphi build works without console and I dont know why
tigrazone commentedon Nov 3, 2024
BeRo1985 commentedon Nov 3, 2024
And with FreePascal + Lazarus?
tigrazone commentedon Nov 3, 2024
On this screen all checkboxes off in my Lazarus. Only last where strip is on
tigrazone commentedon Nov 3, 2024
Fpc+Lazarus generate code with console by default. Maybe sort of "generate gui app" dont show console
tigrazone commentedon Nov 3, 2024
If gltfviwer is demo for game engine, where I can read about this engine? And maybe cheatsheet of api?
tigrazone commentedon Nov 12, 2024
tigrazone commentedon Dec 2, 2024
When you plan to implement fully path tracing support? I interested on this feature
tigrazone commentedon Dec 2, 2024
please don't take it as impudence, but could you please give an example of path tracing with accumulation and use of tonemapper?
And save result of rendering to hdr or png?