Skip to content
This repository has been archived by the owner on Jul 18, 2023. It is now read-only.

Trash. Agenda

Jump to bottom
Cyrille Rossant edited this page Feb 26, 2014 · 1 revision

To more or less structure our discussions

Current phase: oogl layer is converging, work on visuals layer is starting

Priority

These layers should be handled in priority (by decreasing order):

  • review oogl layer implementation + testing
  • low-level visuals
  • shader chaining
  • high-level visuals

Also: building a unit testing framework for the low-level layers.

Topics to discuss and work at during EuroScipy

(more or less in order of importance)

  • [AK] Scope:
    • Should vispy be pure Python? Yes, at least for the beginning. Maybe later: Cython, ctypes, cffi or Numba for tesselation, transparency, etc.
    • We need a way to draw lots of primitives in a single GL call. glMultiDrawArrays is not part of ES, so we need something else.
      • Multiple lines: GL_LINES + index buffer and we're fine: no copy during backing.
      • Multiple lines: GL_LINES + double the number of points (+ extra point at the end of every line?)
      • (Multiple lines: two GL_LINES calls without index buffer (+ extra point)?)
      • For GL_LINE_STRIP, maybe a "discard" in the fragment shader, with a varying variable specifying whether we are between two primitives (no integer). Or alpha between primitives.
      • For GL_TRIANGLE_STRIP, use degenerate triangles between primitives.
      • With tick lines (GL_TRIANGLES and index buffer), no problem.
      • TODO: some experiments with that in Vispy.oogl
    • Integration with our respective toolkits
    • -> Or focus on the visuals layer and beyond?
    • Vispy: real toolkit in the future all-in-one (as soon as visuals layer is ready)
  • OOGL layer:
    • [CR] How to write unit tests for the OOGL layer?
      • Nicolas started, no need for gl context except for visualization see skimage
    • [AK] Review / cleanup
      • TODO
    • [AK] Work on remaining tasks
      • some remaining tasks in OOGL
      • also for web backend
      • not priority
    • [AK] Collection class
      • visuals layer: baking + OpenGL tricks (see above)
    • [AK] Fix incompatibilities of OpenGL vs ES 2.0
      • put #version automatically
      • automatically do some glEnable to make like the user is using ES
      • see wiki page extensions, try to do most of the stuff automatically + documentation
      • let the user use stuff not in ES (geometry shader), maybe separate namespace with non-ES stuff, or just documentation if not much stuff
      • add in the wiki the important features in OpenGL 3/4 not at all in ES 2.0 (geometry shaders)
  • [NR] Code review and good practice
    • style guide
  • [NR] Start organizing examples/data/etc
    • already started: resources ==> data
    • aleady github.com/vispy/experimental
    • how to organize the examples?
      • OOGL examples separate with Visuals examples, etc.
      • examples/oogl/, ...?
  • [AK] Website, docs, examples, domain names: where to put and host
  • [NR] Many questions around corner cases for shader/VBO
    • sanitize type: throw exception if attribute does not match VBO (e.g. there should be no possibility to upload array of vec2 if attribute is vec3, and so on)
    • document VertexBuffer(...)
    • default ndarray to VBO simply with what we have in nicolas code
    • ClientArray = inefficient way without VBO
    • document that * = VBO(array) is better than = array
  • [AK] Visuals layer (not imported by default, notably in the early versions)
    • Priority:
      • Lines
      • Grid
      • Marker
      • General collections
    • Text
    • Mesh
    • 2D Image
    • Volume
    • Bézier curve
    • NURBS?
  • Data transformation
    • We need to design a flexible and clean API to deal with arbitrary transformations between the CPU and GPU
    • it should come right above the low level visuals layer
    • should also be done in the shader
    • normalization of the data like "pixel transfer": scale and bias
    • world wind jitter problem: loss of precision with 32-bit floating points at high values ==> need to normalize the data on the CPU (64 bit) before converting in 32 bit.
    • look transfo tutorial on matplotlib
  • [NR] High-level API "a la matplotlib" (compatible ?)
    • later, once we have made some experiments on low-level visuals
    • see scenegraph later
  • [AK] Shader chaining/templating
    • Luke started this
  • [AK] vispy and skimage (skimage people also have a sprint):
    • LATER
    • Data types for pointset, aarray, mesh?
    • What would be needed to make Vispy a visalization tool for skimage?
  • [CR] What would be needed to make Vispy a backend for matplotlib?
    • lowest level in MPL: draw a text, a line, a polygon, linecollection
    • use the scene graph from MPL and write a VisPy plot from that?
  • [AK] How can we make use of ANGLE (on Windows)?
    • generate ctypes code from GLES header, use ANGLE
  • [AK] How can we move towards a browser backend?
      1. Batch all GL commands and send them to Javascript at the end of initGL and paintGL. Need to specify the variable dependency between output of GL commands and inputs of following commands.
      1. Communication at each GL command, blocking when an output is required.
      1. OOGL.JS, exact same API than Python, Python-JS communication at a higher level than raw OpenGL.
    • Do some experiments with 1 and 2.

List of topics to discuss over time

Here's a lot of topics to discuss (more or less in order). Please add topics to this list (please put your initials in front).

After we have reached some form of agreement on a certain topic, the summary (decision+motivation) should be written down in the wiki for reference.

  • LC: Library architecture. The library consists of several sub-components in hierarchical layers:

    • Low-level object-oriented GL wrapper. Provides classes for textures, VBO, shaders, uniforms, etc.
    • Mathematics library -- vector/matrix math, mesh geometry, etc. (possibly provided by Pyrr)
    • Visuals library -- primitive visual components (plot lines, scatter plots, 3D meshes, volumes, etc) built on #1 and #2). Each visual defines methods of rendering to OpenGL, SVG, WebGL, etc.
    • Scenegraph
    • Functional interface

  • AK: hierarchy of the visual class

  • AK: cameras and viewports (view_box)

  • AK: shaders (and making them flexible) see: [https://groups.google.com/d/msg/pyvis3d/brtjFa2fWIA/S0WNO_wd2QEJ Shader system design]

  • AK: full screen aa vs per object aa.

    • Both options available.
    • 2D plotting should use nice per-object AGG by default
    • For better performance / smaller memory footprint, AGG can be disabled
    • For scenes with transparency or where depth is important, FSAA could be the default, at least until something better is available (depth peeling, pre-sorting..)

  • AK: render engine (transparency and all that)

  • LC: coordinate systems (re: [https://groups.google.com/d/msg/pyvis3d/ji-EmUpyuDY/pMHumhNiAyIJ this discussion])

  • LC: Style conventions

    • Follow PEP 8 recommendations
    • Documentation in Sphinx
    • Prefer properties/attributes over get/set style methods

Who works on what

  • [AK] scenegraph, cameras, oogl++
  • [LC] visuals, scenegraph, stylesheets
  • [NR]
  • [CR] unit tests, code quality, examples, web backend
Clone this wiki locally