RenderDebug and DebugView : A DLL Plugin and Viewer Application to perform Remote Debug Visualization on Windows

TLDR

How to quickly Run Bitcoin BlockChain Historical Data Visualization

TLDR; If you don't want to read this whole article and just want to download and run the visualization tool with the bitcoin blockchain historic data, here is what you should do. If you are a programmer and comfortable using SVN, then just sync to the SVN depot here:

renderdebug Google Code Project

A pre-built binary as a 7zip file is located here on my personal website:

renderdebug 7-zip binary.

You must have a Windows machine with a DirectX 11 compatible video card to run the tool.
Run the batch file 'show_bitcoin.bat' in the root directory.
The application uses Maya style navigation controls. You must hold down the Alt key first before the mouse will rotate and control the camera. Use the middle-mouse button to pan.
You can go the tab marked 'World' and turn off the checkbox to show the background grid which is on by default.
On the tab marked 'Debug Recording Playback' you have VCR style controls that will let you scrub through the data or single frame advance and rewind.
If you have problem running the tool, maybe because I forget some dependent DLL or something, let me know. mailto:jratcliffscarab@gmail.com
Here is a link to a YouTube video showing the distribution of bitcoin value on the blockchain throughout it's entire history. http://youtu.be/SbA913dLfYU
Here is a link to a YouTube video showing the distribution of non-zero balance bitcoin public key addresses over time. http://youtu.be/e074zH4vfWE
If you enjoy using the tool and appreciate the effort to produce all of this data, please be kind enough to send me a bitcoin tip. It's not so much that I need the money but rather that it's good feedback so I know this work is appreciated by the community.
Bitcoin Tip Address 1BT66EoaGySkbY9J6MugvQRhMMXDwPxPya

Here are some summary statistics current of as May 16, 2014. Please be cautious about trying to infer a great deal from associating public key addresses with individual people. So many of these belong to large exchanges and companies who are, in turn, managing many people's funds off-blockchain.

* Total Blocks: 301,044
* Total Transactions: 38,881,761
* Total Inputs: 89,839,209
* Total Outputs: 100,534,409

* Found 35,989,045 addresses which have ever been used.
* Found 33,074,177 addresses with a zero balance.
* Found 1,386,411 'dust' addresses (less than 1mbtc) with a total * balance of 171.26523 BTC
* Found 1,217,994 addresses with a balance greater than 1mbtc but less than 1btc, total balance 113,806 btc
* Found 199,264 addresses with a balance greater than 1btc but less than 10btc, total btc: 504,628
* Found 96,553 addresses with a balance greater than 10btc but less than 100btc, total: 3,461,562
* Found 13,128 addresses with a balance greater than 100btc but less than 1,000btc, total: 2,992,605
* Found 1,419 addresses with a balance greater than 1,000btc but less than 10,000btc, total: 3,157,431
* Found 98 addresses with a balance greater than 10,000btc but less than 100,000btc, total: 2,290,441
* Found 1 addresses with a balance greater than 100,000btc, total: 144,341

* Bitcoin value distribution based on age.
* Age Value Key Count
-----------------------------------------------------
* One Day : 248,585 BTC : 6,732
* One Week : 280,393 BTC : 9,355
* One Month : 677,688 BTC : 21,200
* 1-3 Months : 2,086,637 BTC : 49,382
* 3-6 Months : 2,779,152 BTC : 79,066
* Six Months to One Year : 1,755,184 BTC : 36,037
* One to Two Years : 1,721,166 BTC : 40,848
* Two to Three Years : 850,632 BTC : 28,523
* Three to Four Years : 895,958 BTC : 11,518
* Over Four Years : 1,449,591 BTC : 27,831

TipJar: 1BT66EoaGySkbY9J6MugvQRhMMXDwPxPya

--------------------------------------------------------------------------------------------

Introduction to the RenderDebug Debug Visualization Library

Have you ever been working on a command line or server application and desperately needed to display some debug visualization data but couldn't because you had no access to a graphics rendering library? Or, how about you were working in a large complex graphics application, like say a full game engine, but you just needed to be able to visualize something that might be happening in the physics engine and displaying that data in the main window was incredibly difficult to do?

RenderDebug is a library that I have kept around for a very long time. I can hardly remember when I wrote the initial version of it. I have released it as part of many of my open-source projects in the past, in various forms, but I don't think I have ever written it up before.

RenderDebug is a debug visualization API. It is not about doing high-end rendering, or anything complex. It's entire purpose in life is to display debug information like 3d text, boxes, spheres, rays, arrows, lines, triangles, and the like. It's a pretty clean and simple to use API. It uses 'const float' for all parameters passed in, so it does not enforce or require any particular math library.

Here is a link to the single header file needed to use the RenderDebug system. I will try to add some better documentation soon, it's a bit sparse for the moment.

The API is contained in a single header file with no other dependencies. Currently I am only providing an implementation as a plugin DLL for windows. It actually does compile for nearly every platform known to man, but I cannot provide full source at this time due to it having some dependencies on a shared multi-platform source library that I cannot release at this time. Perhaps, in the future, once the license status of the platform abstraction library becomes more clear, I will release the full source as well. However, at least on Windows, you can use the plugin fine without needing direct access to the source code.

