We are about to switch to a new forum software. Until then we have removed the registration on this forum.
Why is lights() not lighting sphere in a class in this example?
float th_6 = 0;
Orbital Orb_3;
void setup()
{
size(1280, 1024, P3D);
//Class initialization
Orb_3 = new Orbital();
}
void draw()
{
background(0);
lights();
noStroke();
translate(width/2, height/2, 0);
sphere(20); //lights work on this!
th_6=th_6+TWO_PI/360;
seq_D();
}
class Orbital
{
int A = 200; //diameter
float x, y, z;
float th = 0;
void Circle()
{
for(th=0;th<TWO_PI;th+=TWO_PI/360)
{
x=A*cos(th);
y=A*sin(th);
point(x, y, 0);
}
}
void Traj()
{
x = A*cos(th_6);
y = A*sin(th_6);
translate(x,y);
}
}
void seq_D()
{
strokeWeight(2);
rotateY(th_6);
stroke(255, 0, 255);
Orb_3.Circle();
Orb_3.Traj();
sphere(20); //lights DO NOT work on this!
}
Answers
Please edit post, highlight code, press Ctrl-o
Thanks for tip.
Added a noStroke() to make shading from light work on sphere:
@GLV -- good catch -- it doesn't have anything to do with a class, it seems like each
sphere()
needs there to benoStroke()
in order to have default lighting. In order to consistently isolate stroke/noStroke in your sketch try using pushStyle/popStyle.A few suggestions:
noStroke()
insetup()
-- then all your spheres will draw correctly without needing to remember to remove stroke each time.pushStyle()
/popStyle()
so that your later spheres don't all turn purple as well.Other thoughts:
Sketch:
Hello, Thanks for taking the time to provide great feedback! My background is embedded C with no object oriented programming. :) and :( ! I have been programming for a couple of months now with Processing and gradually transitioning from "procedural" to "object-oriented" and enjoying the ride. Converting all the code (1000s of lines and dozens of tabs!) I wrote for this and other projects to object-oriented and already seeing the benefits:
GLV
@GLV -- this is really beautiful work! Thank you for sharing the video.
I hope that the project is still going well.
@GLV --
Later, I found myself wondering if the noStroke() lighting behavior was actually bug and should be reported.
It looks like it is by-design -- however it can be confusing trying to light a sphere by trial-and-error.
The problem above was that your stroke weight / sphere distance was creating a mesh that completely covered your fill so that it couldn't interact with the lighting source.
Essentially:
Therefor, the only light-able spheres are: - filled - non-black - have no stroke - or have stroke that show fill through the mesh.
See demo sketch for examples. Out of these eighteen spheres with different settings, only four of them respond to the light source.
@jeremydouglass Thanks for the great demo! And excellent formatting as well. Only thing I did was add ortho() to settings to change the view. This was prompted by a friend looking at this and asking about this... which spawned off to another hour of discussion! Have a great new year!
Interesting discussion here
I always use sphere with noStroke();
But with stroke being active it would depend on the size of the sphere and maybe also on the value of sphereDetail how much actual fill area you see that reacts to light (as has been said)
I just wanted to mention size and sphereDetail() here as possible factors
Happy new year!
Chrisir
@GLV -- very glad that it was helpful! Good
ortho
tip.@Chrisir -- great point about
sphereDetail()
also affecting the mesh and how much surface the stroke covers -- at higher detail, there are more lines per unit of sphere surface. That would be a good thing to add to a revised demo -- possibly with sliders for: