Update for version 1803: support for HoloLens and platform/version flags #18
Conversation
robertos
commented
Apr 2, 2018
robertos
commented
- Add support for HoloLens (NRM packing)
- Add more parameters on command line and UWP to support multiple platforms and versions, as well as replacing compressed textures
- Documentation fixes
…d line and UWP to support multiple platforms and versions, as well as replacing compressed textures. Documentation fixes.
robertos
requested review from
erikdahlstrom,
sbtron,
mhurliman,
najadojo,
thmignon and
johnpf74
| None = 0x0, | ||
| Holographic = 0x1, | ||
| Desktop = 0x2 | ||
| }; |
There was a problem hiding this comment.
It seems as though we should not define the tool interface by platform instead of on the packing type(s) desired. If we also desire to have quick parameters also add platform/minversion.
There was a problem hiding this comment.
The interface of the library uses the packing types. This is a lot more user-friendly, so that the dev doesn't have to study the docs to figure out which packing to use.
Here I'm using -compatibility-mode <on|off> and -platform <holographic|desktop|all> in combination to get assets with the right packing (NRM or ORM, but also supporting NRM+ORM, ORM+RMO and NRM+RMO+ORM combos).
What would be your proposal?
There was a problem hiding this comment.
Also provide a option for packing types to add if the customer wants to define this themselves for use outside of Windows MR.
Simplifying with platform is great but a target minversion would be better than compatibility as our requirements/options evolve over time. Even better maybe to parse an appx manifest.
There was a problem hiding this comment.
If the user wants to use their asset outside of Windows MR then this is the wrong tool. It's very easy to use the library and pack up a tool for your own scenario, but this tool specifically doesn't allow you to choose the packing/compression parameters besides what's supported for WMR.
I thought about the min version but that also adds complexity. I was trying to avoid as much as possible the user of the tool having to learn implementation details in order to use it. I agree that compatibility-mode is a very generic way of saying "support RS3 as well". I guess I'd be OK with changing that parameter to "-min-version " and number could be a build number (e.g. 16299.0) or a version number (1803) and it would do the right thing on either case.
| } | ||
| else if (param == PARAM_REPLACE_TEXTURES) | ||
| { | ||
| replaceTextures = true; |
There was a problem hiding this comment.
Should set state to initial here.
| - Allows overriding the maximum texture dimension (width/height) when compressing textures. The recommended maximum dimension in the [documentation](https://developer.microsoft.com/en-us/windows/mixed-reality/creating_3d_models_for_use_in_the_windows_mixed_reality_home#texture_resolutions_and_workflow) is 512, and the allowed maximum is 4096. | ||
|
|
||
| - `-replace-textures` | ||
| - If enabled, replaces all textures with their DDS compressed equivalents during the compression step. | ||
| - This results in a smaller file size, but the resulting file will not be compatible with most glTF viewers. |
There was a problem hiding this comment.
This also sounds sort of like 'compatibility-mode', as in one might expect that when 'compatibility-mode' is off this flag would get applied automatically.
There was a problem hiding this comment.
Makes sense. I think I'll get rid of -compatibility-mode entirely given this comment and @najadojo 's comments above.
…-mode to -min-version
|
Any other pending comments @erikdahlstrom @najadojo ? |