For now what I am providing is the library as a plugin style DLL that can be demand loaded into any Windows application, console or otherwise, for both 32 and 64 bit. I may release a Linux shared-object file as well at some point in the future.

So, here are some of the things which make this debug visualization library unique and interesting.

RenderDebug Features

It provides a rich set of debug visualization primitives like lines, triangles, boxes, spheres, capsules, rays, arcs, frustum and matrix visualization.
It uses a 'const float' style API so it enforces no specific math library, though the layout of matrices, quaternions, and vectors passed in as const float should conform to a fairly standardized layout (OGL/D3D).
It can render things in wireframe, solid shaded, or both solid-shaded with a wireframe outline
It provides support for oriented 3d text
If your application provides a valid view and projection matrix, it can also do screen-space 3d hud style rendering and it can orient text and quads to the camera.
It uses a stack-based state system for simplicity and efficiency. For example, rather than having to pass the color into every single API call, instead you just set the current color and all draw commands after that are assumed to use this state. The state is maintained in a state-stack, so you can push the current state, change the color, display time, or other global state settings, do some draw commands, and then pop the state restoring everything back to it's original values.
It understands the concept of time! Many debug visualization libraries might offer you an API to, say, draw a line, however, they will usually only draw that line for one frame. With RenderDebug any debug visualization primitive has a 'life time'. Sure, you can draw a line for just one frame, but you can also draw a line and indicate it should stay on screen for 60 seconds. Why is this important? Because often when doing debug visualization you are trying to see a transient event. Maybe you want to visualize a raycast hit location event that happens discretely. If you only draw these kinds of contact events for one frame you will usually miss seeing them.
The RenderDebug library does not do any actual rendering itself. Instead it buffers up all of the debug visualization primitives to be streamed in a variety of different ways. Debug visualization can be streamed to a file, over a communications channel to another application, or it can provide raw geometry that you can submit to your own graphics engine.
The RenderDebug library also supports debug logging messages as well as remote commands if you are using it in client/server mode.
It also supports draw groups. This allows you to create a set of debug commands which get cached by id, so that you don't have to update them every single frame. Think of them like macros for draw commands. Using the setPose command you can render a draw group, multiple times, with different transforms.

Example Use Cases

Here are some example use cases where it makes a lot of sense to use the RenderDebug library

Your Own Graphics Application: Probably the most obvious use case, is to simply take advantage of it for general debug visualization in your own graphics application. If you have any graphics application of your own, but have not yet implemented a rich debug visualization library, then why not use RenderDebug? All you have to do is implement a single callback interface called 'RenderDebugInterface' and you can embed the entire rich debug visualization library directly into your own application. The RenderDebugInterface simply requires that you implement four methods. One to render lines, one to render triangles, one to log a debug message and, finally, one to process a command from a remote client.
A Server Application : One use case that is really powerful is for servers. Let's say you are working on a massively mutiplayer online game and you are implementing the server. While the server has to represent AI and players and world geometry, rarely do servers have any graphics front end. Servers are typically console applications with no way, other than some debug log messages, to have any idea what is happening inside. With the RenderDebug library you can use the front-end DebugView application to 'talk' to your server in real-time. You can send it commands and the server can make calls into the RenderDebug library to provide real-time debug visualization of it's internal state. I did exactly this when I was working on an MMO server years ago and it proved to be an incredibly powerful tool.
A Mesh Processing Tool : Let's say you are working on a mesh processing application, for example the convex decomposition tool that I have previously published. Rather than having to spend days creating a graphics application which can test the mesh processing tool and display the output, instead you can just easily add the RenderDebug library to your console mesh processing application and get a debug visualization of the output. You can even create multiple-frames of debug visualization data. For example with the HACD console application, on the first frame I debug visualize the original triangle mesh. On the second frame I debug visualize the convex decomposition, color coding each convex hull. Then, on the next frames I show each hull getting added to the result. On the final frames I create an 'exploded' view of the convex decomposition. You can see an example in this YouTube video link. https://www.youtube.com/watch?v=U6MRe36YKIk&feature=youtu.be
A Simulation Tool : If you are working on a physics or other kind of simulation project, for example it could be doing AI processing, you can perform all kinds of debug visualization of the internal state of your simulation without needing to drag in any graphics or rendering engines. This can make prototyping go much, much, faster.
General Statistical Analysis : Let's say you have a bunch of data that you are trying to analyze. Sure, you can export it as a CSV and import it into a spreadsheet application so that you can generate some graphs. In fact, that is what you should do. However, what if you want to see how a particular data set evolves over time? Or let's say that your data contains a great deal of visual information, like the kind that cannot easily be conveyed in a conventional graph? With the RenderDebug library you can implement your own way to visualize a data set, including evolving it over time. I did exactly this the other day. For those who follow this blog, they know by now that I have spent a lot of time doing analysis on the bitcoin blockchain. A lot of what interests me these days is forensic analysis on how the bitcoin blockchain has evolved over time. So, in part to test the RenderDebug library, I quickly revised my bitcoin blockchain parser tool to create a debug visualization bar graph of the distribution of bitcoin value by age and then created one frame for every single day in the history of bitcoin. The results were very cool and would be even cooler if I spent more time creating a better looking graph. Here is a link to the YouTube video which shows how the bitcoin blockchain value distribution has evolved over it's entire history. Here is the link. http://youtu.be/SbA913dLfYU

