Tasks & Projects

[kaveh808]

Over the next little while, I am going to revamp major portions of the software. Things I have been putting off while we waited for the Linux port and SBCL.

In the meantime, we can start thinking about what people would like to work on. I'm posting a catch–all list here of stuff that's been sitting in my notes. If any of them seem interesting to you, or if you have ideas of what you would like to do, please let me know. This list is just a starting point to begin discussions. I have marked with (K) the things I am working on.

Also please check this discussion about workflow: #37

• optimized 3d math (K)
• cubic parametric curves -- bezier curve example has been implemented, need other curves
• implement poly-mesh class -- the class has been implemented, need topological operations for mesh editing
• cubic parametric surfaces -- spline patches
• trimmed NURBS -- useful for CAD software
• subdivision surfaces -- based off poly-mesh, with edge sharpness weighting
• csg -- for CAD
• signed distance functions -- implicit rendering of mathematical functions
• isosurfaces -- for metaballs style modeling and data visualization
• update transform class (K)
• angle-axis transform class (K)
• generalized transform class (K)
• group parent/unparent (K)
• genetic algorithms -- general approach to very the parameters of any system
• genetic programming -- use genetic techniques to generate code for a system
• 3d ui manipulators -- interactive controls for transforming shapes
• 3d ui picking -- ability to pick shapes, faces, edges, and vertices in the 3D view
• gui toolkit -- cross platform UI system built on a graphics engine
• gui text engine -- ability to display scaled and styled text
• computed-slots -- data flow management between objects
• persistent objects -- ability to store and load scene data
• rigid body dynamics -- possibly wrapper around existing C package
• soft body dynamics -- possibly wrapper around existing C package
• fluid simulation -- possibly wrapper around existing C package
• behaviors -- shapes with a state machine
• protocols -- generic interface mechanism for procedural asset creation
• deformers -- bend/twist/taper, FFD lattices, etc
• deformable-mesh -- adaptively subdividable mesh for deformation
• character animation: skeleton rigging
• character animation: muscles system
• character animation: skinning
• character animation: facial animation
• character animation: hair and fur
• character animation: clothing
• I/o: obj
• I/o: usd
• dsl for modeling
• animation: timeline
• animation: playback controls
• animation: sequencer
• animation: dsl for blocking/choreography
• gui design: customizable extensible inspectors (aspects)
• gui generates code
• particles: build on existing system
• l-systems: build on existing system
• manager-groups: variants
• manager-groups: LOD
• manager-groups: blend shapes
• scene i/o
• visual programming
• code visualization
• batch engine (no ui)
• gpu & simd code
• collaboration features
• standalone app
• layered gestural animation
• purely key-driven ui
• gui for editing code
• emergent structures
• adaptive ui
• grid view for genetic evolution
• generate geometric styles
• web features
• web graphics output
• data visualization
• mathematical visualization

[grapesmoker]

As I said in the intro thread, I have some geometry code lying around here: https://github.com/grapesmoker/cl-geom. It's got some stuff for quaternion operations as well as points, vectors, lines, and polygons. I will not claim that it's any great shakes, but if any of it is useful, please feel free to copy it directly.

[kaveh808]

For points and matrices, both your code and mine are based on CLOS. I want a more efficient representation.

Please have a look at: #23

[grapesmoker]

Very interesting, thanks for the link.

[kaveh808]

You may have noticed that I have left rendering off of this list. That's quite a large project and it's own right.

We could develop our own renderer, or link to an existing one.

If it's something you're interested in, let's talk.

[JMC-design]

So is protocols separate from DSL. Like protocols to enquire about shapes to make the DSL part easier? Like referencing shapes by name or id(perhaps autogenerated?).
While fooling around doing this https://imgur.com/gallery/YvPt3RK i became painfully aware there's no easy way to specify a path. Perhaps that should be a separate DSL from modeling? I wonder if I can extend my 2d path building stuff to 3d.

[kaveh808]

Protocols advertise a service. For now we have point-source and curve-source. Modeling tools (e.g. sweep shapes, particles) use these services for their profiles, paths, spawn points, etc.

A DSL is a way of creating procedural content rapidly and conveniently. So I can see a DSL using protocols, yes.

I have been working on shape query by name and scene-path (hierarchy).

We do have a polygon class. By path do you mean a multi-section outline like you used for the "A"?

[JMC-design]

yes, with an easy way to specify it. like

(new-path
  (move p1)
  (rline p2)
  (rcubic-bezier p3 p4 p5))

or maybe with keywords so it'd be easy to dump from the gui, person hotkeys line clicks a point on screen and (:line p) gets pushed to the path. End result some shape popping out.
Not necessarily a closed shape either if you're doing something like a camera path.

[kaveh808]

How about this?

(defclass poly-path (polygon) ...) contains a list of segments, which can be lines, cubic curves, circular arcs, etc.

Method compute-path-points stores the points in the polygon's points array for drawing.

(defclass multi-path (shape) ...) contains a list of poly-paths, for encodings fonts and such.

These would be the scene classes. We could have some DSL which generates the data.