cannontwo / cannon Goto Github PK

Should at least control font size, axis width, point size, point color, line color, perhaps on a per-plot basis (i.e. add write_imgui functions to Scatter and Line classes, have ImGui menu like Geometry menu in Viewer3D)

See the end of https://learnopengl.com/Advanced-Lighting/Deferred-Shading. This technique will allow for rendering large numbers of lights, at the expense of introducing additional geometry calls.

A new Table class should be created in the log subdirectory that presents an interface for printing table-formatted output.

It might have a method for adding columns, rows, setting colors of entries.

This is necessary for completion of #4. See here.

This is a basic component of PARL, and should be directly portable from the Python implementation.

This will likely involve a ScatterPlot class with a vector of points represented as Vector2f objects. The ScatterPlot object will be responsible for drawing the points in a particular color. The major thing to be resolved is how the Plotter will keep track of multiple kinds of plotted elements.

CGAL provides a KDTree implementation, but I will need to wrap it in a friendly interface for use with PARL.

See http://assimp.sourceforge.net/lib_html/materials.html. This behavior should go in Model::process_mesh.

Screenshot functionality is already implemented, and video recording can be done by saving a picture on each frame to a dedicated folder, then calling ffmpeg when a stop button is pressed.

For a simple depth effect, implement shadow mapping for the assumed single directional light in deferred_lighting.frag

This should make use of the Euler integration implemented in #16.

This class will contain the behavior previously in parl/run_from_config.py, taking a config filename and specification of the environment to run.

This will involve adding a class Line with essentially the same interface as Scatter and a function plot_line to Plotter.

This is a basic physics simulation technique, but it's also a necessary component of testing PARL.

This will bring it closer to print behavior in Python, and make my life a bit easier.

The new version should be called as log(foo, bar) and print foo bar.

This will require implementing a reload method on ShaderProgram that takes a path. It should be wired to ImGui to allow for interactive reloading during execution.

As part of this, Viewer3D should keep track of the programs used by geometry so that (a) LightCollection can update lighting more efficiently, and (b) hot swapping a program has predictable effects. That is to say, the hot swapping ImGui code should be written by Viewer3D using its knowledge of the shaders in the scene.

Some sort of encapsulation of arbitrary 2D scale is needed in the plotting library. This could look like an Axes object which holds the extent (max and min x and y) of the objects currently registered with a Plotter. Each Plotter has a single Axes object. This object's draw() method is invoked at the very end of the render loop, and should display a numbered x and y axis.

The VertexBuffer::buffer() methods should take a parameter specifying whether the buffer should be static or dynamic.

They also need to be refactored to remove duplicated code.

The C++ inverted pendulum implementation can't be tested in code for equivalency with the Python version, but this should be manually confirmed by writing a script and testing on a set of given start states.

Something like the OMPL notion of a state space should be created to represent the dimensionality and bounds of the state and action spaces that PARL uses.

An SDF Volume will be drawn as a rectangular prism for forward rendering. The SDF to be drawn should be defined on [0, 1]^3, and rays cast from the camera into the volume will be transformed to [0, 1]^3 in the coordinate space of the SDF volume (scaling, translation, and rotation based on box model matrix and axes). For a first implementation, the SDF Volume will just be a cube.

Actual SDF rendering happens in an additional geometry pass before the light geometry pass, during which only SDF geometry is rendered. Position, AlbedoSpec, and Normal information is written into the GBuffer.

Note that the SDF information to be displayed has to be contained in the fragment shader applied during this additional pass. #51 will allow that definition to be separate from the sphere marching code and combined at compile time.

This should make use of CGAL's Voronoi Diagram generating functionality, and will probably be easiest to implement by adding the ability to draw polygons to Plotter first.

This is a more rational camera model for navigating a 3D scene than the fly camera currently implemented. See https://docs.blender.org/manual/en/latest/editors/3dview/navigate/navigation.html for inspiration.

See

• http://developer.download.nvidia.com/assets/gamedev/files/sdk/11/FXAA_WhitePaper.pdf
• https://github.com/PixelLightFoundation/pixellight/blob/master/Plugins/PLCompositing/src/Shaders/PostProcessing/FxaaShader.h
• https://catlikecoding.com/unity/tutorials/advanced-rendering/fxaa/

This should be easy to do given the way that meshes are loaded. At the very least, each mesh should apply its parent mesh's transformation before its own, and the top-level meshes treat the containing Model as a parent. This will allow for future extensions such as rigging and transformation tree animation.

Put together all PARL components into the overarching algorithm and replicate results on inverted pendulum.

This will enable multiple lighting passes and also take the graphics system closer to being standardized on physical units.

This probably looks like developing a physically inspired Spectrum that each kind of light accepts and which defines light intensity for each color channel.

This is a basic component of PARL (accelerated SGD), and should be portable from the Python implementation.

This is a basic component of PARL and should be portable from the Python implementation.

Just as in the Python version, Runner should write out episode rewards and test rewards to csv files that can be read in the same way to plot training progress.

