-
-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
WEBGL - Is ambientMaterial() the same as fill()? #5308
Comments
I didn't design this and I find it a bit too subtle but there is a difference. specularMaterial(0, 0, 255);
fill(255, 0, 0);
sphere(100); results in a sphere with a red specular material applied. specularMaterial(0, 0, 255);
ambientMaterial(255, 0, 0);
sphere(100); results in a sphere with a red ambient material applied. Perhaps a slight redesign or a better articulation of the distinction in the docs is in order but this is my understanding of the difference currently. |
Huh. Thank you for the insight. So the current
--- Sidenote: is it correct to state that the default material of a sketch (when not explicitly created with a call to --- The second one makes more sense, when you work with the assumption that only one material can be active at a time. The call to ambient consistently overrides the call to specular. |
What do you think about adding this example (demonstrating WebGL behaviour) to the |
Here is another example demonstrating its use for setting vertex colors when using beginShape/endShape. The reference page for |
tagging @ShenpaiSharma as relevant to your GSoC project! |
Here’s an update from @ShenpaiSharma’s 2022 GSoC project: In the Processing implementation, the ambient, specular, and emissive each store the passed colors separately, which allows shaders to combine multiple material properties and colors. Currently p5 stores one color only in the curFillColor property on the renderer. This same property is set by fill, ambientMaterial, specularMaterial, and emissiveMaterial. So currently p5 will use only the material properties and color most recently called. Any previously called material methods will be overridden. ShenpaiSharma@680113f
In order to achieve similar results to Processing, it looks like we would need to add new properties to the renderer to store ambient, specular, and emissive colors and then modify every shader, passing in these colors as uniforms and combining them. We are wondering:
|
I think it's ok to go ahead with adding more fields. I think we were trying to be sparse and not over-complicate things, but it sounds like we need more fields to implement this properly! |
adding: reading over the comments, I think the thought was that ambient material may behave more like what people expect when they call I guess I'm also wondering if it's appropriate for (small edit just for clarity) |
I vaguely remember coming to similar conclusions 2 years ago when we were working on webGL for GSOC. As I recall it was just going to be a larger project than we had the time to solve, so we punted on this work. |
@kjhollen and @aferriss thanks for these insights! @ShenpaiSharma and I had discussed a less ambitious approach, which sounds like what you're wondering about @kjhollen: to remove the parameters for the material methods to clarify:
This would be simpler to implement, as no new fields would need to be added, nor would the shaders need to be modified. This approach, however, still would not allow for material property and color combinations that are possible in Processing. Without storing colors separately, it looks like we'd still need use only one material at a time. EDIT: I had initially written that perhaps a color could be passed in specularMaterial in place of using specularColor(), but I realized that specularColor is tied to lights, not materials. |
Feature Implemented -- Support for Multiple materials for geometryTagging @kjhollen So finally, I and @calebfoss have decided to move away from the current overwriting of fill colors to the geometry, towards the approach that Processing uses where the material has different color properties (ambient, emissive, specular) that all contribute separately to the lighting of the surface. So we have implemented a few new uniforms (uSpecularMatColor, uAmbientMatColor, uEmissiveMatColor) which store the RGB colors and fill the geometry with different color properties and thus contributing separately to the lighting of the surface. Here are the p5.js examples showing the multiple material properties for the geometry:
|
How would this new feature help increase access
Most appropriate sub-area of p5.js?
Details:
I'm currently working on improving the material documentation.
The current documentation for
ambientMaterial()
does not mentionfill()
. I'm wondering if the two are equivalent since they have identical behaviour. See here for live demo.I.e. is
fill(255, 0, 0)
the same asambientMaterial(255, 0, 0)
?If they are equivalent, I would like to mention this in the documenation.
Link to
fill
(WEBGL) source code.Link to
ambientMaterial
source code.The text was updated successfully, but these errors were encountered: