Best practice for large 2d world in Three.js

[Continuities]

Hey everyone!

 

I'm playing around with Three.js for the first time, and looking for some pointers. I've chosen to use Three.js even though the game is 2d so that I can use the z-axis for easy parallax, camera zooming, and maybe some neat effects later on.

 

I'm building a game with a world that's much larger than the viewing area, with lots of entities that will often be outside of the viewport. Normally, I'd maintain a list of entities and draw them to the screen when they're positioned within the viewable area. With Three.js, however, you add a mesh to a scene once and then just update its position. Is it safe to just add everything and trust Three.js to optimize its rendering algorithms, or is it better to add and remove stuff from the scene as the viewport scrolls?

 

Cheers!

 

- Michael

[rich]

Not sure there is a black/white answer to this, as it depends on how many objects you've got in total, your target platform, how fast objects are likely to need to be created/destroyed, etc. If we're talking thousands of objects then simple logic should deduce that even if three.js is smart enough to not render them (which I'd assume it is) then you've still got them hanging around in memory. But against if you're only worried about desktop browsers this might even not be an issue anyway.

[Continuities]

Yeah, I'm targetting desktop. I'm aiming to streamline memory and processing so that I can simulate the gameworld, even outside of the viewport. I'm gonna be sad if I can't. I also assume that Three.js is smart enough to ignore meshes that fall outside the viewable area, but I haven't been able to find any confirmation of this.

[xerver]

Having used Three.js as a rendering engine for a 2d game, I would recommend against it. I ran into performance issues with large numbers of plane objects (which is what I used to display sprites).

 

Also, three.js does not do frustrum culling automatically for you; you will have to do that manually. Something like:

 

var frustum = new THREE.Frustum();frustum.setFromMatrix(new THREE.Matrix4().multiply(camera.projectionMatrix, camera.matrixWorldInverse));for (var i=0; i<objects.length; i++) {  objects[i].visible = frustum.intersectsObject( objects[i] );}

 

I found that the extra 3d calculations added too much overhead for a large 2D game (I was doing LTTP at the time). It is possible I was doing something very wrong, but I would recommend looking at a 2D renderer like PIXI instead.

[Continuities]

Good to know. I'll have to look into PIXI to see if it can handle some of the effects I have planned. Crappy that Three.js doesn't do frustrum culling. I don't wanna write that stuff...

 

Edit: That's actually much easier than I was expecting. Thanks rolnaaba!

[xerver]

You will have to do it with almost any renderer, it is more of a logic thing than a rendering thing. PIXI will not do it for you either.

[Continuities]

Yeah, that makes sense. I just want to be lazy.

[rich]

You should consider the Turbulenz engine as well then.

[Gio]

I would also like to shamelessly promote our free engine, that does that for you (though it's limited to 2D). It uses layered quad-trees to organize the objects in your game, so it only ever tries to draw those that are visible on the screen.

 

Also, using the same mechanism, if there are areas of the screen that haven't changed since the last frame, it doesn't redraw them.

 

EDIT: I say it's limited to 2D, but it does support zooming, parallax effects and so on.

[Continuities]

Thanks for the help, folks! I didn't even know the term "frustrum culling" before now, so I'm definitely in a better place than I was.

I have a strange aversion to using pre-built game engines. Feels like cheating somehow.

[P.Uri.Tanner]

check out this well done implementation: http://www.zephyrosanemos.com/windstorm/20130301/live-demo.html

[Skratti]

Three.js objects now have built in frustum culling.

 

http://threejs.org/docs/#Reference/Core/Object3D

 

 

 

.frustumCulled

When this is set, it checks every frame if the object is in the frustum of the camera. Otherwise the object gets drawn every frame even if it isn't visible.

default – true

 

So this flag should be set to false if one has already written a culling function...