A very simple THREE.js script.
It runs fine in this JSFiddle.
But if the following line of code:
controls = new THREE.OrbitControls(camera, renderer.domElement);
is commented out and the JSFiddle is re-run then no graphics are displayed. I ran equivalent code from a localhost html file with Chrome debugger but it showed no warnings or exceptions. Same behavior in Firefox. All runs done on a Windows 7 laptop.
So why does THREE.js seem to require an OrbitControls object in this example?
(I don't specifically need OrbitControl functionality in the app).
The problem is not from the controls but the camera. The .lookAt() take a vector so you need to call it as camera.lookAt(new THREE.Vector3(0,0,0));. Otherwise you invalidate the camera instance. If you comment out the controls and the camera.lookAt() in your fiddle it works.
Related
I am trying to achieve seamless objects next to each other in Three.JS which currently works fine on most devices / browsers but in some cases i'm experiencing difficulties. For example while using MacOS with the latest version of Google Chrome (and also Safari) the objects render with pixelated gaps in between that should not be there.
Bug occurs with all 3D Objects, GLTF models (left) and BoxGeometry (right):
While using the same Mac device but using Firefox everything renders as expected:
Sizes are exactly (1, 1, 1) and should fit exactly next to each other. I've also tried to scale it up to (1.05, 1.05, 1.05) but this didn't fix the problem, in fact it only got worse as applying scaling results in Z-fighting when textures are enabled.
I'm currently using R137 of Three.JS and made sure my application correctly applies window.devicePixelRatio so that should not be the problem either - is there any other renderer setting that i'm forgetting which could help resolve this rendering issue?
The behaviour for Android and Windows devices also works correctly. The used Android device has a devicePixelRatio greater than 2 and everything looks smooth there. I doubt it's a problem with my Mac GPU as it renders correctly with Firefox; is this a bug of the browser maybe, and is there something we can do about it ourselves?
Hopefully this is not a duplicate, i couldn't find any solutions/answers to this.
EDIT:
I've found out that EffectComposer (for FXAA) are causing these problems for Google Chrome / Safari on Mac devices. Which is weird because it works completely fine on all other devices. I'm currently still looking for a way to fix this. If anyone had problems in the past with EffectComposer for Mac and managed to fix them please share your solution with us. When replacing FXAA shader with for example Sepia shader the same bugs occur, it doesn't seem to matter which shaders are being passed, anything pass from EffectComposer causes this.
I've made a fiddle: https://jsfiddle.net/ilanbentley/g3yxdvmh/3/
Note how the right side (EffectComposer) has buggy edges while the left side (Renderer) looks good (for Mac).
Somehow the code below is responsible for this buggy behaviour:
const renderPass = new RenderPass( scene, camera );
fxaaPass = new ShaderPass( FXAAShader );
composer2 = new EffectComposer( renderer );
composer2.addPass( renderPass );
composer2.addPass( fxaaPass );
NOTE: It appears I oversimplified my initial question. See below for the edit.
I'm trying to combine the technique shown in the clipping/stencil example of Three.js, which uses the stencil buffer to render 'caps' when clipping geometry, with an EffectComposer-based rendering pipeline, but I am running into some difficulties. A fiddle demonstrating the problem can be found at https://jsfiddle.net/2vc76ajd/1/.
The EffectComposer has two passes: a RenderPass and a ShaderPass using CopyShader (see code below).
composer = new EffectComposer(renderer);
composer.addPass(new RenderPass(scene, camera));
var shaderPass = new ShaderPass(CopyShader);
shaderPass.enabled = false;
composer.addPass(shaderPass);
The first renders the scene as usual, the latter merely copies the rendertarget onto a fullscreen quad. If I disable the ShaderPass everything works as intended: the geometry is clipped, and cutting planes are drawn in a different color:
When the ShaderPass is enabled by clicking the 'copy pass' checkbox in the upper right, however, the entire cutting plane gets rendered, rather than just the 'caps':
Presumably there is some interaction here between offscreen render targets and stencil buffers. However, I have so far been unable to find a way to have subsequent render passes look the same as the initial render. Can anyone tell me what I am missing?
EDIT: While WestLangley's answer solved my initial problem, it unfortunately doesn't work when you're using an SSAOPass, which is what I was doing before trying to simplify the problem for the question. I have posted an updated fiddle at https://jsfiddle.net/bavL98hf/1/, which includes the proposed fix and now toggles between a RenderPass or an SSAOPass. With SSAO turned on, the result is this:
I have tried setting stencilBuffer to true on all the render targets used in SSAOPass in addition to the ones in EffectComposer, but sadly that doesn't work this time. Can anyone tell me what else I am overlooking?
I am trying to take a 'snapshot' of a babylon3d scene ... in other words: I am trying to clone a babylon3d canvas when a user presses a button, and then append the new <canvas> to the <body> .. Sometimes it works, but other times it does not.
However, if I use a simple canvas (ie. by using fillRect), the cloning/appending always works as expected.
I have set up a test on plunker to demonstrate my problem: plunker: press the button over and over again to see how sporadic it behaves when there is a babylon scene. AND NOTE: You can toggle between the simple canvas and the babylon canvas from within the _jquery(document).ready(...) handler.
thanks, Shannon
This is because from version 2.3.0 of Babylonjs :
Engine now initialize WebGL with preserveDrawingBuffer = false by default.
You need to initialize the Engine by passing a {preserveDrawingBuffer: true} object as third parameter.
Forked plnkr
But this will unfortunately kill your canvas' performances.
See more about it here.
I'm not really a specialist of Babylonjs, and I didn't find a way to make a call from scene.render method where we could use the flag method proposed by
#CapsE. But there is a BABYLON.Tools.CreateScreenshot(engine, camera, size) method, which will make a downloadable png from your scene ; maybe this could help you.
How can I dynamically turn on and off antialiasing and shadows in WebGLRenderer?
Simply changing the properties of anti-aliasing and shadowMapEnable does not work. I looked in the source and found a method updateShadowMap () but it was removed in release 69.
UPDATE: OK, the answer to the second half of the question I found here
https://github.com/mrdoob/three.js/issues/2466
As a result the following code works fine:
renderer.shadowMapEnabled = false;
for(var i in tiles.children)
tiles.children[i].material.needsUpdate=true;
renderer.clearTarget( sun.shadowMap );
You can't enable/diable antialiasing from a WebGL context after creation. The only way is to create a new context and submit all the buffers and textures again.
So, ideally you would only need to create a new WebGLRenderer with the antialias boolean. This doesn't work yet thought, but I'm working to have it working ASAP.
I'm trying to make a simulation consisting of many lines. Up until now I had Three.js v45 and Trackball Controls and it worked fine.
I then tried to implement my lines in a buffer geometry (as in this example: http://fzwoch.project-sheol.org/three.js/examples/webgl_buffergeometry_lines.html)
but for that I needed to update to the newer Three.js build. And Trackball Controls doesn't work anymore! Am I missing something? How can I get both to work?
Thank you,
Kasia
First have you noticed that the controls changed location? Now you have to add in your html file:
<script src="three.js/examples/js/controls/TrackballControls.js"></script>
You should also check the migration notes https://github.com/mrdoob/three.js/wiki/Migration to see if anything else changed for your code from the r45 release to r55 (current).