Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GLTFLoader refactoring #12772

Merged
merged 4 commits into from
Nov 30, 2017
Merged

GLTFLoader refactoring #12772

merged 4 commits into from
Nov 30, 2017

Conversation

takahirox
Copy link
Collaborator

This PR refactors and cleans up GLTFLoader and it's much more readable now. It uses Group.isGourp so requires build/ update.

Major changes

  • Removing _each() and ._withDependencies() and introducing .getMultiDependencies() instead. They were a bit tricky especially for new developers. By removing them the code became more readable.
  • Unifying .loadXXX methods. .loadXXX( xxxIndex ), not .loadXXXs(), now (except for .loadGeometries()).
  • Marking SkinnedMesh mesh defs before parsing. We don't need to replace Mesh with SkinnedMesh later now.
  • Moving Skeleton build to .loadScene().
  • Moving onBeforeRender() set to.loadMesh/Node().
  • Improving code consistency. For example, using *Def var name for definitions in json

I'd be very pleased if you folks check if this update won't break anything tho I already tested on webgl_loader_gltf. And any feedbacks are welcome.

/cc @donmccurdy

@donmccurdy
Copy link
Collaborator

This looks much cleaner, thanks! ❤️

I’ll run some tests with more models later tonight.

@donmccurdy
Copy link
Collaborator

donmccurdy commented Nov 29, 2017

I ran all of the glTF-Sample-Models (well, one file from each set) as well as the rome-gltf samples and a few Sketchfab files. All looks good.

Demo: https://gltf-viewer-experimental.donmccurdy.com/
Original: https://gltf-viewer.donmccurdy.com/

The only weird thing I see is that loading seems slow in some cases:

robin_hood_in_sherwood_forest.zip

^When I profile that, it looks like the Blob XHR request is just taking much longer, so maybe it's nothing to do with this PR, or just a fluke on my machine? Also note the experimental demo is on dev three.js, original demo is r88. Do you see the same thing?

@@ -1183,9 +1083,9 @@ THREE.GLTFLoader = ( function () {
* @param {THREE.Mesh} mesh
* @param {GLTF.Mesh} meshDef
* @param {GLTF.Primitive} primitiveDef
* @param {Object} dependencies
* @param {Array} accessors
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: can you make this Array<THREE.BufferAttribute>?

GLTFParser.prototype.getMultiDependencies = function ( types ) {

var results = {};
var fns = [];
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe name this deps or pending; fns sounds like Functions, but these are Promises.


} );

};

/**
* Specification: https://github.com/KhronosGroup/glTF/blob/master/specification/2.0/README.md#meshes
* @param {number} meshIndex
* @return {Promise<THREE.(Skinned)Material>}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

{Promise<THREE.Mesh|THREE.SkinnedMesh>}

(http://usejsdoc.org/tags-type.html)


};
}();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a pretty long with the IIFE here... maybe buildNodeHierarchy should just be a local helper function or a method of GLTFParser?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the performance, readability, or anything else?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just readability IMO

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't really wanna make it GLTFParser method because it's used only in .loadScene().
And the reason why I used IIFE is .loadScene() can be called many times with glTF including many scenes. I didn't wanna make function for each call.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah making a function for each call would be worse I agree. I think the alternative is making a helper function, like addMorphTargets that is a local function but not exposed as a method on GLTFParser. Just easier to read with less nesting I think.

Copy link
Collaborator Author

@takahirox takahirox Nov 30, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, OK. I had misunderstood a bit. Yeah, helper function is one of the good ideas. Let's make PR for it if/when it's necessary.

@takahirox
Copy link
Collaborator Author

I've confirmed loading performance issue here...
I'll look into the detail.

@takahirox
Copy link
Collaborator Author

Seems like something stalls request... 🤔

image

@takahirox
Copy link
Collaborator Author

Probably I've figured out. This seems a bug. I'll try to fix.

@takahirox
Copy link
Collaborator Author

I've fixed the performance issue. I needed cache in GLTFParser.getDependencies().

@mrdoob
Copy link
Owner

mrdoob commented Nov 30, 2017

Sweet!

@mrdoob mrdoob merged commit 7a14e55 into mrdoob:dev Nov 30, 2017
@mrdoob
Copy link
Owner

mrdoob commented Nov 30, 2017

Thanks!

@takahirox takahirox deleted the gltfRefactoring branch November 30, 2017 08:57

} );

};

/**
* Specification: https://github.com/KhronosGroup/glTF/blob/master/specification/2.0/README.md#meshes
* @param {number} meshIndex
* @return {Promise<THREE.Mesh|THREE.SkinnedMesh>}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should the return type be Promise<THREE.Group>?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, it should actually be:

Promise<THREE.Mesh|THREE.SkinnedMesh|THREE.Group>

in the future we want to reduce the number of cases where a Group is returned (#11944), but probably can't eliminate that entirely.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I see you spotted that already 😁

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants