Support for vrm. #199

fire · 2020-12-05T05:31:07Z

Use a vrm file extension to trigger processing.

See #198 for test cases and examples.

The command to test is now:

./gltfpack -i "Miraikomachi.vrm" -o "Miraikomachi Opt.VRM"

fire · 2020-12-05T05:46:47Z

How do I read those errors in the cicd?

Edited:

What are the step to recreate the error?

fire · 2020-12-07T15:12:07Z

@zeux I wasn't able to recreate the errors. Do you know how that test works?

zeux · 2020-12-07T16:52:30Z

The test validates that packing any model from glTF-Sample-Models repository produces a valid glTF file as validated by glTF-Validator. glTF-Sample-Models/2.0/Cameras/glTF/Cameras.gltf is the specific file on which the process fails with this change, you should be able to get the source file from glTF-Sample-Models Khronos repository.

fire · 2020-12-08T02:54:46Z

Green!

Use a vrm file extension to trigger processing.

fire · 2020-12-08T15:17:07Z

gltf/parsegltf.cpp

@@ -165,6 +175,8 @@ static void parseMeshesGltf(cgltf_data* data, std::vector<Mesh>& meshes, std::ve
 			meshes.push_back(Mesh());
 			Mesh& result = meshes.back();

+			result.name = mesh.name;


Might be a problem with variable lifetime

zeux · 2020-12-09T02:35:14Z

gltf/gltfpack.cpp

@@ -488,6 +498,11 @@ static void process(cgltf_data* data, const char* input_path, const char* output
 				append(json_meshes, ",\"indices\":");
 				append(json_meshes, index_accr);
 			}
+			if (settings.keep_extras && !prim.extras.empty())


Why is this necessary? AFAICT the only "extras" node in the .VRM file from the issue is on the mesh, not on primitive, and that contains targetNames which should already be preserved by gltfpack.

zeux · 2020-12-09T02:35:59Z

gltf/gltfpack.cpp

+		for (size_t i = 0; i < data->data_extensions_count; ++i)
+		{
+			cgltf_extension extension = data->data_extensions[i];
+			if (!extension.name)


This & above & below can be replaced with if (strcmp(extension.name, "VRM") == 0) (extension.name is guaranteed to be non-null)

zeux · 2020-12-09T02:38:37Z

gltf/gltfpack.cpp

@@ -676,6 +722,8 @@ static void process(cgltf_data* data, const char* input_path, const char* output
 	writeArray(json, "meshes", json_meshes);
 	writeArray(json, "skins", json_skins);
 	writeArray(json, "animations", json_animations);
+	comma(json);
+	append(json, json_extensions);


This will always emit "extensions" and also causes a conflict with top-level KHR_lights_punctual extension since there's now going to be two extension blocks for files that use that.

Instead what should happen is:

json_extensions should be initially empty

json_lights should be appended to it, if necessary

VRM data should be appended to it, if necessary

if json_extensions isn't empty when forming the final JSON blob, we should write out "extensions":{ followed by json_extensions contents followed by }

zeux · 2020-12-09T02:38:49Z

gltf/gltfpack.cpp

+			append(json_extensions, "\"");
+			append(json_extensions, extension.name);
+			append(json_extensions, "\":");
+			append(json_extensions, extension.data);


This should use appendJson to minify the output

zeux · 2020-12-09T02:39:23Z

gltf/gltfpack.cpp

@@ -790,8 +838,12 @@ int gltfpack(const char* input, const char* output, const char* report, Settings

 	const char* iext = strrchr(input, '.');
 	const char* oext = output ? strrchr(output, '.') : NULL;
+
+	if (iext && (strcmp(iext, ".vrm") == 0 || strcmp(iext, ".VRM") == 0)) {


Please use clang-format on this code, as this bracing style is inconsistent with the coding guidelines, see https://github.com/zeux/meshoptimizer/blob/master/CONTRIBUTING.md

zeux · 2020-12-09T02:40:57Z

gltf/gltfpack.cpp

+	if (oext && (strcmp(oext, ".vrm") == 0 || strcmp(oext, ".VRM") == 0))
+	{
+		settings.vrm = true;
+		settings.keep_extras = true;


I would prefer to omit these, esp. quantize but preferably others. It's not clear to me why these need to be present, and if a user wants to apply these optimizations to a VRM file there's not going to be a way to do this without adding more kinds of command-line options, if vrm extension acts as an override.

zeux · 2020-12-09T02:42:12Z

gltf/gltfpack.cpp

@@ -896,7 +958,7 @@ int gltfpack(const char* input, const char* output, const char* report, Settings
 			return 4;
 		}
 	}
-	else if (oext && (strcmp(oext, ".glb") == 0 || strcmp(oext, ".GLB") == 0))
+	else if (oext && (strcmp(oext, ".vrm") == 0 || strcmp(oext, ".VRM") == 0 || strcmp(oext, ".glb") == 0 || strcmp(oext, ".GLB") == 0))


Should this also be added to the condition above that sets texture_embed? Unclear what the de-facto rules are for VRM files, e.g. whether they are supposed to keep textures separately or not.

zeux · 2020-12-09T02:42:26Z

gltf/gltfpack.h

@@ -39,6 +39,7 @@ struct Transform

 struct Mesh
 {
+	const char* name;


std::string might be better.

zeux · 2020-12-09T02:44:05Z

gltf/write.cpp

@@ -739,6 +739,14 @@ static std::string decodeUri(const char* uri)

 void writeImage(std::string& json, std::vector<BufferView>& views, const cgltf_image& image, const ImageInfo& info, size_t index, const char* input_path, const char* output_path, const Settings& settings)
 {
+	if (image.name)


Is preserving the name of the image object necessary? It doesn't carry semantical meaning, and gltfpack right now only preserves names for objects that are likely to be used by-name externally, specifically nodes, materials and animations.

I need to check if this is required by the internal material definition called MTOON.

zeux · 2020-12-09T02:44:25Z

gltf/write.cpp

@@ -1320,7 +1328,8 @@ void writeAnimation(std::string& json, std::vector<BufferView>& views, std::stri

 		comma(json_samplers);
 		append(json_samplers, "{\"input\":");
-		append(json_samplers, range ? range_accr : track.constant ? pose_accr : time_accr);
+		append(json_samplers, range ? range_accr : track.constant ? pose_accr


Was this change intended?

Not intended.

fire · 2020-12-09T19:57:42Z

Thank you for the review. I will be delayed until the weekend to submit the changes.

fire · 2020-12-29T19:08:39Z

I slept thinking about this optimization, because Godot Engine added autolod, I don't have a requirement for this. This VRM pr is salvageable.

arpu · 2021-01-14T00:27:39Z

still interessded in vrm optimation

@fire can you point me to how Godot Engine autolod works?

fire · 2021-01-14T02:29:52Z

Godot loads gltf2
For every imported mesh run mesh optimizer with the error returned and create lod levels. Loop until stuck or index is 10. Determine metric to display lod level.
(Would like tesselate first and the decimate second together option) because simplify gets stuck
Implement vrm

I believe that mesh optimizer works under wasm, so you can follow the same flow.

The reason for this flow is that it doesn't make sense to modify the original gltf if the goal is to convert to the internal engine format.

fire force-pushed the vrm branch 2 times, most recently from 9c101cd to a5368cd Compare December 5, 2020 05:39

fire force-pushed the vrm branch 3 times, most recently from 83132ed to c24d873 Compare December 8, 2020 02:54

fire force-pushed the vrm branch from c24d873 to ab0cdec Compare December 8, 2020 02:56

fire marked this pull request as draft December 8, 2020 03:08

Support for vrm.

c06f2e5

Use a vrm file extension to trigger processing.

fire force-pushed the vrm branch from ab0cdec to c06f2e5 Compare December 8, 2020 03:27

fire marked this pull request as ready for review December 8, 2020 03:28

fire commented Dec 8, 2020

View reviewed changes

fire mentioned this pull request Dec 8, 2020

VRM importer crashes with a custom optimizer saturday06/VRM-Addon-for-Blender#31

Closed

zeux reviewed Dec 9, 2020

View reviewed changes

fire added 3 commits December 9, 2020 16:31

Cleanup.

c77fc9f

Trying to reduce the breakage.

aea5e4d

Symmetrical.

8c15632

fire marked this pull request as draft December 10, 2020 02:16

fire added 4 commits December 9, 2020 18:46

Changes to compile.

4353d11

Clang format.

31c6825

Mesh quantization is an illegal vrm optimization.

8d6fe5a

Texture transform is a legal extension.

7fb67b0

fire closed this Dec 29, 2020

madjin mentioned this pull request Dec 30, 2023

Debugging VRM support madjin/meshoptimizer#1

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support for vrm. #199

Support for vrm. #199

fire commented Dec 5, 2020

fire commented Dec 5, 2020 •

edited

Loading

fire commented Dec 7, 2020

zeux commented Dec 7, 2020

fire commented Dec 8, 2020

fire Dec 8, 2020

zeux Dec 9, 2020

zeux Dec 9, 2020

zeux Dec 9, 2020

zeux Dec 9, 2020

zeux Dec 9, 2020

zeux Dec 9, 2020

zeux Dec 9, 2020

zeux Dec 9, 2020

zeux Dec 9, 2020

fire Dec 10, 2020

zeux Dec 9, 2020

fire Dec 10, 2020

fire commented Dec 9, 2020

fire commented Dec 29, 2020

arpu commented Jan 14, 2021

fire commented Jan 14, 2021 •

edited

Loading

Support for vrm. #199

Support for vrm. #199

Conversation

fire commented Dec 5, 2020

fire commented Dec 5, 2020 • edited Loading

fire commented Dec 7, 2020

zeux commented Dec 7, 2020

fire commented Dec 8, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fire commented Dec 9, 2020

fire commented Dec 29, 2020

arpu commented Jan 14, 2021

fire commented Jan 14, 2021 • edited Loading

fire commented Dec 5, 2020 •

edited

Loading

fire commented Jan 14, 2021 •

edited

Loading