Allow --lod -1 to tag an input as the environment#270
Conversation
There was a problem hiding this comment.
Pull request overview
This PR closes a CLI gap by allowing users to manually tag an input as the “environment/skybox” using the existing lod === -1 sentinel, matching how LCC/LCC2 inputs are already handled across the pipeline.
Changes:
- Relax
--lodvalidation to accept-1(rejecting only values< -1). - Emit a warning when environment-tagged splats are present but the output format is not
lod-meta.json(since non-LOD writers ignoreenvDataTable). - Update CLI help/README docs and add CLI tests covering
--lod -1acceptance and< -1rejection.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
src/cli/index.ts |
Accepts --lod -1, updates help text, and warns when env-tagged splats will be discarded for non-LOD outputs. |
test/cli.test.mjs |
Adds regression tests for --lod -1 (accepted) and --lod -2 (rejected). |
README.md |
Updates --lod documentation to mention -1 as the environment sentinel. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
why |
|
it would have to be |
|
I'm not why it would have to be |
|
actually using env was my instinct too, but it would mean jumping through a bunch of hoops in the argument parser (this arg is a number). not sure it's worth it? if you really really can't live without it I can probably add an |
|
I don't mind, your call, just pointing it out that it's less clear than ideally should be. |
|
We can always tweak this in a major version bump. I kinda like the idea of |
Summary
The environment/skybox concept already exists throughout the pipeline as the sentinel
lod === -1— LCC/LCC2 readers tag environment splats with it, the CLI splits those splats into a separateenvDataTable, and the LOD writer emits them toenv/meta.json(referenced fromlod-meta.jsonvia theenvironmentfield). The only gap was that there was no way to assign it manually:--lodvalidation rejected any negative value, so an arbitrary.ply/.sog/etc. input could never be marked as the environment.This change relaxes the validation so
--lod -1is accepted, unlocking the existing environment path from the CLI.Changes
src/cli/index.ts):--lodnow rejects values< -1instead of< 0, permitting the-1environment sentinel while still rejecting other negatives (only-1is recognized; other negatives would be mis-binned by the LOD writer).src/cli/index.ts): environment splats are only written forlod-meta.jsonoutput — every other writer ignoresenvDataTable. We now emit a warning when env-tagged splats are present but the output format isn't LOD, so they aren't silently dropped.--lodhelp text and README usage block to(n >= 0, or -1 for environment).test/cli.test.mjs): added coverage for--lod -1being accepted and--lod -2being rejected.No change was needed to argument tokenization (
normalizeArgvalready rewrites--lod -1→--lod=-1) or toprocess.ts(it fills thelodcolumn with whatever value,-1included).Usage
--lodis per-input, so it must follow the input file it tags. Note that forlod-meta.jsonoutput the scene input must itself carry a--lod <n>tag (pre-existingwrite-lodrequirement).Testing
npm run lint— cleannode --test test/cli.test.mjs— 4/4 pass;test/write-lod.test.mjs— 2/2 passscene --lod 0 env --lod -1 out/lod-meta.jsonwritesenv/meta.json+ textures and sets"environment":"env/meta.json"in the manifestout.plyprints the discard warning and excludes the env splats from the output