cannontwo / cannon Goto Github PK
View Code? Open in Web Editor NEWLifetime repository
Home Page: https://cannontwo.com/cannon/
License: MIT License
Lifetime repository
Home Page: https://cannontwo.com/cannon/
License: MIT License
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 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
.
cannon/cannon/log/registry.hpp
Line 33 in e1202df
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.
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.