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

[WIP] Example for extending materials #14166

Closed
wants to merge 1 commit into from

Conversation

pailhead
Copy link
Contributor

@pailhead pailhead commented May 29, 2018

I've copied over the instancing lambert example and tried to make it work on various materials. The focus of this example is not instancing by itself (its a very simplified example) but for extending materials.

I was unable to make it work with MeshToonMaterial though:

http://dusanbosnjak.com/test/webGL/three-materials-extended/

@pailhead pailhead force-pushed the instance-material-builtin branch from 479eff5 to 2e2a5b3 Compare May 29, 2018 08:32
@WestLangley
Copy link
Collaborator

Sweet. Well-done, and informative.

@pailhead
Copy link
Contributor Author

pailhead commented May 29, 2018

Thank you, ill clean it up a bit. Leave the giant comment? The most important thing i wanted to outline are the "discrete steps" meaning, vertex transformation is a different thing from normal transformations. What should this be called?

@mrdoob
Copy link
Owner

mrdoob commented Jun 20, 2018

What does this example show that the one introduced in #14012 doesn't? 🤔

@pailhead
Copy link
Contributor Author

pailhead commented Jun 20, 2018

How to write arbitrary extensions for arbitrary materials in 3rd party applications? Not sure how #14012 relates. 🤔 @WestLangley you're welcome to share what you liked about this?

@WestLangley
Copy link
Collaborator

@WestLangley you're welcome to share what you liked about this

I considered this to be an informative experiment that is beneficial to the other contributors who are trying to understand the issues involved in extending materials. These kinds of experiments are helpful when making design decisions. They are particularly helpful in identifying design limitations.

I have not considered this WIP as something to be added as an example. We should only include in the examples coding patterns we recommend users to follow. I think we are still trying to figure that out.

@pailhead
Copy link
Contributor Author

pailhead commented Jun 20, 2018

Hmmm, as an example it's more at odds with:

https://threejs.org/examples/?q=modified#webgl_materials_modified

I think i disagree with you @WestLangley on the meaning of this as a pattern. I don't think that contributors should be using this as a pattern of contributing. IE. three should have no core features that rely on shader extensions.

It could be used for prototyping and testing:

  • instead of modify core, npm run build and refresh, you can modify example and refresh (without the build)
  • you can test the current structure of the shaders and decide if they need to be refactored(@mrdoob doesn't want to do any modifications to the current system though) but for example, instancing could first be prototyped with an extension, and then included in the core like most other stuff behind a preprocessor directive.
  • in a 3rd party app, if you want to make a modification to the decision three contributors made, you can opt out and replace it with your own (for example how matrices are handled for instancing, if three only does one thing)

Good examples are your recent object space normal maps. Say you weren't sure about the convention. It wouldn't have to be a core feature immediately, it could be an extension example until some requirements are met - "is this a good place for it", "is this the right api", "are these the right assets" etc.

With instancing, it can get pretty complex if you consider various optimizations, are matrices baked, are they computed, should some of the current shader structure be refactored to better accommodate instancing or not. All of these considerations can slow down the progress of a feature. As is #10750 is still unavailable, and i believe it's because of some of these choices/considerations. Because it's not available for use, it's hard to tell if the current solution is good or not, so it's hard to asses these choices.

This can be mitigated by something like this https://www.npmjs.com/package/three-instanced-mesh, but the code in that module is not up to the best practices and standards, because it's monkey-patching three.js on the fly. With more of these extensions in "staging" one could have a clearer picture of bigger overview of the landscape. This could indicate areas that need refactoring in the current chunk system, or even in future systems. At least that's how i imagine this should work , could be totally wrong :)

tl:dr; if there is only to be one example of shader extensions now, or for a while, would it make sense to add instancing to this

https://threejs.org/examples/?q=modified#webgl_materials_modified

@WestLangley
Copy link
Collaborator

Sorry, @pailhead, I have tried and tried, but I have a very difficult time comprehending your posts. Consequently, I have nothing else to add because I do not understand what you are trying to say.

So sorry...

@pailhead
Copy link
Contributor Author

Lol no worries. In short, do not look at this when developing threejs. Possibly combine with materials modified example (don’t compare to lambert instancing).

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.

3 participants