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

Multiple types of materials to support WebGL Geometries #3806

Closed
2 tasks done
sanketsingh24 opened this issue Jun 10, 2019 · 3 comments · Fixed by #5774
Closed
2 tasks done

Multiple types of materials to support WebGL Geometries #3806

sanketsingh24 opened this issue Jun 10, 2019 · 3 comments · Fixed by #5774

Comments

@sanketsingh24
Copy link
Contributor

sanketsingh24 commented Jun 10, 2019

Nature of issue?

  • Existing feature enhancement

Most appropriate sub-area of p5.js?

  • WebGL

Details

Currently, in p5, only one of the specularMaterial() or ambientMaterial() can be applied to a geometry. But many objects in the real world can exhibit both behaviour. Take a look at this sketch from processing-

Screenshot_2019-06-09_21-55-37
(Code)

In short, the left sphere has just ambient (red) properties whereas the right sphere has both ambient (red) and specular (white) properties.

As I am implementing emissiveMaterial() also, we (me and @aferriss ) just got this thought and this would be a good feature. One of the things which we noticed was both specularMaterial() and ambientMaterial() use the same uniform and same variable, which causes the later one to render.

@sanketsingh24 sanketsingh24 changed the title Multiple type of materials support for WEBGL Geometries Multiple types of materials to support WebGL Geometries Jun 10, 2019
@stalgiag
Copy link
Contributor

stalgiag commented Sep 2, 2019

Hi @sanketsingh24 and @aferriss, after finishing the summer project, what are your thoughts on this issue? Thanks!

@aferriss
Copy link
Contributor

aferriss commented Sep 4, 2019

@stalgiag @sanketsingh24 I still think this would be a good feature to add, but it's probably not a simple PR. This touches a lot of the webGL rendering pipeline and untangling and sorting things out is probably going to be a bit of an effort.

I don't think I'll have much time anytime soon to work on this and I'm pretty certain Sanket is also busy in the coming months, so I'm going to slap on the help wanted tag.

@stalgiag
Copy link
Contributor

stalgiag commented Sep 5, 2019

Thanks for the thoughts @aferriss !

I agree that this seems a bit rough, and definitely feels like it would need to be part of a larger restructuring. I am looking into these kinds of changes as part of #3794. I am happy to do the work if there is a sound high-level plan for a restructure or redesign, but without this I am reluctant to start messing with this many parts of the code before the 1.0 release.

It would be nice to start gathering design opinions from gl experts, but that might require first making a very clear map of the rendering pipeline as it stands now.

I also don't know if the effort-to-reward ratio is ideal with a large GL restructure currently. The stability, functionality, and performance trend of the GL Renderer has been strongly upward for the past few years, but the portion of users that work with it may still be relatively low. Of course, this is difficult to know for sure since we don't capture data about these kinds of things.

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

Successfully merging a pull request may close this issue.

3 participants