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.

Sign up for GitHub

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

Already on GitHub? Sign in to your account

Jump to bottom

Strange behaviour in development build with Three.js #7555

Closed
coelhucas opened this issue Jan 13, 2022 · 1 comment
Closed

Strange behaviour in development build with Three.js #7555

coelhucas opened this issue Jan 13, 2022 · 1 comment
Labels
Stale Inactive issues

Comments

@coelhucas
Copy link

coelhucas commented Jan 13, 2022 •
edited

馃悰 bug report

Given an almost empty project (I have three.js and parcel as dependencies), for some reason Three JS objects lose some of their fields in development mode. I noticed that some methods from WebGLRenderer, for instance, such as setAnimationLoop doesn't exist (it works only in generated bundles)

I don't have any kind of babel config or anything else. And although I saw this behaviour in Three.JS it may happen with other dependencies I guess.

Please let me know if I can help with any more information and if you can guide me through some way on fixing it myself.

馃 Expected Behavior

Their small "hello world" example should work just fine without any workarounds, as it does in builded version, without "omitting" any of their properties and methods

馃槸 Current Behavior

Lots of Three.js objects fields just "disappear". I made a small diff of some properties that were "lost" in development for WebGLRenderer as an example. The array below contain all missing properties.

[
  "debug",
  "outputEncoding",
  "renderLists",
  "xr",
  "forceContextRestore",
  "getDrawingBufferSize",
  "setDrawingBufferSize",
  "getCurrentViewport",
  "getViewport",
  "getScissor",
  "getScissorTest",
  "setOpaqueSort",
  "setTransparentSort",
  "compile",
  "setAnimationLoop",
  "getActiveCubeFace",
  "getActiveMipmapLevel",
  "getRenderTarget",
  "setRenderTargetTextures",
  "setRenderTargetFramebuffer",
  "copyFramebufferToTexture",
  "copyTextureToTexture",
  "copyTextureToTexture3D",
  "initTexture",
  "resetState"
]

In builded bundles it works just fine and keeps all original fields

Update:
The issue stopped and came back in some iterations but was mostly happening. Tested with Chrome, Firefox and Safari

馃拋 Possible Solution

I have no clue so far about what might be causing it and if is it really a Parcel issue, but I am willing to help if I am able to. It seems related to the same issue in #5138. I also gave a look at some three js implementations of some of these fields that "disappear" when using Parcel and it really doesn't seems to be something on their side.

馃捇 Code Sample

<!DOCTYPE html>
<html>
    <head>
        <title>hei</title>
    </head>
    <body>
        <script type="module" src="index.js"></script>
    </body>
</html>
import * as THREE from "three";

let camera, scene, renderer;
let geometry, material, mesh;

init();

function init() {

    camera = new THREE.PerspectiveCamera( 70, window.innerWidth / window.innerHeight, 0.01, 10 );
    camera.position.z = 1;

    scene = new THREE.Scene();

    geometry = new THREE.BoxGeometry( 0.2, 0.2, 0.2 );
    material = new THREE.MeshNormalMaterial();

    mesh = new THREE.Mesh( geometry, material );
    scene.add( mesh );

    renderer = new THREE.WebGLRenderer( { antialias: true } );
    renderer.setSize( window.innerWidth, window.innerHeight );
    renderer.setAnimationLoop( animation ); // -> Propert "doesn' exists" only when using Parcel in development server
    document.body.appendChild( renderer.domElement );

}

function animation( time ) {

    mesh.rotation.x = time / 2000;
    mesh.rotation.y = time / 1000;

    renderer.render( scene, camera );

}

Given the above and having both three.js and parcel, one may run yarn parcel index.html to replicate this issue

馃實 Your Environment

Software Version(s)
Parcel 2.2.0
Node 14.18.2
npm/Yarn 1.22.15
Operating System macOS
@CalamityAdam CalamityAdam mentioned this issue Feb 2, 2022
Open
@github-actions
Copy link

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs.

@github-actions github-actions bot added the Stale Inactive issues label Jul 12, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Stale Inactive issues
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@coelhucas