# Relation 3D:Model

## Rationale

We already have simple 3d modelling like building:parts=* and building:levels=* so, what should we do if we want to use stored 3d models and simple 3d which we already have in database? We need to know, which objects have 3d model and do not render building:parts=* and building:levels=* based geometry.

## Tags

Key Value Explanation
type 3d:model Indicates this relation represents an object's 3d model.
src url URL to model. I think wiki data might be the best place to store models and models' edit history. I dont know which way is better, keep number of relations one for each model or keep number of links in each relation to models with different level of details.
polygons Number of polygons Says how many polygons contains model. Is it lowpoly or highpoly model.
azimuth Origin azimuth Angle between model's Y axis and direction to North
lon Model's origin lon Longitude of model's (0, 0) point. Center coordinates of members by default.
lat Model's origin lat Latitude of model's (0, 0) point. Center coordinates of members by default.

## Members

Member Role Explanation
building=* and building:part=* - Ways, used in Simple 3D buildings [S3DB], 3D Renders shouldn't render 3d models for child objects.
origin Origin point for model. I think it would be good practice to use one of the corners for this. Longitude and latitude of this point should override relation's lon and lat tag values.
director Used to specify azimuth for model, with osm node. If user have specified director point, build vector from origin node to director node. Norm of this vector will be X vector for model coordinates system. And azimuth is angle between direction to North and this vector. This value should override relation's azimuth tag value.

## Procedural generation

1. Add roles for objects like 3d:ref:REF_NAME
2. Access that object from 3d model description script as REF_NAME
3. Generate geometry iteratively
4. Extend geometry groups with onthologies or throe osm's tag=vlue
5. Describe snapshots