Default camera view changed in v1.9?

[komatebe]

Most appropriate sub-area of p5.js?

• Accessibility
• Color
• Core/Environment/Rendering
• Data
• DOM
• Events
• Image
• IO
• Math
• Typography
• Utilities
• WebGL
• Build Process
• Unit Testing
• Internalization
• Friendly Errors
• Other (specify if possible)

p5.js version

1.9

Web browser and version

All

Operating System

All

Steps to reproduce this

Has the default camera view in WEBGL mode changed in the latest 1.9 version of p5js?

I have noticed a significant difference, and it seems that any sketches created before version 1.9 would require reprogramming to work correctly.

Steps:

1. Use this code in v1.9
2. Use this code in v1.8
3. Spot the difference

Snippet:

function setup() {
  createCanvas(400, 400, WEBGL);
	noStroke();
}

function draw() {
  background(0);
  for(z=0;z<300;z+=50){
    push();
    translate(0,0,z);
    torus(50+z/5,5);
    pop();
  }
}

[welcome]

Welcome! 👋 Thanks for opening your first issue here! And to ensure the community is able to respond to your issue, please make sure to fill out the inputs in the issue forms. Thank you!

[davepagurek]

This was an intentional change which is hopefully minor for new sketches. The change was to move from a fixed field of view, which requires the camera position to change when the canvas size changed, to a variable field of view, which left the camera position in place. There are some instructions here on how to call perspective() with a fixed field of view again: https://p5js.org/reference/#/p5/perspective

Everything at z=0 should look the same as before though!

[inaridarkfox4231]

Please also refer to #6611. The cause is #6216.

[inaridarkfox4231]

@iadarshrawat We're talking about how it looks, not whether it works. If you don't understand what's being discussed, don't participate in the discussion.

[inaridarkfox4231]

Simply put, the default value of eyeZ is now 800. As a result, the appearance changes when sketching a small canvas. If you specify camera settings concretely, the problem will not occur, so that is the only countermeasure you can take now.

As you can see from #6611, many examples of reference page were broken. I have modified most of them accordingly using the method I just described.

[inaridarkfox4231]

Also, isn't the example backwards? This is what happened in my environment. Well, the environment doesn't matter...

ver1.9.0

ver1.8.0

In any case, if you want to achieve the desired look with the current specifications, please specify the camera settings specifically.

[komatebe]

Hi guys, thank you for the clarification!
Your detailed explanation was very helpful. I don't mind changes as long as they are intentional 😁.
Perhaps adding a small footnote on the camera documentation page about this change would be a good idea?
This change looks like a good improvement.
Also, @inaridarkfox4231 you are right: I have been using flipped examples. Sorry for the confusion.

[inaridarkfox4231]

I don't care about the example order as it is a trivial matter.

Perhaps adding a small footnote on the camera documentation page about this change would be a good idea?
This change looks like a good improvement.

In #6620, I added descriptions to clarify that eyeZ is 800 in several places in the camera reference. If this is not enough, I will consider adding more, but please carefully review the content first.

But the problem is, they won't know that unless they look at the reference page. They may not even realize that it's because the camera's default settings have changed.

Since changing the camera defaults is obviously a destructive specification change, I personally think it would be good if such contents were notified in an appropriate manner when updating the version. That will be a challenge for the future. It is also important that the person making the change has this awareness. I think the problem is that it was missing this time, personally.

If you're on Twitter, you can also tweet to spread the word that the camera default has been changed.

It would be also a good idea to have it brought up in a p5 study session (p5勉強会).

[komatebe]

This change is presented as a fix. But it changed the way how all previous p5 WebGL sketches work.
This should have been mentioned with bold letters along with suggestions to either redo sketches or use your perspective fix. The only thing I can do now is to tweet. And I will.

But I am unsure about adding:

perspective(PI/3, 1, 5*sqrt(3), 500*sqrt(3));

...to fix the camera example #6620.

It makes the example work but also sends the wrong message that using the camera requires setting the perspective, too. I prefer to keep it simple.
The code has been changed, the decision has been made, and examples should be rewritten.

I don't remember how the example looked before, but something like this:

camera(0, 0, 300 + sin(frameCount * 0.03) * 200, 0, 0, 0, 0, 1, 0); 

...is enough to make it work again. As soon as someone fixes the strokeWeight too (but you know that already).
🤯 This just got more complicated than I thought...

Cheers :-)

[inaridarkfox4231]

You can see the original example by going to the reference page now.

It makes the example work but also sends the wrong message that using the camera requires setting the perspective, too. I prefer to keep it simple.
The code has been changed, the decision has been made, and examples should be rewritten.

Unfortunately, with the current specifications, it is not enough to change just the camera to get intended behavior. Because just setting the camera doesn't change the fov. In the previous spec, fov was always fixed at PI/3, but in the current spec, eyeZ is 800, so it is set accordingly. What happens then is that the smaller the canvas, the smaller the fov.

This resulted in the appearance of some reference example being unnecessarily enlarged. Specifically, things like debugMode.
debugMode
In the debugMode example, only the camera is set, so the situation just described occurs. Therefore, I changed the fov. I can't think of any other way. How would you fix it? As of now, the reference page examples are still broken. Why not check it out for yourself first?

The expression "wrong message" is wrong. With the current specs, if you only change the camera, you will fall into the fov trap. This was not the case before. This is because most people set their camera settings depending on the canvas size. However, that is now a thing of the past. The only way to avoid this is to establish the use of perspective() as the new standard.

To convey this, I've modified the example accordingly. Using perspective() is no longer unavoidable. It is true that it is inconvenient. But there's nothing I can do.

Frankly, I hate this change. I think it is extremely unnatural to have to revise so many examples. All we can do now is better understand camera specs than ever before.

p5.js webgl is no longer suitable for beginners.

[inaridarkfox4231]

I don't remember how the example looked before, but something like this:

camera(0, 0, 300 + sin(frameCount * 0.03) * 200, 0, 0, 0, 0, 1, 0);

...is enough to make it work again. As soon as someone fixes the strokeWeight too (but you know that already).
🤯 This just got more complicated than I thought...

Which example is this about? I won't know unless you post the link. It's that easy, right? I can't debate, so I can't comment for this.

[komatebe]

#6620

[inaridarkfox4231]

I also tried to spread the word by tweeting. However, the people who responded only gave fav. He won't RT. In other words, it wouldn't spread, so it was no good. It's no good unless someone with a lot of followers who RT does it.
作例の修正が終わりました。
レファレンスの書き換えなどやることが多そうです...