Future Work

One of the key features of the RenderDebug library is not yet implemented, which is the ability to do client/server communications in real-time. I am still working on that. I expect it to be done in the next week or so. It will use inter-process communication via a shared block of memory. In this mode you will be able to run your own project, say a game engine, and in real-time interact with the standalone DebugView visualization application. You will be able to not only send log messages and debug visualization data from your game engine to the viewer application, but you will also be able to send console commands between the two applications as well. In fact, you can actually use DebugView as your primary mechanism for debug visualization and console commands for your project if you want! For example, you could send a command from DebugView to your game engine to enable some particular debug visualization feature and essentially control the game engine remotely. In fact, I even plan to send mouse picking and drag events over the API too. This should allow me to develop fully interactive PhysX simulation demos using DebugView as a front-end tool to interact with the simulation.

For readers familiar with PVD, the PhysX Visual Debugger, you may see a lot of similarities here. Both DebugView and PVD tackle very similar problems. However, while PVD is focused exclusively to the task of visualizing what is happening inside the PhysX SDK, DegugView is a general purpose debug visualization viewer. It deals only in debug visualization draw commands, log messages, and command streams.

There are also some parallels here with the kinds of features offered by projects like Telemetry from Rad GameTools. Now, don't get me wrong, I am a huge, huge, fan of Telemetry and I highly recommend it to anyone who is concerned about performance analysis of their product. However, I would like to see a remote debug visualization feature like RenderDebug in Telemetry too, and I've talked to Brian about this in the past but it's never been a super high priority before.

I realize that it would be both useful and valuable for this system to also support inter-process communications via TCP/IP so that you could get remote debug visualization from console games or remote servers. Unfortunately, that feature won't be coming right away even though I have implemented it before in previous versions of the tool. My immediate short term need it to get remote-debug visualization from game engines I am running from the same machine I am on.

Future work on this project may include the following features, though there is a strong possibility I will not do all of them unless I have a specific reason to do so.

Add support for real-time interactive visualization on the same machine using a client/server relationship and inter-process communications via shared memory.
Add support for dynamic interaction, ray-picking, for example, so that it the DegugView application can be used to control a real-time ragdoll physics simulation.
Implement compression for the channel of debug visualization data to lower the bandwidth requirements
It might be interesting to make a way for scripting languages to talk to the RenderDebug API so that people who work in Perl or Python or any one of those other whizzy scripting languages could get remote debug visualization out of them. I don't use any of these scripting language myself, so I probably will not do this any time soon, though I can see some valuable uses connecting it to an embedded scripting language in a game engine.
Release the RenderDebug source code open-source and get a build that works using Shared-Object files on Linux
Release an simple open-source version of a DebugView application to demonstrate how to bind to a graphics layer fro rendering.
Implement a TCP/IP mechanism so that the DebugView application can connect to remote applications on other machines like a game console for example.

The DebugView Application

The DebugView application is what you use to play-back debug visualization recording files. Just launch it and pass as a command line argument the name of the recording file. Or you can use the 'File' menu to browse for a recorded debug visualization file. The DebugView application uses Maya style controls to navigate, so use the 'Alt' key in conjunction with the mouse to move the camera around.

It requires a Windows machine with a DirectX 11 capable graphics card. This is not because it needs some high-end graphics card for any particular reason, it's just that the render library I built the tool against is DX11 and I figure most anyone these days has a DX11 card by now anyway.

I have tested this application on a number of machines but there is still every chance it might fail to run on some machine configurations. If that happens, let me know and I will see if I can figure out what is going on.

Related Google Code Projects

Here are the projects that are relevant to this article:

RenderDebug: The main renderdebug Google Code project page. Contains the DLL plugin and two sample applications, ObjView which reads in a wavefront OBJ file and TestRenderDebug, which created an animated debug visualization. Here is a short YouTube video clip showing the visualization produced by TestRenderDebug: http://youtu.be/B__h--QGUXM
HACD: The hierarchical approximate convex decomposition app which now can build for Linux and also outputs a debug-render visualization of the results on Windows. Here is a YouTube video showing an example. https://www.youtube.com/watch?v=U6MRe36YKIk
blockchain : And finally the bitcoin blockchain parser which now has an option on the Windows version to generate a debug visualization output of the blockchain over time. Here is a link to a YouTube video showing the output. http://youtu.be/SbA913dLfYU

Untuk pemesanan, hubungi kami melalui kontak yang tersedia berikut:

Chat WhatsApp Send SMS Call