diff options
Diffstat (limited to 'indra/newview/gltf/README.md')
| -rw-r--r-- | indra/newview/gltf/README.md | 30 |
1 files changed, 15 insertions, 15 deletions
diff --git a/indra/newview/gltf/README.md b/indra/newview/gltf/README.md index 8e7df0a439..a2d43be1d6 100644 --- a/indra/newview/gltf/README.md +++ b/indra/newview/gltf/README.md @@ -1,13 +1,13 @@ # Linden Lab GLTF Implementation - -Currently in prototype stage. Much functionality is missing (blend shapes, + +Currently in prototype stage. Much functionality is missing (blend shapes, multiple texture coordinates, etc). GLTF Specification can be found here: https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html. If this implementation disagrees with the GLTF Specification, the specification is correct. Class structure and naming should match the GLTF Specification as closely as possible while -conforming to the LL coding standards. All code in headers should be contained in the +conforming to the LL coding standards. All code in headers should be contained in the LL::GLTF namespace. The implementation serves both the client and the server. @@ -18,7 +18,7 @@ The implementation serves both the client and the server. - The implementation MUST use the same indexing scheme as the GLTF specification. Do not store pointers where the - GLTF specification stores indices, store indices. - Limit dependencies on llcommon as much as possible. Prefer std::, boost::, and (soon) glm:: over LL facsimiles. -- Usage of LLSD is forbidden in the LL::GLTF namespace. +- Usage of LLSD is forbidden in the LL::GLTF namespace. - Use "using namespace" liberally in .cpp files, but never in .h files. - "using Foo = Bar" is permissible in .h files within the LL::GLTF namespace. @@ -69,14 +69,14 @@ Parameters to "write" and "copy" MUST be ordered "src" before "dst" so the code reads as "write src to dst" and "copy src to dst". When reading string constants from GLTF json (i.e. "OPAQUE", "TRIANGLES"), these -strings should be converted to enums inside operator=. It is permissible to +strings should be converted to enums inside operator=. It is permissible to store the original strings during prototyping to aid in development, but eventually we'll purge these strings from the implementation. However, implementations MUST preserve any and all "name" members. "write" and "copy" implementations MUST be stored in buffer_util.h. As implementers encounter new data types, you'll see compiler errors -pointing at templates in buffer_util.h. See vec3 as a known good +pointing at templates in buffer_util.h. See vec3 as a known good example of how to add support for a new type (there are bad examples, so beware): ``` @@ -120,29 +120,29 @@ inline bool write(const vec3& src, Value& dst) Speed is important, but so is safety. In writers, try to avoid redundant copies (prefer resize over push_back, convert dst to an empty array and fill it, don't -make an array on the stack and copy it into dst). +make an array on the stack and copy it into dst). -boost::json WILL throw exceptions if you call as_foo() on a mismatched type but -WILL NOT throw exceptions on get_foo with a mismatched type. ALWAYS check is_foo +boost::json WILL throw exceptions if you call as_foo() on a mismatched type but +WILL NOT throw exceptions on get_foo with a mismatched type. ALWAYS check is_foo before calling as_foo or get_foo. DO NOT add exception handlers. If boost throws an exception in serialization, the fix is to add type checks. If we see a large number of crash reports from boost::json exceptions, each of those reports -indicates a place where we're missing "is_foo" checks. They are gold. Do not +indicates a place where we're missing "is_foo" checks. They are gold. Do not bury them with an exception handler. -DO NOT rely on existing type conversion tools in the LL codebase -- LL data models -conflict with the GLTF specification so we MUST provide conversions independent of +DO NOT rely on existing type conversion tools in the LL codebase -- LL data models +conflict with the GLTF specification so we MUST provide conversions independent of our existing implementations. ### JSON Serialization ### -NEVER include buffer_util.h from a header. +NEVER include buffer_util.h from a header. Loading from and saving to disk (import/export) is currently done using tinygltf, but this is not a long term solution. Eventually the implementation should rely solely on boost::json for reading and writing .gltf -files and should handle .bin files natively. +files and should handle .bin files natively. When serializing Images and Buffers to the server, clients MUST store a single UUID "uri" field and nothing else. The server MUST reject any data that violates this requirement. @@ -152,5 +152,5 @@ Servers MAY reject Assets that contain Buffers with unreferenced data. ... to be continued. - + |