Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Circular dependency in WebGLCubeRenderTarget.fromEquirectangularTexture #19137

Closed
looeee opened this issue Apr 15, 2020 · 6 comments · Fixed by #19138
Closed

Circular dependency in WebGLCubeRenderTarget.fromEquirectangularTexture #19137

looeee opened this issue Apr 15, 2020 · 6 comments · Fixed by #19138

Comments

@looeee
Copy link
Collaborator

looeee commented Apr 15, 2020

The last circular dependency in the library is:
WebGLCubeRenderTarget -> CubeCamera -> WebGLCubeRenderTarget

This is caused by WebGLCubeRenderTarget.fromEquirectangularTexture, which was added in #16671 following discussion in #15331 (comment).

This is the last blocker for closing #6241.

To remove this, we could extract .fromEquirectangularTexture to an external utility (or maybe move it to CubeTexture?). I'm not sure if it's worth doing so just to avoid a circular dependency though.

@WestLangley, @Mugen87 and @mrdoob - you guys were involved in adding this method. Do you think we need to fix this circular dependency? If not, then we can probably just mark as "won't fix" and close #6241.

@Mugen87
Copy link
Collaborator

Mugen87 commented Apr 15, 2020

Do you think we need to fix this circular dependency?

As far as I understand, this circular dependency is not harmful. However, circular dependency is always an indicator that something with the class design is not right. This issue can only be solved by refactoring.

I've already though about this in the past and my preferred option is to inject the internal render target of CubeCamera to solve this issue. So instead of:

var camera = new THREE.CubeCamera( 1, 1000, 256, { format: THREE.RGBAFormat, magFilter: THREE.LinearFilter, minFilter: THREE.LinearFilter } );

we do this:

var renderTarget = new THREE.WebGLCubeRenderTarget( 256, { format: THREE.RGBAFormat, magFilter: THREE.LinearFilter, minFilter: THREE.LinearFilter }  );
var camera = new THREE.CubeCamera( 1, 1000, renderTarget );

I like latter one since the last two parameters of CubeCamera are obviously intended for WebGLCubeRenderTarget. And since users usually use cubeCamera.renderTarget to access the internal render target, they could instead refer to the variable created on app level (so just renderTarget).

@looeee
Copy link
Collaborator Author

looeee commented Apr 15, 2020

Yeah, that looks better to me. Passing in parameters intended for the render target to the CubeCamera constructor doesn't feel right.

@Mugen87
Copy link
Collaborator

Mugen87 commented Apr 15, 2020

If @mrdoob approves (and consider no other objections), I can make a PR with the change.

@Mugen87
Copy link
Collaborator

Mugen87 commented Apr 15, 2020

I've already made the PR so it's easier to see the changes.

@mrdoob
Copy link
Owner

mrdoob commented Apr 20, 2020

@Mugen87 Thank you! I'll review this week.

@Mugen87 Mugen87 added this to the r117 milestone May 2, 2020
@Mugen87
Copy link
Collaborator

Mugen87 commented May 12, 2020

@mrdoob /bump

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants