Feature implementation: emissiveMaterial()

[sanketsingh24]

Implemented emissiveMaterial()

Work done-

• Implemented uEmissive uniform in both shaders
• Implemented emissiveMaterial() in /src/webgl/material.js
• Added a manual-test-example in /webgl/material/emissive/sketch.js
• Unit tests
• Documentation
• Example

To do-

@aferriss

[Spongman]

is this really the direction we want to go, though. i would rather move away from the current practice of overloading the fill color, and toward a more reasonable color model like the one that processing uses where the material has different color properties (ambient, emissive, specular) that all contribute separately to the lighting of the surface. this is much more in line with similar color models that are used in other libraries and 3d modeling/rendering packages.

[sanketsingh24]

@Spongman I wouldn't call it overloading, but overwriting, and I also opened an issue regarding this #3806. It would require a lot of refactoring of both shaders and the js part. The shaders themselves are in pretty bad shape right now, and given only one material type is to be rendered, @aferriss and I agreed on this implementation.

[Spongman]

oh, i'm sorry, i didn't realize that it had been decided. i would have like to have weighed in beforehand. can you point me to the issue where that discussion occurred?

[aferriss]

@Spongman I think the issue Sanket is referring to is the one he referenced (#3806) but we didn't get any feedback regarding how to move forward. Since we're on a tight timeline for GSOC we decided it would be best to move forward in the paradigm that was already established (as far as we could tell) in p5 of one material type per geometry.

I think we'd both like to eventually add the ability to use multiple material properties per geometry but since it was a much larger task we decided to punt and try to implement at the end of the summer if we had any leftover time.

[Spongman]

yeah, i definitely think this area could use some more discussion before introducing these API changes.

for example:

• how is this PR different than just using basic.frag?
• why the name emissiveMaterial?
• not unrelated: why is ambientMaterial named the way it is?

[aferriss]

@Spongman Are you asking why they are named ambientMaterial() vs. just ambient()? I think that these functions are appended with "material" to clearly distinguish it from ambientLight() and other lighting functions. I know that there's Do you have any suggestions for how they could be better named?

As for how this is different than basic.frag, it's not. However I think it makes sense to have this kind of redundancy for setting the color of 3d geometry. I feel like in the context of 3d graphics, fill() is the odd one out. If you're already using ambientMaterial() and specularMaterial() does it not make sense to also use emissiveMaterial()rather than fill()? Fill is a nice simple way to set a solid color for geo, but inside of a light / material rendering pipeline I think it makes more sense to have an api that more accurately reflects what is happening when setting material / light properties.

[stalgiag]

I agree with @aferris here.

Restating points differently or offering my extended thoughts, I think that fill() is great for the user as-is, in that it offers a simple intuitive way of getting solid unlit colors especially for folks first making the move from 2D to 3D, but once we are moving into the language of 'materials' I think it makes more sense to offer a different term for the base color for a material. As was pointed out, this is useful mostly once multiple simultaneous materials are achieved. Once this is the case, it becomes a bit confusing for fill to dictate the main color state across all materials instead of just indicating a completely unlit solid color material. There are already many contradictions between the fill color state and material expectations, with normalMaterial being the most apparent example.

And as far as naming, I actually like ambientMaterial versus ambient. I think the distinction between lighting and material is a little more immediately clear with this than it is in Processing.

[aferriss]

Going to merge this as I haven't heard any other dissenting opinions.

[Spongman]

@aferriss i find your explanation above to be wholly unsatisfying. now we have two apis for doing essentially the same thing, complicating and confusing the documentation, and
the rendering pipeline.

i feel this was entirely rushed through with insufficient thought.

[aferriss]

@Spongman I'm sorry to hear that. I felt that the PR was in good shape and that there had been sufficient explanation as to the design and intention of the feature. It seemed to me that enough time had passed and since I hadn't heard from you since I was inclined to merge. I'm happy to continue the discussion if you have further thoughts.

[stalgiag]

@Spongman luckily no change is permanent! Open-source software is something that changes with time and not in a strictly unidirectional or linear fashion, so let's not exaggerate the severity of any one decision. I think everyone here is happy to talk if you feel like the merits of this design direction should still be discussed.

For my part in said discussion, I wouldn't say this complicates and confuses the documentation or render pipeline. I do think that there is some confusion but that is because this is only one step towards a more fully realized change in which curFillColor isn't always the intended material color. Also, it is important to note that there is nothing radical in the doubling of some duties between fill and emmisiveMaterial as this can be seen in Processing. That said, I'd be happy to try and think through why we might want to break from Processing and develop a different API for multiple simultaneous materials.

Perhaps there is an opportunity for an innovation in design here but it can only be reached through suggestions and discussion.

[stalgiag]

@Spongman could you send me an email at the address listed in my profile? I’d be grateful for the opportunity for a more direct conversation outside of the repo. We could discuss any concerns about the way that decisions are made with the library and also talk about what the expectations are for engaging with the community. One-on-one communications seems ideal for the task. Thanks!