Naming scheme and library content

[xelatihy]

To freeze version2, we want to adopt a final naming scheme as well as decide about a final library content. This issue is a proposal to track decision in this area.

Library merges

To reduce library dependencies, we should merge small libraries into bigger ones if the use makes sense.

• [x] merge Yocto/Bvh into Yocto/Shape and remove Embree support.
  • this is to shorten code and since the bvh is now only used for other apps
  • Embree support needs to be removed to keep bvhs as values, while Embree is a reference type
  • note that Embree will remain supported in the path tracer
  • in the future, we could have a generic BVH that wraps Embree, but it cannot be a value type, so we need to accept the fact that large data structures in Yocto/Shape need to use pointers
• [x] Yocto/Ply, Yocto/Bvh, Yocto/Pbrt should eventually be released as separate libraries, since they are already separate now. This is not crucial now.
  • remove dependency on Yocto/Math
• [x] Yocto/Common is a collection of unrelated utilities like container shortcuts and parallel stuff; it is not used in the rest of Yocto to reduce dependencies. We could remove or keep it.
• [x] Yocto/Shape contains a lot of functionality that helps everywhere and some more hard functionality. For example compute_normals is helpful everywhere and only a tiny bit of code. While geodesics are more proper in a library for computational geometry. One practical think we could do is to move the small functionality into Yocto/Math and keep the big ones in Yocto/Shape.
• [x] Yocto/Image contains the image datatype that is used everywhere in yocto. Often the only reason why Yocto/Image is included is to get the image definition and be able to talk to the rest of Yocto. If, and only if, we move small parts of Yocto/Shape into Yocto/Math, we should move small parts of Yocto/Image into Yocto/Math, at least image, tonemap and eval_image.
• [x] Yocto/Trace contains rendering helpers like fresnel and micro facet functions. We should move them to math. This is similar to render man or osl libraries.

Library names

We want to freeze library names to final ones. Also to

• [x] decide on name for Yocto/Math
  • math seems too generic
  • proposal: Yocto/VecMath
• [x] decide on name for Yocto/Shape
  • shape makes little sense IMO
  • proposal: not sure yet
• [x] decide on name for Yocto/OpenGL
  • OpenGL is hidden and should be since it may go away
  • proposal: Yocto/UserInterface
• [x] decide on name for Yocto/CommonIO
  • Yocto/CommonIO is really library support for quickly writing command line applications
  • proposal: Yocto/CmdLine or Yocto/CommandLine
• [x] decide on name for Yocto/SceneIO
  • Yocto/SceneIO does mostly scene loading and a few small utilities related to scene validation
  • but in the future we may add a few other small utilities, so maybe a more generic name may be best
  • proposal: either keep the same or Yocto/Scene or Yocto/Model

Namespace names

We should decide and update namespace names. The keyword here is consistency in length and meaning. Right now we use 2-5 characters because it just happened that way. But many libraries settle for 3 chars, so maybe that is a good compromised to achieve if it does not break readability too much. Here are some proposal we should vote on. Here I list alternatives of 3 chars or the current ones.

• [x] Yocto/Math: yvm - ym now
• [x] Yocto/Shape: ysh - yshp now
  • but really a better library name may be helpful
• [x] Yocto/Image: yim - yimg now
• [x] Yocto/OpenGL: yui - yglu now
• [ ] Yocto/CommonIO: ycl / ycli now
• [x] Yocto/Trace: ytr - ytrc now
• [x] Yocto/SceneIO: ysc - yscn now

[giacomonazzaro]

The following proposed names are optimized to be namespace-friendly.

Library names

Yocto/Math could be alternatively called Yocto/Vec as it provides basic support for operations in vector spaces. A better name for Yocto/Shape could be Yocto/Geometry, as it is a collection of functions for geometry processing. Yocto/OpenGL could be replaced with Yocto/Gui. Yocto/SceneIO could be named simply Yocto/IO, which is more general and also suggests that there is no graphics in it. Additionally, Yocto/Rendering could be a more representative name for Yocto/Trace.

Namespaces

Using only 3 characters maybe is not expressive enough, since the first one is always y and you can't do much with only 2 characters. We can consider settling on using 4 characters. In that case, these are the proposed namespaces for the mentioned library names.

• Yocto/Vec: yvec
• Yocto/Geometry: ygeo
• Yocto/Image: yimg
• Yocto/Gui: ygui
• Yocto/CommonIO: ycli
• Yocto/Trace: ytrc
• Yocto/Rendering: yrnd (but it's too close to "rand"...)
• Yocto/IO: yio

[xelatihy]

The proposed changes and wording seem fine.. We will keep four letter words and attempt to change names in the suggested manner. This is also a smaller change to where we are now, so quicker and less risky. Hopefully we can make it before the deadline.

[xelatihy]

Names have been changed where possible to follow the above conventions. Yocto/Math stayed like this since it was not easy to get things to compile on a name change (and we are too close to the deadline). Yocto/Shape also stayed for the same reason.

[xelatihy]

All changes not implemented will have to wait for next release in v3 once we move to span and pointers and avoid std::vectors.