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

Check if PointsMaterial map is a WebGLRenderTarget. #8417

Closed
wants to merge 10 commits into from
Closed

Check if PointsMaterial map is a WebGLRenderTarget. #8417

wants to merge 10 commits into from

Conversation

vanruesc
Copy link
Contributor

When using a WebGLRenderTarget as a map for the PointsMaterial, the following warning will be logged to the console every frame: THREE.WebGLRenderTarget: .repeat is now .texture.repeat.

981e0a2 fixes this by checking if the given map is a WebGLRenderTarget.

2d4b856 takes care of a small TODO note. The canvas' clientHeight property doesn't need to be divided by 2 every frame. Now its stored as a local variable and will only be updated when the setSize method is called.

Using a WebGLRenderTarget as a color map for the PointsMaterial results
in console spam (THREE.WebGLRenderTarget: .repeat is now
.texture.repeat.).
Only update the half client height when setSize is called.
@WestLangley
Copy link
Collaborator

If I recall correctly, WebGLRenderTarget used to be texture. Now it has a texture.

It seems that the code pattern we should require now is

material.map = renderTarget.texture; // not material.map = renderTarget;

which, as far as I know, works.

This will simplify the code a bit -- and, IMHO, makes more sense.

@vanruesc
Copy link
Contributor Author

@WestLangley You're right; when I first ran into this issue, I simply used the texture property of the render target directly which worked just fine. However, all the post processing examples for instance directly use their render targets as textures. That's why I decided to follow that style.

Anyway, I support the proposed code pattern.

Btw: the WebGLRenderer already contains code that treats render target as special cases: https://github.com/mrdoob/three.js/blob/dev/src/renderers/WebGLRenderer.js#L2002-L2006.
I used that as reference for this PR.

@WestLangley
Copy link
Collaborator

Btw: the WebGLRenderer already contains code that treats render target as special cases:

Right. And that special case can be removed.

I expect the EffectComposer changes will cause a lot of breakage, so it is up to @mrdoob if he wants to go this route.

@mrdoob
Copy link
Owner

mrdoob commented Mar 20, 2016

Yep, I also support @WestLangley suggested code pattern. I think the code clean up is worth the breakage.

@mrdoob
Copy link
Owner

mrdoob commented Mar 20, 2016

Anyone up for doing the refactoring?

@vanruesc
Copy link
Contributor Author

I'd be glad to do that.

Just to be clear:

  • you want the WebGLRenderer to not treat WebGLRenderTargets as special cases anymore when they are used as maps (like here)
  • and all examples that currently use render targets as textures should be refactored to use the .texture property instead

Right? I'm not sure where the breakage would happen with this refactoring, though 😕

@WestLangley
Copy link
Collaborator

Right?

Right.

I'm not sure where the breakage would happen with this refactoring, though

It will break user's code. In which case it would be a good idea to test for WebGLRenderTarget/Cube and provide a warning to the user. The code should self-correct.

@vanruesc
Copy link
Contributor Author

Alright, I'm done.

All examples now use the texture property of render targets that are used as inputs.

I noticed that the following examples were already broken before these changes:

Additionally, the following examples seem to be broken in r76dev.

  • materials / standard (physically based rendering)
  • materials / envmaps / hdr

At least for me they fail to render the hdr envmaps (I checked with an untouched build of three-dev).

@mrdoob
Copy link
Owner

mrdoob commented Mar 22, 2016

@WestLangley looks good?

@WestLangley
Copy link
Collaborator

Looks good.

@vanruesc Perhaps the instanceof THREE.WebGLRenderTarget tests can be made only when textures are assigned, rather than every render loop. If so, merge now; fix later.

@vanruesc
Copy link
Contributor Author

I think it'd be possible to modify all materials that define explicit texture properties to use getters/setters instead. Checking for render targets could be done efficently this way and these changes could be reverted easily later on.

I'm not sure how to check custom shader texture uniforms efficiently, though, because they are updated every frame. Got any leads on this?

uniforms.envMap.value = material.envMap;
uniforms.flipEnvMap.value = ( material.envMap instanceof THREE.WebGLRenderTargetCube ) ? 1 : - 1;
uniforms.flipEnvMap.value = ( material.envMap && material.envMap.renderTargetCube ) ? 1 : - 1;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this just be material.envMap instanceof THREE.CubeTexture?
I wouldn't add renderTargetCube to Texture dynamically...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The WebGLRenderTargetCube has a Texture instance because it extends WebGLRenderTarget. CubeTexture is not involved in this check any way.

To replicate the original logic here, I had to resort to this awkward flag because there is no other way to know whether the texture at hand belongs to a WebGLRenderTargetCube.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see... I think we should figure out how to fix that first...

@mrdoob
Copy link
Owner

mrdoob commented Apr 9, 2016

Hmmm, this PR ended up having too many different changes. The refactoring is great but can't be merged because other things are not ready 😕

@vanruesc
Copy link
Contributor Author

Yea, I agree. It's kind of messed up at this point.

What do you think about the changes in the examples? 85a7aef should work with the current version of three right away. I could make a fresh PR out of that.

I'm a bit overwhelmed by the density of the WebGLRenderer class and I don't have enough time to dig through it to find a better solution. All I can offer right now is to open a new issue to outline the identified problem and keep hold of the details.

@mrdoob
Copy link
Owner

mrdoob commented Apr 10, 2016

What do you think about the changes in the examples? 85a7aef should work with the current version of three right away. I could make a fresh PR out of that.

That would be great!

@vanruesc
Copy link
Contributor Author

Continued in #8615.

@vanruesc vanruesc closed this Apr 12, 2016
@tschw
Copy link
Contributor

tschw commented Apr 14, 2016

Verdammt! Noch so'n irrer Deutscher der's nicht lassen kann den Renderer aufzuräumen... :)
[ EN: Damn! Yet 'nother Germaniac who can't resist to tidy up the renderer... :) ]

👍 I appreciate your efforts.

@vanruesc
Copy link
Contributor Author

@tschw Well, it's definitely worth every effort! Three is where it's at 😄

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

Successfully merging this pull request may close these issues.

None yet

4 participants