baldurk
commented
7 years ago Phew, that's a pretty beefy feature! Like you say though, it would be useful in a number of situations.
There are a number of difficulties involved in implementing this which I won't go into the details of, but right now this kind of feature wouldn't be practical with the current way serialisation and replay happens. However as I mentioned in the v0.32 release notes I've been working on a revamped serialisation system, which will solve a bunch of those roadblocks.
One of the proof-of-concept things I've done is made it possible to export a .rdc to an xml+zip bundle. The xml file with all the API calls, and all the large buffers as binary files in the zip. You can then go the other way and recompose it into a loadable .rdc. This would allow easy manual or third party tooling to edit logs to change, remove or even add (if you know what you're doing!) API calls. The iteration time wouldn't be great so this isn't a replacement for in-program state/API editing, but it's exactly the kind of place where a feature like this would fit.
The remaining trick would be fixing up the initial states to contain data from part-way through the original capture. This would require more work on the part of the tool and probably some use of the renderdoc replay API, but you could basically run a batch mode to do 'jump to the starting event, dump all mips of all textures in native format, dump all buffers' etc. Then you have the data you need to replace in the xml+zip bundle, for anything that's changed.
So medium to long term this is totally doable, although it's likely that I will expose the building blocks someone would need to create the feature before I'd get around to doing it myself - and likewise I think this is maybe something that is better to implement on top of basic building blocks.
sebbbi
I would like a new feature that allows me to extract part of the RenderDoc capture log (range of events from A to B) and save it as a new smaller capture log.
This would be highly valuable feature when sending bug reports to third parties (driver bugs to IHVs, engine bugs to Unreal/Unity/etc, RenderDoc bugs, etc). It would both help in avoiding sending confidential information (captures from unannounced game IP) to third parties and would make the capture significantly smaller (easier to send off-site). This feature would also allow easy construction of minimal case bug repro cases.
It would be important that the partial capture removes all references (names, initial data, etc) of resources that are not referenced in the selected range of events. Initial data of the remaining resources would need to match the state of the resources at the point of the first event in the selected range.