Order of execution

--This is 101 type stuff but I'm half way through the nature of code and this is driving me insane...I guess my problem was I made everything black and white so I didn't notice till yesterday why this is happening. The first object drawn in the draw()method is the background and the second and third should be in front of this....whenever I design something from this logic is seems to work out but when i copy the below example of a fill covering the other two objects it is still in the background. I posted the code....I'm pretty sure its something with the fill() and stroke() being messed up but I can't figure out why. Please clear this up for me. The way the below code is written the ellipse on the bottom should cover up the other two objects and we should just see the line peaking out. However the blue stroke circle is still on top, WHY? Thank you in advance but I just re read to books on the subject and neither one shed light as to why this is happening. Thanks.

void setup(){
  size(600,600,OPENGL);
  smooth(8);
}
  void draw(){
  background(0);

  stroke(36,162,159,255);
  strokeWeight(4);
  noFill();
  ellipse(width/2,height/2,50,50);

  stroke(255,255,255,255);
  strokeWeight(2);
  line(width/2,height/2,width,height/2);
  //this should cover up the top object!!
  noStroke();
  fill(255,78,93,255);
  ellipse(width/2,height/2,200,200);
}

Answers

  • _vk_vk
    edited August 2014

    Don't know why also, but it only happens in OPENGL and P3D, neither JAVA2D, P2D (this last I believe is opengl as well) have the same issue.... Maybe something with z positioning.

  • looks like a bug to me.

  • This seems to be an OpenGL issue. If you switch to Java2D (the default renderer) or P2D (if you still want hardware acceleration), the problem goes away. It seems to be a difference between 2D and 3D renderers.

    Specifically, the stroke (but not the fill) from the first ellipse appears despite having been drawn over.

    Minimal code example:

    void setup() {
      //Renderer makes the difference - switch to P2D to fix problem
      size(400, 400, OPENGL);
      //This isn't necessary, but it makes it easier to look at
      smooth(8);
    }
    
    void draw() {
      background(127);
    
      //Draw an ellipse with both stroke and fill
      stroke(255);
      fill(0);
      ellipse(width / 2, height / 2, 50, 50);
    
      //Draw another ellipse on top of it
      fill(255, 0, 0);
      ellipse(width / 2, height / 2, 100, 100);
    
      //Result: the first ellipse's stroke (but not the fill) is
      //visible despite having been drawn over
    }
    

    It looks like this problem (bug?) appeared between versions 2.0a4 and 2.0a6 (I don't have a copy of 2.0a5). Coincidentally, this happens to be the same time frame that parameterized smooth() was introduced. There were 600 commits between these releases, so I'm not going to track down exactly where the issue came from...

    I'm not sure if the same issue applies to other shapes, such as rectangles, lines, etc. Unfortunately, all of my OpenGL sketches have mysteriously stopped working, so I can't conduct further tests at the moment...

  • edited August 2014

    ok thank goodness I was about to jump off a bridge thanks guys...

    for the time being i could use P2D but the bigger problem is it is not as fast as P3D or OPENGL....I was planning on making some pretty complex animations...so no one knows of a work around?

    btw just opened processing 3 and its still an issue there....if it were a bug though wouldn't someone have caught it by now.....i tried putting all the objects in different classes and it still didn't work

  • In JAVA2D and P2D the draw operations are drawn in the order they are executed. This is not the case in 3D as those furthest from the viewpoint have to be drawn first.

    There is your problem, the ellipse is not being drawn on top of the first ellipse they are being drawn at the same distance from the viewer. Also in OpenGL drawing the stroke of the ellipse is a separate operation from drawing the fill so in effect you have four operations

    Draw fill ellipse 1
    Draw stroke ellipse 1
    Draw fill ellipse 2
    Draw stroke ellipse 2
    

    but since they are all at the same z order then the fills are being done before the strokes i.e.

    Draw fill ellipse 1
    Draw fill ellipse 2
    Draw stroke ellipse 1
    Draw stroke ellipse 2
    

    Here is one solution - not elegant and difficult to implement in a large animation.

    void draw() {
      background(127);
    
      //Draw an ellipse with both stroke and fill
      stroke(255);
      fill(0);
      ellipse(width / 2, height / 2, 50, 50);
    
      translate(0,0,-0.05);
      //Draw another ellipse on top of it
     fill(255, 0, 0);
      ellipse(width / 2, height / 2, 100, 100);
    
      //Result: the first ellipse's stroke (but not the fill) is
      //visible despite having been drawn over
    }
    

    for the time being i could use P2D but the bigger problem is it is not as fast as P3D or OPENGL....I was planning on making some pretty complex animations

    Are you sure because P2D also uses OpenGL at least in Processing 2, and if you get 50+fps will the user notice it.

  • edited August 2014

    i forgot to mention this, what makes the behavior seem buggy to me is that waht @quark mentioned shouldn't be necessary. opengl uses the depth buffer to figure out what is draw on top of what. it can be disabled with hint(DISABLE_DEPTH_TEST). but that's not working either. possibly that hint broke with one of the releases?

  • I encountered this bug before and it's rather annoying. Strokebug

    Looking forward to an easy fix...

  • try this:

    hint(DISABLE_OPTIMIZED_STROKE);

    i searched through the bug data base and found this: https://github.com/processing/processing/issues/2410

    it's exactly the problem you described. imho this is utterly unacceptable for default behavior, but it seems the decission was made already.

  • @kritzikratzi well spotted.

    It seems that this hint will degrade P3D performance so it might be worth staying with P2D

  • So moving objects in z space hadn't worked either....and the disable option does slow it down....I'm using physics system in the real patch...maybe I did the translates wrong...so much more to learn...but I did translate(0,0,-1) on the furthest object and then (0,0,0); on the closest but it still drew the furthest object on top of the closest...

  • Are you sure that -1 isn't closer than 0? Does the z axis increase towards or away from the front?

  • translate is cumulative i.e. move from the current position; so translate(0,0,0) means stay where you are. See the example above.

Sign In or Register to comment.