react-three-renderer icon indicating copy to clipboard operation
react-three-renderer copied to clipboard

(getting started example): Material "disappears" after ~10 seconds

Open ashtonsix opened this issue 9 years ago • 18 comments
trafficstars

Not sure whether this is relevant to three or react-three-renderer though this issue is particularly boggling to me.

When running the getting started example the material "disappears" after a few seconds. Small changes to the scene affect how long it takes until the change:

  • default ~5 seconds
  • swap meshBasicMaterial for meshPhongMaterial ~8 seconds
  • add second cube ~6 seconds
  • swap boxGeometry for sphereGeometry ~10 seconds

demo

Code

// using redux instead of this.setState
// is equivalent - error still occurs when using this.setState
const Scene = connect(
  state => ({cubeRotation: new THREE.Euler(..._.range(3).map(() => state.meta.age * 0.01))})
)(
class Scene extends React.Component {
  constructor(props, context) {
    super(props, context)

    this.cameraPosition = new THREE.Vector3(0, 0, 5)
    this.firstCubePosition = new THREE.Vector3(0, 0, 0)
    this.secondCubePosition = new THREE.Vector3(2, 0, 2)
  }

  render() {
    const width = window.innerWidth
    const height = window.innerHeight

    const box = i => (
      <mesh
        position={this[i ? 'secondCubePosition' : 'firstCubePosition']}
        rotation={this.props.cubeRotation}
      >
        <boxGeometry
          dynamic={false}
          width={1}
          height={1}
          depth={1}
        />
        <meshPhongMaterial
          color={0x00ff00}
        />
      </mesh>
    )

    return (
      <React3
        mainCamera="camera"
        width={width}
        height={height}
        onAnimate={() => store.dispatch('TICK')}
      >
        <scene>
          <perspectiveCamera
            name="camera"
            fov={75}
            aspect={width / height}
            near={0.1}
            far={1000}
            position={this.cameraPosition}
          />
          <pointLight
            color={0xffffff}
            position={this.cameraPosition}
          />
          <ambientLight
            color={0x111111}
            position={this.cameraPosition}
          />
          {box(0)}
          {box(1)}
        </scene>
      </React3>
    )
  }
})

There's nothing (except the visual change) to indicate a problem occurred.

ashtonsix avatar May 22 '16 23:05 ashtonsix

That's very strange. Which browser and which version of react-three-renderer / threejs / react ?

toxicFork avatar May 23 '16 22:05 toxicFork

Wow, tested in chrome and I get similar problems, but funnily on firefox it's all fine. WTF??

toxicFork avatar May 24 '16 08:05 toxicFork

Also confirming that it works fine in Edge and Internet Explorer.

toxicFork avatar May 24 '16 08:05 toxicFork

OK. It looks like on Chrome it's spending an awfully long time on getting stack traces for prop type validation errors... and somehow that's making it miss some frames for some very strange reason. On other browsers this does not happen, also if you serve with e.g.

new webpack.DefinePlugin({
    'process.env': {
      NODE_ENV: '"production"',
    },
  }),

Then prop types will not be checked and it's all fine. I'm wondering if I should try to somehow use a stackless error at least for the react-three-renderer internal prop type checking...

toxicFork avatar May 24 '16 08:05 toxicFork

@toxicFork, I just tried out the Simple example with React 15.1.0 and react-three-renderer 2.0.1 on Chrome 50.0.2661.102 and it gave me the following warnings.

image

I looked at the checkDebugId() function and it checked if it is not in the production environment:

function checkDebugID(debugID) {
  process.env.NODE_ENV !== 'production' ? warning(debugID, 'ReactDebugTool: debugID may not be empty.') : void 0;
}

I turned it on using webpack.DefinePluginand my error was gone, might it be related to this issue?

imjasonmiller avatar May 24 '16 09:05 imjasonmiller

I couldn't reproduce the debug id error but it could be a clue! I will have more time this evening UK time to take a look.

toxicFork avatar May 24 '16 09:05 toxicFork

@toxicFork Using react 15.0.2, react-three-renderer 2.0.1 & chrome 50.0.2661.102.

Also noticed the problem goes away in production mode & other browsers.

@imjasonmiller Tempted to say no, I tried setting NODE_ENV to "development" explicitly though the problem still occurred.

Here's another example with 3 pointLights (0x666666, 0x333333, 0x333333) and 1 ambientLight (0xaaaaaa). When the problem occurs the effect is equivalent to deleting the ambientLight.

I don't think this is exactly what's happening in the previous example though. The point light is brightest in that example. In this one you can also see the Earth retains a blue tint when the lights go out instead of the color being stripped. Also the objects don't completely blink out so much (though I believe this is an unrelated issue caused by the camera's near value being too low)

demo

ashtonsix avatar May 24 '16 10:05 ashtonsix

This sounds like this chrome issue: mrdoob/three.js#8666

But also getting ton of these messages in chrome and firefox

debugId may not be empty

jardakotesovec avatar May 24 '16 15:05 jardakotesovec

It looks like "debugId may not be empty" came from a newer version of React 3 renderer. I'm using an older version of r3r in another project and have no issues.

AndrewRayCode avatar May 24 '16 18:05 AndrewRayCode

And a newer version of React :) I think 15.1.

toxicFork avatar May 24 '16 18:05 toxicFork

OK, I fixed the _debugId issues on #77 , will keep an eye on the weird chrome lighting issue still

toxicFork avatar May 28 '16 14:05 toxicFork

Still seeing the issue in production mode using the latest React 15.1.0 and R3R 2.1.3. I also see a secondary error that says "invariant requires an error message argument."

The problem goes away in development mode.

screen shot 2016-06-15 at 10 42 17 am

Robinnnnn avatar Jun 15 '16 14:06 Robinnnnn

Hmm... Okay I will fix this asap, looks like I forgot to wrap a call in dev flag checks, sorry about that

On Wed, 15 Jun 2016, 15:46 Robinnnnn, [email protected] wrote:

Still seeing the issue in production mode using the latest React 15.1.0 and R3R 2.1.3. I also see a secondary error that says "invariant requires an error message argument."

The problem goes away in development mode.

[image: screen shot 2016-06-15 at 10 42 17 am] https://cloud.githubusercontent.com/assets/12162433/16084324/620d8046-32e6-11e6-8309-ae08920cdd8e.png

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/toxicFork/react-three-renderer/issues/74#issuecomment-226210139, or mute the thread https://github.com/notifications/unsubscribe/AA0iLWbSFOWoK554NhQhe76d4gj3vqrOks5qMBA_gaJpZM4IkGvC .

toxicFork avatar Jun 15 '16 14:06 toxicFork

@Robinnnnn can you please provide a link to a repro build? I could not reproduce this on my end

toxicFork avatar Jun 15 '16 21:06 toxicFork

I also have not seen this issue with latest versions, including dev build.

jardakotesovec avatar Jun 16 '16 04:06 jardakotesovec

Apologies with the delayed update.

The issue was my fault. While I was minifying my code, I never set NODE_ENV to production (was using testing instead for a temporary testing server), and was being thrown the following error:

screen shot 2016-06-20 at 1 47 16 pm

This then caused the ReactDebugTool error when trying to launch a 3D scene. Everything was fixed after switching to modes to production.

TL;DR Ran into an edge case using minified code without NODE_ENV=production

Robinnnnn avatar Jun 20 '16 17:06 Robinnnnn

@ashtonwar do you still see this issue?

toxicFork avatar Jul 18 '16 20:07 toxicFork

@toxicFork I'll test sometime later this week

ashtonsix avatar Jul 18 '16 20:07 ashtonsix