react-three-renderer
react-three-renderer copied to clipboard
(getting started example): Material "disappears" after ~10 seconds
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
meshBasicMaterialformeshPhongMaterial~8 seconds - add second cube ~6 seconds
- swap
boxGeometryforsphereGeometry~10 seconds

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.
That's very strange. Which browser and which version of react-three-renderer / threejs / react ?
Wow, tested in chrome and I get similar problems, but funnily on firefox it's all fine. WTF??
Also confirming that it works fine in Edge and Internet Explorer.
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, 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.

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?
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 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)

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
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.
And a newer version of React :) I think 15.1.
OK, I fixed the _debugId issues on #77 , will keep an eye on the weird chrome lighting issue still
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.

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 .
@Robinnnnn can you please provide a link to a repro build? I could not reproduce this on my end
I also have not seen this issue with latest versions, including dev build.
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:

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
@ashtonwar do you still see this issue?
@toxicFork I'll test sometime later this week