This should support the notion of rendering to a series of framebuffers, possibly using the results of framebuffers earlier in the pipeline to render to framebuffers later in the pipeline. Each of these stages should also be able to access scene geometry if necessary.

The two target applications for this feature are applying stacked postprocessing effects in screen space and doing deferred lighting/shading.

Implement the DPLL algorithm, with space for two visitors: a UnitClauseHeuristic functor which scores unit clauses to simplify and a SplittingRuleHeuristic functor which scores propositions to assign values to during the splitting rule phase. The algorithm state should be stored in a DPLL object which maintains a stack of partial truth assignments to be "recursively" processed, as well as the input formula object. This DPLL object will also be responsible for storing the two visitors mentioned previously.

The implementation should run iteratively, maintaining a stack of pairs consisting of a truth assignment valarray and "simplified" boolean valarray, which will indicate for each clause in the formula if it should be evaluated for the truth assignment at any iteration. Note that this implementation of DPLL will "simplify" formulas by annotating clauses that should be skipped, and not by actually modifying the data structure representing the formula being evaluated. In this way the memory and time used to simplify is simply the cost of copying a boolean valarray.

This should be done in much the same way that the ImGui spawn model functionality works in test_3d_viewer.cpp; it will need to make use of glfwSetDropCallback and glfwSetWindowUserPointer/glfwGetWindowUserPointer.

Add a Dockerfile which installs the dependencies for this repository and builds it in Ubuntu 18.04.

This should have an interface like rich.progress

This is a basic component of PARL, and should be directly translatable from the Python implementation.

For programmatically defined textures (diffuse materials not sampled from a file), it should be possible to find some physical characterization which produces the same effects currently being simulated by the ambient, diffuse, and specular fields.

Once 3DViewer is implemented, as well as rendering of arbitrary geometry, a method start_rendering should be added to the InvertedPendulum class that spins up another thread which renders the current inverted pendulum state via OpenGL.

The RLSFilter class is already mostly set up to handle arbitrary feature transformations. The class should be templated with a feature transformation function type, and an argument of that type stored and called in the make_feature_vec() function. This will allow arbitrary nonlinear features to be provided to the RLS filter.

The function passed as a feature transformation must return a RowVectorXd.

See https://learnopengl.com/Advanced-OpenGL/Instancing. Delaying this for now as there isn't any need for it yet, but drawing instanced geometry will likely require a slightly different control flow.

Drawing a particle system could be a motivating application of this rendering technique.

See https://learnopengl.com/Advanced-Lighting/Parallax-Mapping and https://learnopengl.com/Advanced-Lighting/Parallax-Mapping. With the deferred rendering pipeline already implemented, this is as simple as adjusting the normals and texture coordinates that get stored in the GBuffer.

However, I have no real need to implement this right now, so I'm putting it off.

Encapsulate color printing to loggers that are colorable in a class which handles outputting the appropriate commands.

See https://learnopengl.com/Advanced-Lighting/Deferred-Shading

Really just an editable triangulated plane, perhaps with initialization from some sort of planar noise.

Various 3D brushes are common, and can be seen as manipulating an array of vertices. See https://docs.unity3d.com/2019.3/Documentation/Manual/terrain-Tools.html for inspiration.

Basic version would use a hardcoded terrain resolution, but the fancy way to implement this would be to use a KDTree and dynamically generate new vertices based on the resolution necessary to make local changes using the brushes implemented. With a smoothness assumption, this can be done in a relatively principled way using a maximum allowable height differential between adjacent vertices and adding new vertices when it is violated.

This should probably be a template class specialized for 2D and 3D―which CGAL provides explicit methods for―and for arbitrary dimensions will need to handle computing a Voronoi Diagram by lifting a Delaunay Triangulating and computing its convex hull. This is also related to #25 and may be a dependency for it.

Essentially, the VertexShader and FragmentShader classes should have a constructor which takes multiple filenames or multiple strings containing shader code and combine them into a single shader.

Note that only one of the strings/files to be combined should include a main function, as otherwise compilation will fail.

See scripts/draw_triangles.cpp. There are ordering constraints between creation and binding of VertexArrayObject and VertexBuffer that should be properly encapsulated, along with calls to glVertexAttribPointer and glEnableVertexAttribArray.

This could be done by, for example, creating a VertexArrayObject data member in VertexBuffer—but only if that explicit association is necessary. The VertexArrayObject could be required in the constructor, even if nothing in the VertexBuffer needs to call on the VertexArrayObject explicitly, simply to enforce the ordering constraint.

This is another type of DrawableGeom that should be supported by 3DViewer, and becomes especially important once shadow casting is implemented.

VertexBuffer should do something similar to std::vector when asked to buffer data to the GPU so that we avoid constantly reallocating when dynamically plotting points. That is, it should ask for exponentially increasing sizes of buffer, and then manage actual data using glBufferSubData. Draw calls will be responsible for requesting only actually initialized memory, which means that VertexBuffer should keep track of the amount of space reserved on the GPU and the amount actually being used.

This is a basic machine learning technique and will be useful in a variety of contexts. Gives context to implementation of ADAM which is necessary for PARL.