RendertargetTexture problem

Now I want to implement a function, in the current main scenario, create a new camera, and a new viewport (probably the canvas or RenderTargetTexture), the new camera captured by the elements to the new canvas, and you can also to manipulate, the new similar examples of website, I have achieved, but the effect is not obvious, seem to have shelter, what should I do

Hi @ranwei-001. Sorry for no replies. Have you made progress?

Not sure what “shelter” is. Same as “border”?

BJS RenderTargetTexture must stay within canvas element. It cannot be used as ANOTHER canvas on a webpage. It is a BJS texture… to be used on BJS materials/mesh… in same canvas. :slight_smile: It cannot travel to “DOM tree”.

If you need more help, please make playground demo showing problem, if possible. Not easy to do, when mixing HTML and webGL, I know. Good luck!

1 Like

Hi again. Ah yes, I know how to fix that.

Added lines 33-38 AND line 148. anymesh.alwaysSelectAsActiveMesh = true;

“True if the mesh must be rendered in any case (this will shortcut [bypass] the frustum clipping phase)”

Sorry that I took so long to understand issue. I hope this fixes it. Party on!

1 Like

Thank you very much. I really don’t know where you found it, but I didn’t find it

1 Like

That is understandable as it is not in BJS docs. You have a rather special scene… unusual.

The camera has an “area of view” called a “frustum” (sort-of cone shaped). It is defined with camera.fovMode, .fov, .minZ, and .maxZ. Frustum clipping is a great performance-enhancer, but can cause puzzles in multi-camera scenes.

You noticed that when a mesh departed the main camera frustum, BJS system decided to not-render departed mesh. So I went looking on BJS MESH class API… for something like “alwaysRender” or “ignoreFrustum”… things like that… and found something interesting-sounding, and tried it.

Your excellent playground demo… helped perfectly. AND, you improved that playground demo… for future users. Nice work! We make a good team, eh? :slight_smile:

Hey @ranwei-001… If you would, please delete your last two posts in…

Let’s talk HERE… about ways to make ALL your mesh… be set to alwaysSelectAsActiveMesh = true by default.

I have an idea. Testing…

interesting, i have an idea too, but i didnt know about frustum
wingnut u know pretty much, Its not as active without wingnut chronicle, I missed the rants so i started looking for alternatives and started code in phaser again in lack of other projects…

1 Like

Hi droggam! You should not abandon BJS, as it is a super-nice system. My BJS issues are not technical, but managerial. I miss TWC, too, but, the framework still rocks and always will, I hope.

What did I try?

Line 5… setting ALL mesh that happen in the scene… as alwaysSelectAsActiveMesh = true… by setting the default value on the base class of mesh… early in the playground.

It didn’t work… but it is likely a Wingnut mistake. (I know less than you might think) :smiley:

I’ll keep thinking. Help welcome.

Perhaps… put THIS… somewhere near the bottom of the scene code…

        for (mesh of scene.meshes)
            mesh.alwaysSelectAsActiveMesh = true;

…is a smooth/easy way. [pg#81] Caution: the “of” directive can cause troubles in older browsers, I hear. Might need a more-standard for-next loop… for certain browsers/ecma-script versions.

1 Like

haha put this afer bracket =)

  • Sorry, I have no right to delete the article