okmatija / prizm

A Computational Geometry Debugging Tool

Prizm

Prizm is a tool for debugging computational geometry algorithms using a simple workflow:

1. Write debug files using the OBJ format
2. Inspect the files to find bugs

See the wiki for video tutorials. There is also a Discord server.

There are many tools which can be used to implement this two-step debugging workflow (e.g., MeshLab, Polyscope, ParaView, Meshmixer, Graphite, VisIt). Prizm differs from these tools in the following ways:

• Narrower scope. The tools listed above have modelling features, geometry processing features, or are platforms for developing geometry processing algorithms. Prizm on the other hand is exclusively focused on the workflow outlined above, which means that it ships with only a small number of geometry processing features, the ones that have directly helped with debugging. Furthermore, Prizm is not intended to be in development forever, once the issues for the Version 1.0.0 milestone are addressed the program will stabilize and recieve only bug fix changes, to be maximally effective while debugging becoming familiar with your tools and being able to rely on them not changing much is helpful.

• Simpler/faster UI/UX. This is of course a very subjective, but nevertheless the narrow scope of Prizm means that all the effort/iteration around improving UI/UX is necessarily focussed on the singular debugging use case. This focus has (hopefully) resulted in a tool which enables users to identify and fix problems very quickly. Prizm and its predecessors have been used for many years to debug problems arising in different domains and its feature set has evolved through direct experience. It should be useful when inspecting a single file or in cases where you need to sift through/transform a large set of files to identify a problem.

• Simpler to extend. It is common for other tools to be written in C++ and scriptable at runtime using Python. The binding code to implement this interoperation complicates the program making it harder to understand/change/extend. Prizm is implemented using Jai, a new systems programming language with powerful metaprogramming features and very fast compile times. Taken together these features enable 'scripting' to be conveniently implemented via regular functions tagged with a @RegisterCommand note which the build program can inspect to generate the boiler plate code so that the function can be called in the console*.

• Stand-alone. Some tools can directly embedded in your C++ program, and programmers familiar with graphics APIs can of course write their own visualization code for debugging directly in the original program. This can be very helpful because you can inspect data as you step through your program. Prizm is intentionally not a library and cannot be directly embedded in other programs, it is intended to be useful in any situtation where you might be developing geometry code, regardless of framework or language etc. We have attempted to mitigate the downsides of having a stand-alone tool by implementing features which aim to support the same convenience**

* Implementing hot code reloading is a high priority feature and should make Prizm's scripting workflow quite similar to the runtime scripting features available in other tools because you will be able to add console commands without restarting Prizm. Also, as of March 2024, Jai is in closed beta which means that for most people Prizm will only be useful in binary form. When the compiler is publically released people familiar with C++ should find Jai very easy to pick up.

** For example hot-reloading files/folders and supporting "always on top" transparent windows, see the wiki for more details. Implementing a feature where your program can exchange data with Prizm via a shared memory channel/socket is a high priority feature.

prizm's Issues

Add a perspective camera

Enable toggling of window topmost state at runtime

Currently the Prizm window can only be set to topmost if the --AlwaysOnTop is passed on startup. If we update to SDL2 version >= 2.0.16 then it will be possible to toggle this state at runtime, we could also consider implementing this outside SDL but we're using quite an old version so updating might be good anyway...

Add GIFs to demo the features listed in the wiki

MacOS platform support

Add ability to send data between processes

Support the following use cases:

Application --> Local Prizm (as an alternative to using file hot-reloading)
Local Prizm --> Remote Prizm (useful for pair programming debug sessions or screenshares)

This could be implemented via TCP sockets?

Audit internal data-structures and memory management, these should be super clear/simple

Users should be able to quickly understand the data-structures they may want to manipulate when writing console commands

Add a configuration file so users can change Prizm's default settings

Refactor the rendering architecture

It should be easy to implement depth peeling, screen space ambient occlusions (SSAO) and shadow mapping

Support asynchronous file loading

Add a tips/tricks system to help users discover Prizm features

Automate the release process

Do this in the metaprogram first.jai

Add alternative coordinate systems choices (e.g., left/right handed, y/z up)

Linux platform support

Parse texture vertex information (vt-directives)

Currently these are ignored but it would be useful to parse and display them

Implement hot code reloading so that the Prizm application can be modified while its running

Alternatively implement a way to save/load program state? This option would help for cases when we want to revisit a debugging session much later on... Probably we want both of these things, but hot code reloading seems more important.

Add a Python obj authoring API

This should be similar to the current C++ one (which should perhaps be reworked to call into an even simpler C API)