orbitControl() ignored on layer / createGraphics() WEBGL offscreen buffer

[ffd8]

Most appropriate sub-area of p5.js?

• [x] Core/Environment/Rendering
• [x] WebGL

Details about the bug:

• p5.js version: 1.0.0
• Web browser and version: Chrome 80.0.3987.149
• Operating System: MacOS 10.13.6
• Steps to reproduce this:

Have always wished there was an opacity option on background() when using WEBGL render (sneaky request in this bug issue) – so as a work around, I draw the WEBGL content to a layer using createGraphics(width, height, WEBGL) - then display this layer on a 2d canvas, allowing use of translucent/fading background(0, 15). Whil playing with a sketch, just realized that orbitControl() is ignored when applied to this offscreen buffer. Intended behavior or a bug?

Here's an example with both behaviors– toggle useLayer at top to see each: https://editor.p5js.org/ffd8/sketches/n2rIHPPv3

[DivyamAhuja]

orbitControl method works on p5 Instance so you can't call it from graphics object like lay.orbitControl() and it works for a p5 Instance as a whole not for specific renderer graphics object.

@stalgiag should orbitControl be made a method of renderer instead of p5 instance? or maybe all interaction method should be specific to graphics object?

[stalgiag]

I think that this could occur at the renderer level. What do you think @AidanNelson ?

[AidanNelson]

Hmmm... I think the one tricky part of this would be that mouse positions are handled on the instance level. So in a situation with multiple renderers, the mouse positions would be determined by the position in the canvas, rather than the offscreen graphics buffer. Not sure how big of an issue that would actually be, unless the canvas and offscreen buffer were drastically different aspect ratios, in which case you could always adjust the sensitivityXYZ settings. Now, in the situation of an offscreen WebGL graphics object being displayed inside a WebGL canvas (each of which has orbitControls applied) things might get a bit crazy, but how much of a use case is that, really? 🙃

[ffd8]

Seems like the general mouseX/Y mapped to the canvas width/height could continue to be used if moved to the renderer as one can always adjust the sensitivity when needed. Would be awesome if this could occur per render level – indeed weird and interesting things might occur if using orbitControl both on the offscreen graphics buffer... AND while drawing that textured plane... and further when having layers within layers within layers... of inception depth?? 🤪

[ffd8]

Quick belated followup on this since the past few semesters of p5 inputs – students love the 'faded leaving a trace' quality of drawing in 2D mode with a translucent background, ie. background(0, 10) – which doesn't work in WEBGL mode.. So I encourage them to draw their 3D content on a createGraphics layer, then display that within a 2D canvas with that fade active. Works for the most part, but then one loses the ability to interact (easily) with the rotation of said primitive/model. Of course one can then add their own variables and manually rotate things, it's just an instance of where they wonder why orbitControl() doesn't work for a given layer too. Perhaps another use case is if showing a 3D object/model simultaneously from the side/top/front views? If orbitControl() was all listening to the same mousedrag changes/coordinates, one could just add an additional rotation for those different views?