Hi Guys,
Chris, if you don't like having 'implicit' ranking via the order of LOD definitions in the config file, then I think we need an explicit ranking.
In particular, the stud polygon count isn't quite good enough. For example:
- 16-gon studs with/without logos. Clearly the ones with logos represent a higher rendering load, but the stud side count is 16 for both.
- No-studs vs no-studs-and-interiors. If we wanted both levels of detail, they would both have a stud side count of 0.
I really like Santeri's tag-value proposal - it lets us flexibly add more meta data to LODs, and not every client has to care about all meta data. So...
I would like to see polygon edge count be separate from sequence/LOD cost because the polygon edge count is ambiguous in some cases. With Santeri's proposal we can add another tag.
Cheers
Ben
Chris, if you don't like having 'implicit' ranking via the order of LOD definitions in the config file, then I think we need an explicit ranking.
In particular, the stud polygon count isn't quite good enough. For example:
- 16-gon studs with/without logos. Clearly the ones with logos represent a higher rendering load, but the stud side count is 16 for both.
- No-studs vs no-studs-and-interiors. If we wanted both levels of detail, they would both have a stud side count of 0.
I really like Santeri's tag-value proposal - it lets us flexibly add more meta data to LODs, and not every client has to care about all meta data. So...
Chris Dee Wrote:The polygon edge count would be used to sequence the entries and would describe how circular elements are coded, but wouldn't prevent other primitives existing in the same folder.
I would like to see polygon edge count be separate from sequence/LOD cost because the polygon edge count is ambiguous in some cases. With Santeri's proposal we can add another tag.
Cheers
Ben