rtx use example #32
Labels
No labels
bug
duplicate
enhancement
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
BeRo1985/pasvulkan#32
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I have 2 questions.
thank you!
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.
Is no equivalents like ImGUI for Pascal for glfw/vulkan, no SDL?
I see in c++ world ImGUI now is standard
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?
I've been working on a binding for ImGui in Pascal ^_^
https://github.com/Coldzer0/ImGui-Pascal
You may find it interesting.
did you use OpenGL3 or SDL?
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.
I wish not use SDL. Like in c++ version of ImGUI ;-)
ImGui has a lot of backends, and SDL is one of them; you can use any of them.
What operation system are you targeting?
I dont use Discord.
Preffered os for me is Windows and Linux. I like to use backends OpenGL/GLFW without SDL, maybe Vulkan
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?
one more idea is gltf viewer with ray_query pipeline. i interesed with build PBR raytracer
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.
thank you for impressive work. I go to test it
I'm try to compile gltfviewer but I have compiler error.
Before compile I call start.bat
Windows 10.
Lazarus 3.6
Which FPC version you're using?
I'm using
and as well
I use
Free Pascal Compiler version 3.2.2 [2024/09/29] for x86_64
I compile from Lazarus.
Open projects\gltfviewer\src\gltfviewer.lpi
And Run/Build
Maybe I must set some in project options?
To compile PasVulkan, you need to use either the trunk version of FreePascal (currently 3.3.1) or a recent version of Delphi. This is because the stable versions of FreePascal often lack certain features (which are available in Delphi) or contain bugs that are triggered by the PasVulkan source, especially in areas like generics, inline assembly, code generation, register allocation, and so on.
I built it with FreePascal 3.3.1
but 212mb(217 885 772) exe. why?
The large size is due to debugging symbols, as PasVulkan is a sizable project with a substantial amount of code. Without debugging symbols, the executable should be around 34 MB. Additionally, keep in mind that PasVulkan’s Scene3D requires a significant number of precompiled shader permutations, as they need to be prebuilt in SPIR-V format. So even without debugging symbols, the file size will be at least about 34 MB.
hm. I pick "strip symbols from executable".
Delphi give me 40mb exe
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
big scenes rendered with 4-5 fps on my rtx 3060.
used rtx or why is slow?
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).
Delphi build works without console and I dont know why
And with FreePascal + Lazarus?
On this screen all checkboxes off in my Lazarus. Only last where strip is on
Fpc+Lazarus generate code with console by default. Maybe sort of "generate gui app" dont show console
If gltfviwer is demo for game engine, where I can read about this engine? And maybe cheatsheet of api?
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?