Here is a list of commonly asked questions about RenderDoc. Feel free to contact me if you have another question that isn't covered here or in this document.
Here is a list of commonly asked questions about RenderDoc. Feel free to `contact me<mailto:baldurk@baldurk.org?subject=RenderDoc%20question>`__ if you have another question that isn't covered here or in this document.
How do I do some particular task?
---------------------------------
Many specific tasks or functions are detailed in the "How Do I... ?" sections. These sections each take a feature or element of a workflow and explain how it fits into the program as a whole as well as any details of how it works.
If the task you have in mind isn't listed there you might find something similar, or you might find a related feature which can be used to do what you want. If the feature you want doesn't seem to exist at all you might want to check the Planned Future Features to see if it's coming soon - if it's not on that list please feel free to contact me and request it! Contact me. It has often been that simple features are very quick to implement and the prioritisation and scheduling of features is fairly fluid at this stage in development.
If the task you have in mind isn't listed there you might find something similar, or you might find a related feature which can be used to do what you want. If the feature you want doesn't seem to exist at all you might want to check the :doc:`../behind_scenes/planned_features` to see if it's coming soon - if it's not on that list please feel free to `contact me<mailto:baldurk@baldurk.org?subject=RenderDoc%20request>`__ and request it! It has often been that simple features are very quick to implement and the prioritisation and scheduling of features is fairly fluid at this stage in development.
Why did you make RenderDoc?
---------------------------
@@ -17,7 +17,7 @@ Although several tools do already exist for graphics debugging, none of them qui
In addition to this, although the functionality overlaps to some degree many of these tools were primarily designed around the profiling of applications rather than debugging. While being able to inspect the state and contents of resources does often suffice for debugging, it's not necessarily the ideal workflow and often it can become cumbersome.
In principle I didn't see any reason why I couldn't write a home-brew graphics debugger with some fairly simple operating principles. While there were a whole lot of caveats and little stumbling blocks along the way, the original design has pretty much stayed consistent since the project was started back in July 2012. If you're interested you might want to read about How RenderDoc works.
In principle I didn't see any reason why I couldn't write a home-brew graphics debugger with some fairly simple operating principles. While there were a whole lot of caveats and little stumbling blocks along the way, the original design has pretty much stayed consistent since the project was started back in July 2012. If you're interested you might want to read about :doc:`../behind_scenes/how_works`.
Where did the name come from?
-----------------------------
@@ -27,17 +27,18 @@ All of the good names were taken :-(.
Who can I contact about bugs, feature requests, other queries?
At the moment there's just me at the wheel - feel free to contact me at Contact me if you have anything you'd like to ask or suggest. I use a github repository for tracking bugs and feature requests so that's the best place to file an issue.
At the moment there's just me at the wheel - feel free to `contact me <mailto:baldurk@baldurk.org?subject=RenderDoc%20feedback>`__ if you have anything you'd like to ask or suggest. I use a `github repository<https://github.com/baldurk/renderdoc>`__ for tracking bugs and feature requests so that's the best place to file an issue.
I work on RenderDoc in my spare time but I am happy to help with anything and work with you if you have any issues that need attention.
How can I associate RenderDoc's file extensions with the program?
If you installed RenderDoc via the installer package rather than the zip folder, the option is available there to associate RenderDoc's file extensions with the program. Otherwise you can set them up from the Options Window.
Note Note
If you installed RenderDoc via the installer package rather than the zip folder, the option is available there to associate RenderDoc's file extensions with the program. Otherwise you can set them up from the :doc:`../window/options_window`.
RenderDoc will elevate itself to set up these file associations, but otherwise will not hold on to administrator permissions.
..note::
RenderDoc will elevate itself to set up these file associations, but otherwise will not hold on to administrator permissions.
RenderDoc associates .rdc and .cap with itself when desired. The .rdc files are the logfiles output when you capture inside an application. .cap files describe the set up of a particular capture, and can be used to quickly re-launch a capture preset.
@@ -50,14 +51,14 @@ If .rdc files are associated with RenderDoc a thumbnail handler is set up, so th
What APIs does RenderDoc support?
---------------------------------
Currently RenderDoc supports D3D11 (including the D3D11.1/11.2 extensions where available), Vulkan, and core profile OpenGL. Note OpenGL is a complex sprawling API, so see the details of what is supported in its own page. Since Vulkan support is in its early stages, it also has its own page.
Currently RenderDoc supports D3D11 (including the D3D11.1/11.2 extensions where available), Vulkan, and core profile OpenGL. Note OpenGL is a complex sprawling API, so see the details of what is supported in :doc:`its own page <../behind_scenes/opengl_support>`. Since Vulkan support is in its early stages, it also has :doc:`its own page <../behind_scenes/vulkan_support>`.
In future API support is planned for at D3D9 when time and scheduling allows. Higher priority is D3D12 now that Vulkan support is available. Mantle support will not happen as the API is not planned to be publically available anymore.
How can I backup or restore my settings?
----------------------------------------
Everything RenderDoc relies upon is stored in %APPDATA%\RenderDoc. You can back up and restore this directory at will as nothing stored in there is machine specific aside from things like recent file lists.
Everything RenderDoc relies upon is stored in ``%APPDATA%\RenderDoc``. You can back up and restore this directory at will as nothing stored in there is machine specific aside from things like recent file lists.
Deleting this folder will also reset RenderDoc to the defaults - if you uninstall RenderDoc this folder will not be deleted.
@@ -66,50 +67,52 @@ RenderDoc doesn't install any registry keys aside from those to set up file asso
Which network ports does RenderDoc use?
---------------------------------------
RenderDoc uses TCP and UDP ports 38920-38927 consecutively for remote access and control (ie. capturing remotely) for each new program that is opened on a machine. Note that even if you initiate a capture locally these ports are still opened for listening. These are the ports that are probed on a remote host to see if a connection exists.
RenderDoc uses TCP and UDP ports ``38920``-``38927`` consecutively for remote access and control (ie. capturing remotely) for each new program that is opened on a machine. Note that even if you initiate a capture locally these ports are still opened for listening. These are the ports that are probed on a remote host to see if a connection exists.
RenderDoc also uses TCP and UDP ports 39920 for remote replay connections, for when a remote host is used to replay and analyse the log.
RenderDoc also uses TCP and UDP ports ``39920`` for remote replay connections, for when a remote host is used to replay and analyse the log.
Where can I get the source to RenderDoc?
----------------------------------------
RenderDoc is licensed under the MIT license and the source is available on github.com
RenderDoc is licensed under the MIT license and the source is available on `github <https://github.com/baldurk/renderdoc>`__.
What are the requirements for RenderDoc?
----------------------------------------
Currently RenderDoc expects Feature Level 11.0 hardware and above for D3D11. Lower levels will capture successfully, but on replay RenderDoc will fall back to WARP software emulation which will run quite slowly.
For OpenGL RenderDoc will only capture core profile applications, in general, and expects to be able to create a core 4.3 context which includes EXT_direct_state_access and ARB_buffer_storage. For more details see the OpenGL page.
For OpenGL RenderDoc will only capture core profile applications, in general, and expects to be able to create a core 4.3 context which includes ``EXT_direct_state_access`` and ``ARB_buffer_storage``. For more details see :doc:`../behind_scenes/opengl_support`.
With Vulkan RenderDoc should fully support any Vulkan application.
With Vulkan, RenderDoc should fully support any Vulkan application. However replaying a Vulkan log may not work if the hardware used to capture it is different - portability of captures between hardware is not guaranteed.
Why does my capture say "Failed to capture frame: Uncapped command list"?
At the moment RenderDoc only begins capturing deferred command lists at the point that you trigger a capture. If you replay command lists from before this, RenderDoc will fail to capture the frame and try again next frame (and eventually give up after a few retries).
At the moment on some APIs like D3D9, RenderDoc only begins capturing deferred command lists at the point that you trigger a capture. If you replay command lists that were recorded before the captured frame, RenderDoc will fail to capture the frame and try again next frame (and eventually give up after a few retries).
To change this behaviour, enable the Capture all cmd lists option - see that page for more details. This will capture all command lists from the start of the program, ready for when you decide to capture a frame. This currently has a fair overhead but it's something I want to improve in future
To change this behaviour, enable the ``Capture all cmd lists`` option - see :doc:`../window/capture_log_attach` for more details. This will capture all command lists recorded from the start of the program, ready for when you decide to capture a frame. This currently has a fair amount of overhead.
Why does my capture say "Failed to capture frame: Uncapped Map()/Unmap()"?
If you start a Map() before a Present() call then call Unmap() after the Present() during the frame RenderDoc wants to capture, RenderDoc won't have intercepted this call and so will fail to capture this frame and try again next time. This usually only invalidates the first frame you try to capture, but if you Map() many resources, and Unmap() them one by one in subsequent frames, you could hit this failed capture scenario many times in a row.
If you start a ``Map()`` before a ``Present()`` call then call ``Unmap()`` after the ``Present()`` during the frame RenderDoc wants to capture, RenderDoc won't have intercepted this call and so will fail to capture this frame and try again next time. This usually only invalidates the first frame you try to capture, but if you ``Map()`` many resources, and ``Unmap()`` them one by one in subsequent frames, you could hit this failed capture scenario many times in a row.
Currently the only solution to this is to change the pattern of Map()/Unmap() such that they are contained within a frame.
Currently the only solution to this is to change the pattern of ``Map()``/``Unmap()`` such that they are contained within a frame.
.._gamma-linear-display:
Gamma display of linear data, or "Why doesn't my texture look right?"
Gamma/SRGB correctness is a rather painful subject. If we could all just agree to store everything in 32bit float data we could probably do away with it. Until that time we have to worry about displaying textures while making sure to respect SRGB.
Gamma/sRGB correctness is a rather painful subject. If we could all just agree to store everything in 32bit float data we could probably do away with it. Until that time we have to worry about displaying textures while making sure to respect sRGB.
For texture formats that explicitly specify that they contain SRGB data this isn't a problem and everything works smoothly. Note that RenderDoc shows picked texel values in linear float format, so if you pick a pixel that is 0.5, 0.5, 0.5, the actual bytes might be stored as say 186, 186, 186.
For texture formats that explicitly specify that they contain sRGB data this isn't a problem and everything works smoothly. Note that RenderDoc shows picked texel values in linear float format, so if you pick a pixel that is 0.5, 0.5, 0.5, the actual bytes might be stored as say 186, 186, 186.
For other textures it's more difficult - for starters they may actually contain SRGB data but the correction is handled by shaders so there's no markup. Or indeed the app may not be gamma-correct so the data is SRGB but uncorrected. If we display these textures in a technically correct way, such that the data is not over or under gamma-corrected, the result often looks 'wrong' or unintuitively different from expected.
For other textures it's more difficult - for starters they may actually contain sRGB data but the correction is handled by shaders so there's no markup. Or indeed the app may not be gamma-correct so the data is sRGB but uncorrected. If we display these textures in a technically correct way, such that the data is not over or under gamma-corrected, the result often looks 'wrong' or unintuitively different from expected.
Nothing is actually wrong here except perhaps that when visualising linear data it is often more convenient to "overcorrect" such that the data is perceptually linear. A good example to use is a normal map: The classic deep blue of (127,127,255) flat normals is technically incorrect as everyone is used to visualising these textures in programs that display the data as if it were SRGB (which is the convention for normal images that do not represent vectors).
Nothing is actually wrong here except perhaps that when visualising linear data it is often more convenient to "overcorrect" such that the data is perceptually linear. A good example to use is a normal map: The classic deep blue of (127,127,255) flat normals is technically incorrect as everyone is used to visualising these textures in programs that display the data as if it were sRGB (which is the convention for normal images that do not represent vectors).
You can override this behaviour on any texture that isn't listed as explicitly SRGB with the gamma (γ) button - toggle this off and the overcorrection will be disabled.
You can override this behaviour on any texture that isn't listed as explicitly sRGB with the gamma (γ) button - toggle this off and the overcorrection will be disabled.
RenderDoc makes my bug go away! Or causes new artifacts that weren't there
@@ -120,18 +123,20 @@ During capture the main impact of having RenderDoc enabled is that timings will
The two primary causes of differences between the captured program and the replayed log (for better or for worse) are:
#.Map()s that use DISCARD are filled with a marker value, so any values that aren't written to the buffer will be different - in application you can get lucky and they can be previous values that were uploaded, but in replay they will be 0xCCCCCCCC.
#.``Map()``s that use DISCARD are filled with a marker value, so any values that aren't written to the buffer will be different - in application you can get lucky and they can be previous values that were uploaded, but in replay they will be ``0xCCCCCCCC``.
#. RenderDoc as an optimisation will not save or restore the contents of render targets at the start of the frame if it believes they will be entirely overwritten in the frame. This detection is typically accurate but means targets are cleared to black or full depth rather than accumulating, even if that accumulation is not intentional it may be the cause of the bug.
This behaviour can be overridden by enabling 'Save all initials' in the :doc:`capture options <../how/how_capture_log>`.
This behaviour can be overridden by enabling 'Save all initials' in the :doc:`capture options <../how/how_capture_log>`.
I can't launch my program for capture directly. Can I capture it anyway?
There is an option for capturing programs using RenderDoc where you can't easily set up a direct launch of the process.
More details can be found in the capture options page which details how to use it, however you should take care to read the warnings! This option isn't without its risks, so you need to be sure you know what you're doing before using it. It should always be used as a last resort when there is no other option.
More details can be found in the :ref:`capture options page <global-process-hook>` which details how to use it, however you should take care to read the warnings! The global process hooking option isn't without its risks, so you need to be sure you know what you're doing before using it. It should always be used as a last resort when there is no other option.
.._view-image-files:
I'd like to use RenderDoc's texture viewer for dds files, or other images. Can I?
Simply drag in an image file, or open it via file → open. RenderDoc will open the image if it is supported, and display it as if there were a log open with only one texture.
RenderDoc supports these formats: .dds, .hdr, .exr, .bmp, .jpg, .png, .tga, .gif, .psd. For dds files RenderDoc supports all DXGI formats, compressed formats, arrays and mips - all of which will display as expected.
RenderDoc supports these formats: ``.dds``, ``.hdr``, ``.exr``, ``.bmp``, ``.jpg``, ``.png``, ``.tga``, ``.gif``, ``.psd``. For ``.dds`` files RenderDoc supports all DXGI formats, compressed formats, arrays and mips - all of which will display as expected.
Any modifications to the image while open in RenderDoc will be refreshed in the viewer. However if the image metadata changes (dimension, format, etc) then this will likely cause artifacts.
Any modifications to the image while open in RenderDoc will be refreshed in the viewer. However if the image metadata changes (dimension, format, etc) then this will likely cause artifacts or incorrect rendering, and you'll have to re-open the image.
I think I might be overwriting Map() boundaries, can I check this?
Yes RenderDoc can be configured to insert a boundary marker at the end of the memory returned from a Map() call. If this marker gets overwritten during a captured frame then a message box will pop up alerting you, and clicking Yes will break into the program in the debugger so that you can investigate the callstack.
Yes RenderDoc can be configured to insert a boundary marker at the end of the memory returned from a ``Map()`` call. If this marker gets overwritten during a captured frame then a message box will pop up alerting you, and clicking Yes will break into the program in the debugger so that you can investigate the callstack.
To enable this behaviour, select the 'Verify Map() Writes' option when :doc:`capturing <../window/capture_log_attach>`.
To enable this behaviour, select the ``Verify Map() Writes`` option when :doc:`capturing <../window/capture_log_attach>`.
RenderDoc is complaining about my OpenGL app in the overlay - what gives?
The first thing to remember is that **RenderDoc only supports Core 3.2 and above OpenGL**. If your app is using features from before 3.2 it almost certainly won't work as most functionality is not supported. A couple of things like not creating a VAO (which are required in core profile) and luminance textures (which don't exist in core profile) are allowed, but none of the fixed function pipeline will work, etc etc.
If your app is not using the CreateContextAttribs API then RenderDoc will completely refuse to capture, and will display overlay text to this effect using the simplest fixed-function pipeline code, so it will run on any OpenGL app, even on a 1.4 context or similar.
If your app is not using the ``CreateContextAttribs`` API then RenderDoc will completely refuse to capture, and will display overlay text to this effect using the simplest fixed-function pipeline code, so it will run on any OpenGL app, even on a 1.4 context or similar.
If your app did use the CreateContextAttribs API, RenderDoc will allow you to capture, but compatibility profiles will have a warning displayed in the overlay - this is because you could easily use old functionality as it is all still available in the context.
If your app did use the ``CreateContextAttribs`` API, RenderDoc will allow you to capture, but compatibility profiles will have a warning displayed in the overlay - this is because you could easily use old functionality as it is all still available in the context.
Can I tell via the graphics APIs if RenderDoc is present at runtime?
Yes indeed. Some APIs offer ways to do this already - D3DPERF_GetStatus(), ID3DUserDefinedAnnotation::GetStatus() and ID3D11DeviceContext2::IsAnnotationEnabled().
Yes indeed. Some APIs offer ways to do this already - ``D3DPERF_GetStatus()``, ``ID3DUserDefinedAnnotation::GetStatus()`` and ``ID3D11DeviceContext2::IsAnnotationEnabled()``.
In addition to those:
Querying an ID3D11Device for UUID ``{A7AA6116-9C8D-4BBA-9083-B4D816B71B78}`` will return an IUnknown* and S_OK when RenderDoc is present.
Querying an ``ID3D11Device`` for UUID ``{A7AA6116-9C8D-4BBA-9083-B4D816B71B78}`` will return an ``IUnknown*`` and ``S_OK`` when RenderDoc is present.
`GL_EXT_debug_tool <https://renderdoc.org/debug_tool.txt>`_ is implemented on RenderDoc, which is an extension I've proposed for this purpose (identifying when and which tool is injected in your program). It allows you to query for the presence name and type of a debug tool that's currently hooked. At the time of writing only RenderDoc implements this as I've only just proposed the extension publicly, but in future you can use the queries described in that spec.
@@ -175,12 +180,12 @@ Querying an ID3D11Device for UUID ``{A7AA6116-9C8D-4BBA-9083-B4D816B71B78}`` wil
It's unlikely the extension will ever be 'made official', so these enumerants can be used:
..highlight:: c++
..code::c++
..highlight:: c++
..code::c++
#define GL_DEBUG_TOOL_EXT 0x6789
#define GL_DEBUG_TOOL_NAME_EXT 0x678A
#define GL_DEBUG_TOOL_PURPOSE_EXT 0x678B
#define GL_DEBUG_TOOL_EXT 0x6789
#define GL_DEBUG_TOOL_NAME_EXT 0x678A
#define GL_DEBUG_TOOL_PURPOSE_EXT 0x678B
A similar extension for Vulkan will be proposed after release.
@@ -189,7 +194,7 @@ A similar extension for Vulkan will be proposed after release.
My shaders have 'cbuffer0' and unnamed variables, how do I get proper debug info?
If you get textures that are just named 'texture0' and 'texture1' or constant/uniform buffers named 'cbuffer2' then this indicates that you have stripped optional reflection/debug information out of your shaders.
If you get textures that are just named ``texture0`` and ``texture1`` or constant/uniform buffers named ``cbuffer2`` then this indicates that you have stripped optional reflection/debug information out of your shaders.
This optional information is generated by the compiler, but is not required for API correctness so some codebases will strip the information out after processing it offline, and so it will not be available for RenderDoc to fetch.
@@ -108,11 +108,11 @@ As Vulkan is still in early support, some features are not yet supported. Featur
* Support for Vulkan 1.0 on Windows and Linux.
* Optional network support. The main use case is capture & replay on the same machine, but you can also attach over the network, and replay on a remote host.
* Event browsing, with debug marker extension based tree.
* Event browsing, with ``VK_EXT_debug_marker`` extension based tree.
* Full Vulkan Pipeline display.
* Resources are shown on the stage that references them, so each shader stage shows a list of the resources that it uses. Uniform buffers are separated out for clarity, but all other resources are listed together along with their descriptor set and binding point.
* Where available debug marker labelled names are displayed, along with reflection data from the SPIR-V to clarify usage.
* Where available ``VK_EXT_debug_marker`` labelled names are displayed, along with reflection data from the SPIR-V to clarify usage.
* SPIR-V disassembly display.
* Timeline bar of the scene hierarchy.
@@ -142,7 +142,7 @@ As Vulkan is still in early support, some features are not yet supported. Featur
* Simple per-drawcall timings.
* Python scripting console, giving access to some of the RenderDoc internals and core data structures.
Capturing on Linux is possible, although there is no native UI. The renderdoccmd program allows capturing on the command line, as well as opening a 'preview' window of the final frame of the framebuffer.
Capturing on Linux is possible, although there is no native UI. The ``renderdoccmd`` program allows capturing on the command line, as well as opening a 'preview' window of the final frame of the framebuffer.
RenderDoc has no runtime dependencies on Visual Studio or the DirectX or Windows SDK, and should run anywhere that a normal DirectX application will run - i.e. on Artist or QA machines.
Currently RenderDoc also assumes feature level 11+ hardware for the replay app. It can capture applications running at a lower feature level, but when replaying if 11+ hardware isn't available, RenderDoc will fall back to WARP software emulation and will run slowly.
* If capturing callstacks from the app, ensure that dbghelp.dll is not loaded or used by the application as this can easily interfere with RenderDoc's use and cause undefined or empty results. More information on this can be found in :doc:`../how/how_capture_callstack`.
* If capturing callstacks from the app, ensure that ``dbghelp.dll`` is not loaded or used by the application as this can easily interfere with RenderDoc's use and cause undefined or empty results. More information on this can be found in :doc:`../how/how_capture_callstack`.
* RenderDoc can have a significant memory overhead, especially when a lot of resources are allocated as shadow copies in main memory are created.
If running in 32bit, it's possible that an application can run out of memory - particularly when capturing, as this causes a significant spike in memory use. Improvements in memory management are planned but for now it's recommended to use 64bit, or to limit captures to simple scenes wherever possible.
This document serves as a brief introduction to how to use RenderDoc to capture and analyse your application. It doesn't go into much detail about exactly what functionality is available for digging into things, as this can be found elsewhere. Instead it focuses on just the workflow from start to finish and roughly where to look for different things.
For this tutorial we will be using a slightly modified version of the CascadedShadowMaps sample from the Microsoft DirectX SDK (June 2010).
For this tutorial we will be using a slightly modified version of the CascadedShadowMaps sample from the Microsoft DirectX SDK.
Capturing a log
---------------
@@ -21,9 +21,9 @@ More details of the specific options and their functionality can be found in the
..note::
It's best to choose the edition of RenderDoc to match your OS - 64-bit for Windows x64 and vice-versa
You should choose the edition of RenderDoc to match your OS - 64-bit for Windows x64 and vice-versa
You can only capture a 64-bit process with a 64-bit build of RenderDoc. A 32-bit process can be captured by any build of RenderDoc.
You can only capture a 64-bit process with a 64-bit build of RenderDoc. A 32-bit process can be captured by either build of RenderDoc.
RenderDoc in-app
----------------
@@ -67,7 +67,7 @@ There are various visualisation controls that allow you to select different chan
E.g. if you select render target 0 then the texture display will update to show the currently bound render target 0 regardless of which texture that is. If the slot you are following becomes unbound or unused, the previous texture will still be displayed up until you select a different pipeline slot, or the slot is bound again. Unbound texture slots show up with *Unbound* listed under their thumbnail.
To open a specific texture and watch it even as it changes slots or becomes unbound, you can open it in a new locked tab. Right click on the thumbnail and 'open in new locked tab', or :doc:`open it by name <../how/how_view_texture>`.
To open a specific texture and watch it even as it changes slots or becomes unbound, you can open it in a new locked tab. Double click on it, right click on it and 'open in new locked tab', or :doc:`open it by name <../how/how_view_texture>`.
* The format and dimensions of the texture are displayed on the status bar just below the texture display itself.
Also on this status bar you can see the current pixel co-ordinate that you are hovering over, as well as the 'picked' pixel value which can be inspected by right clicking anywhere on the texture display.
This page is a random hodge-podge of different tips and tricks that might not be obvious and aren't practical to make clear in the UI - e.g. keyboard shortcuts, edge cases and suchlike.
#. File associations for .rdc and .cap files can be set up in the installer or in the :doc:`../window/options_window`. These allow automatic opening of capture logs or capture settings files directly from files.
#. File associations for ``.rdc`` and ``.cap`` files can be set up in the installer or in the :doc:`../window/options_window`. These allow automatic opening of capture logs or capture settings files directly from files.
.. note::
These associations must be re-created if RenderDoc is moved to another folder.
.._view-image-files:
#. RenderDoc can be used as an image viewer! If you drag in or use file → open, you can open images in a variety of formats - .dds, .hdr, .exr, .bmp, .jpg, .png, .tga, .gif, .psd. The image will load up in RenderDoc's texture viewer and you can use the normal controls to view it as if it were a texture in a log. Note that dds files support all DXGI formats, compressed formats, arrays and mips - all of which will display as expected. If the file is modified, RenderDoc will reload it and display it. Note that changing the image's dimensions or format will likely cause problems.
#. If a .cap file is saved with the "auto-start" option enabled, launching RenderDoc by opening this file will cause RenderDoc to automatically trigger a capture with the given options. This is useful for saving a common path & set of options that you regularly re-run.
#. RenderDoc can be used as an image viewer! If you drag in or use file → open, you can open images in a variety of formats - ``.dds``, ``.hdr``, ``.exr``, ``.bmp``, ``.jpg``, ``.png``, ``.tga``, ``.gif``, ``.psd``. The image will load up in RenderDoc's texture viewer and you can use the normal controls to view it as if it were a texture in a log. Note that ``.dds`` files support all DXGI formats, compressed formats, arrays and mips - all of which will display as expected. If the file is modified, RenderDoc will reload it and display it. Note that changing the image's dimensions or format will likely cause problems.
#. If a ``.cap`` file is saved with the "auto-start" option enabled, launching RenderDoc by opening this file will cause RenderDoc to automatically trigger a capture with the given options. This is useful for saving a common path & set of options that you regularly re-run.
For more information check out the :doc:`../window/capture_log_attach` page.
#. If you'd like to see the geometry data with each component separated out and formatted, either open "Mesh Output" under the window menu, or click the Go Arrow |go_arrow| on the input layouts in the :doc:`../window/pipeline_state`.
#. Right clicking on one of the channel buttons in the texture viewer (R, G, B, A) will either select only that channel, or if it's already the only one selected it will select all of the others. This is useful e.g. to toggle between viewing RGB and alpha, or for looking at individual channels in a packed texture or render target.
#. Similarly, right-clicking on the 'auto-fit' button |wand| will auto-fit whenever the texture or event changes, so that the visible range is maintained as you move through the frame. This can be useful if jumping between places where the visible range is very different.
Note though that by default the range will be remembered or each texture, so once you have fitted the range once for each texture you should be able to flip back and forth more easily.
#. You can double click on a thumbnail in the texture viewer to open a :doc:`locked texture <../how/how_view_texture>` tab
#. You can close tabs by middle clicking on them.
#. You can trigger a capture from code. renderdoc.dll exports an :doc:`../in_application_api` for this purpose, defined in ``renderdoc_app.h`` in the distributions:
#. You can trigger a capture from code. ``renderdoc.dll`` exports an :doc:`../in_application_api` for this purpose, defined in ``renderdoc_app.h`` in the distributions:
..highlight:: c++
..code::c++
@@ -46,7 +45,7 @@ This page is a random hodge-podge of different tips and tricks that might not be
The next ``Swap()`` after this call will begin the captured frame, and the ``Swap()`` after that will end it (barring complications)
You can also use the RENDERDOC_StartFrameCapture and RENDERDOC_EndFrameCapture functions to precisely define the period to be captured. For more information look at the renderdoc_app.h header in the source code.
You can also use the ``RENDERDOC_StartFrameCapture()`` and ``RENDERDOC_EndFrameCapture()`` functions to precisely define the period to be captured. For more information look at the :doc:`../in_application_api` documentation or the ``renderdoc_app.h`` header.
#. When you have right clicked to select a pixel in the texture viewer, you can perform precise refinements with the arrow keys to nudge the selection in each direction.
#. To get API debug or error messages, enable "Create Debug Device" when capturing then check out the :doc:`../window/debug_messages` window.
@@ -65,12 +64,12 @@ This page is a random hodge-podge of different tips and tricks that might not be
// if GL_EXT_debug_tool is present (see https://renderdoc.org/debug_tool.txt)
glIsEnabled(GL_DEBUG_TOOL_EXT);
// Until enumerants are assigned (if that ever happens):
// Use reserved enumerants as the extension will not become official
#define GL_DEBUG_TOOL_EXT 0x6789
#define GL_DEBUG_TOOL_NAME_EXT 0x678A
#define GL_DEBUG_TOOL_PURPOSE_EXT 0x678B
#. RenderDoc can be informed about separated debug shader blobs through API specific ways:
#. RenderDoc can be informed about separated debug shader blobs through API specific ways - see :ref:`unstripped-shader-info` for more details:
..highlight:: c++
..code::c++
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
baldurk