# Object Geometry Evaluation

## Goals

* Allow the geometry type of an object to change during evaluation.
* Allow an object to have geometry of different types at the same time.
* Allow storing instancing information inside the geometry instead of on objects.

## Current State

Each object has a fixed type, such as mesh, curve or volume. During depsgraph evaluation, modifiers can change the data of an object, but its type has to stay the same. For example, a modifier that takes a mesh as input has to output a mesh as well.

Instancing information is stored on the object instead of on the geometry. Two ways to instance objects are to use particle systems or to set the `parent` and change the `instance_type`.

## Geometry Type Proposal

Object types for original data in DNA are still very useful, because we have different edit modes for different geometry types. However, as soon as we go from original data to evaluated data, having different object types seems unnecessary and limiting.

The proposed solution is to have a generic runtime-only `GeometrySet` type. This type references zero or more `GeometryComponent` instances. `GeometryComponent` is a base class and has to be implemented for specific geometry types. For example, there can be `MeshComponent` and `VolumeComponent`. A `MeshComponent` does not have to be a new mesh data structure, it could just contain a `Mesh *` or `BMesh *` or both.

When `BKE_object_eval_uber_data` evaluates an object, the original data is wrapped by a new `GeometrySet` instance. All modifiers are unified in that they take a geometry set as input and output a new/modified geometry set. After evaluation, the final geomeset set is stored in `Object_Runtime`. So essentially, instead of having `ID *data_eval`, we would have `GeometrySet *data_eval`.

For rendering, objects can be generated from the geometry components on the fly.

### Potential Problems

* Display information stored on original data blocks might be lost or is meaningless, because the type as changed. There are two main solutions:
1. Move the display information for all types to the Object. This way the user can edit the display settings for the final geometry type on a per object basis.
2. Embed the display information within the geometry components. This allows the user to edit display settings using modifiers and nodes.
* Applying modifiers might change the type of an object or the object might have to be split into multiple objects, one for each geometry type.

## Instancing Proposal

This builds on top of the proposal above. One could simply add a new `InstancingComponent`, which contains a bunch of points with attributes and pointers to the objects/collections/geometries that should be instanced.

This is a geometry component like any other and can therefore be further modified by modifiers and nodes.

## Misc

A work-in-progress implementation of a `GeometrySet` type can be found in [BKE_geometry_set.hh](https://developer.blender.org/diffusion/B/browse/geometry-nodes/source/blender/blenkernel/BKE_geometry_set.hh).

The diagram below visualizes the current state (top) and the desired state (bottom).