Fix #1 - Persistent 3D tracer waveforms

[trinitronx]

Some simple modifications to where and how often the background() is redrawn can fix the draw persistence behavior 😸

Not sure how to fix the blue color's brightness to behave like the original YouTube video. That is to say: There is now no difference between the 3D "scan" line and the persisted drawn trails.

[fadookie]

Thanks for the attempt. I'm hesitant to merge this as-is because it breaks the 3D camera movement, it feels very choppy and clears the existing geometry. Maybe we can find a different solution.

[fadookie]

So the simpler 3D drawing technique I was using in 0d9e9db still works:

Maybe we just need to go back to basics and start over on the drawing code. I had a 3D mesh version of this that looked pretty cool but I'm not sure why it stopped drawing the faded lines.

[fadookie]

This is the commit that appears to have broken the drawing code on processing 3:
372a9cc

The only big difference I see is I switched from TRIANGLE_STRIP to QUAD_STRIP - maybe the API for this changed subtly in 3.0? Could always go back to tri strips again.

[trinitronx]

Thanks for the attempt. I'm hesitant to merge this as-is because it breaks the 3D camera movement, it feels very choppy and clears the existing geometry. Maybe we can find a different solution.

Yeah, I'm a newbie at Processing 3 but it's the only solution I could figure out so far to get persistent waveforms. It creates the problem of needing to clear the background on camera movement or perspective changes. Not sure how this problem is solved usually. The backroundRedrawFrameDivisor variable can be tweaked to try and adjust the choppiness.

There's probably a better way to do this. I'm not sure how to persist drawn 3D objects, but maybe there is a way to do 3D transforms when changing camera perspective. I'm not too familiar with the differences and 3D objects in Processing like TRIANGLE_STRIP vs. QUAD_STRIP. I only just started with the Processing 3 tutorial recently and it was showing the background() draw trick in 2D.

That screenshot looks pretty good! I like the lighting and shadows effect. I was experimenting with using different blendMode toggles in the zPosition loop and got something that looked interesting:

diff --git a/Super3dvisualizer.pde b/Super3dvisualizer.pde
index c71aba7..311af14 100644
--- a/Super3dvisualizer.pde
+++ b/Super3dvisualizer.pde
@@ -37,6 +37,7 @@ float[][] geomBuffer;
 
 int mouseDraggedFrame = 0;
 static final int backroundRedrawFrameDivisor = 20;
+int blendModeToggle = 0; // initial blendMode(REPLACE)
 
 void setup()
 {
@@ -163,9 +164,22 @@ void draw()
   float redFactor = 30;
   float greenFactor = 0;
   float blueFactor = 200;
-  
+
   for (int zPosition = bufferStart + 1; zPosition != bufferStart;) {
 
+    if (zPosition == bufferStart + 1) {
+      // Toggle blendMode on each pass to yield slightly different colors for:
+      // 1) 3D "scan" line
+      // 2) Persisted drawn 3D tracer trail
+      if (blendModeToggle == 0) {
+        blendMode(SCREEN);
+        blendModeToggle = 1;
+      }
+      else {
+        blendMode(REPLACE);
+        blendModeToggle = 0;
+      }
+    }
     //;pow(geomBuffer[i + 1][band], power) * -1
    //println(bufferStart + " " + zPosition);

[trinitronx]

This is the commit that appears to have broken the drawing code on processing 3:
372a9cc

The only big difference I see is I switched from TRIANGLE_STRIP to QUAD_STRIP - maybe the API for this changed subtly in 3.0? Could always go back to tri strips again.

Just looked at the diff for 372a9cc and saw something that gave me a hunch, (maybe it's just because I don't understand yet the use of shape functions well enough). Does the order and placement of endShape() matter here with persistence of 3D shapes? I see the TRIANGLE_STRIP has changed levels within the two nested loops. Also, there's now two beginShape() calls:

1. beginShape(QUAD_STRIP);
2. beginShape(TRIANGLE_STRIP);

Do these need to have matching pairs of endShape() to go with them? If so, I'm not sure how Processing would know which is which, maybe it's missing something? How does the nesting level affect these shapes?

EDIT: I missed the second endShape() in the diff fold... oops! So maybe that's not an issue.

[fadookie]

Yeah so check the docs for beginShape. TRIANGLE_STRIP is a compressed way of specifying a bunch of adjacent triangles. QUAD_STRIP is for specifying adjacent quads. It's possible something changed in the drawing code for Processing 3 where some previous drawing technique no longer works for some reason.

I'm not sure why I changed the loop structure there. But I remember at one point I was doing each part of the mesh as a strip of triangles and switched to those wireframe lines at that commit I linked earlier.

I'd say for now it's probably easiest to switch back to rendering a simpler type of mesh using triangle strip wireframes based on the working commit I linked above.

[fadookie]

Alright I messed with this a bit today and was able to get it working by reverting back to a more normal technique for drawing triangle strips. I am going to close this PR since I think my solution in 7f8a255 works better with a moving camera. I also switched the camera to use PeasyCam which is hopefully a bit more user- and programmer-friendly. Thanks for giving me a kick in the butt to get this fixed!