What is the best way to render 1,000,000 bricks? (Is there a 3d blitting technique or something?)

And have the ability to move them individually!

I've tried the following.

1) Game object for each brick (lags out at about 5,000 game objects).
2) All bricks combined in one mesh and use bones for each brick to move individual bricks (causes 3d software to crash and run extremely slow with 1,000,000 bones, can't export without crash).

In 2d games you can use blitting which paints all objects to a single bitmap so you can have 1,000,000 particles on screen by only using one Game Object / MovieClip / Instance.

My idea would be to like... use 'Billboards' for each brick when it's in motion... and and paint all those "billboards" to a bitmap that overlays the screen... like screen space blitting or something.


Anyone have better ideas?

 

Tried voxels?

 

Hmm, didn't think of that. Problem is I don't think I'd be able to get more functionality than minecraft (uniform block sizes, everything is at 90deg angles, fake physics). I'm looking more to use rigid bodies of varying sizes and rotation.

I can have 1,000,000 rigidbodies, it's just I have no way to render them currently.

Could this be done with a shader?

 

Any way you go about it with a million actual objects/rigidbodies/whatever is going to be extremely inefficient. Voxels are likely your best bet since it's all just one mesh, but you can only have 65k vertices in a single mesh so you'd have to do it in an array of chunks. Voxels don't have to be uniform 90 degree angle blocks like minecraft, that's just minecraft's way of using them. You could rig it so that if a voxel brick is interacted with it gets replaced with a rigidbody brick to simulate the physics you're looking for.

Examples of voxels being used in a non-uniform non-90 degree angle manner:
https://www.assetstore.unity3d.com/en/#!/content/8131
https://www.assetstore.unity3d.com/en/#!/content/8176

 

www.openglsuperbible.com/2013/10/16/the-road-to-one-million-draws/
or
hardware instancing?

 

Or you can delve into the depths of the Unity Minecraft Tombs -> http://forum.unity3d.com/threads/after-playing-minecraft.63149/

 

Call a stonemason?

 

Or you can look into Geometry Shaders (video below)

Also check out my CubeMark Unity Benchmark > http://forum.unity3d.com/threads/unity-benchmark-v0-1.151813/

It will give you an idea of how many cubes Unity can throw around without getting into more advanced rendering techniques.

 

Not sure what kind of machine you are testing it on but maybe that has something to do with it?

If you check out SpriteTile on the Asset store you will find the author made a One Million Tile Demo using a 1,000 by 1,000 tile area. On my 6+ year old laptop this demo running in the web browser is very fast and smooth.

I realize this is like comparing apples and oranges if you are using more complex fully 3D objects but at least this would be a good test. First be sure your machine can run this demo at full frame rate. If it is very fast and smooth then it seems quite likely you could get 1 million simple cube game objects running full frame too. It might have nothing to do with the rendering. It could be the physics system slowing everything down.

 

No I think you are getting just enough tiles to fill your view, the tiles are just being moved around and updated from a map 1k x 1k with tile data. I could be wrong but I didn't notice a zoom out key!

But it does show that you can have 100 x 100 x 100 or 1,000,000 cubes in a level and as long as like minecraft they are quite large then you will never have to render all of them.

Like I said check out the minecraft forum thread, it has some great information on how to draw voxel/minecraft style worlds efficiently.

 

Oh yeah of course you wouldn't want to have the entire game world of that size all active and running continually. I assumed (yes I know what that means) the OP was deactivating areas outside the current view. Maybe maintain an active rectangle of a 3 x 3 view at all times. Then as player moves forward into scene check objects on back side disabling them when they fall out of range. The data structure is the key here more than the rendering system.

 

No probably old school tile shifting and wrapping, you draw the sprites of the world onto a set of tiles, only enough to fill the view + 1 tile border. Then you move or shift the tiles to simulate moving the player, and when the tiles disappear from one side of the grid you move them to the opposite side. Allowing for infinite tile area size as you only need to build the level as data and that can be tiny e.g. a byte per tile type (allowing for 256 types of tile). It's tricky to get right in Unity as a tiny move can be sub pixel and show up as breaks in the tile map.

 

Or.... you can just render them all.

(the crappiness of the video is from the capture. they fps doesn't dip below about 70. and it stays sharp.)
1.3 million tiles (2d). Here are some better pics:


Here are a few videos generated maps.

The light tracer that appears on a couple of them is done with by just moving the texture, I build an alt UV set for animation. I did this about a month ago to determine a highly optimized and flexible tiling system for mobile usage. Even the 1.3 million one holds up on new devices, though about half way out it, my iPad2 struggles. I had done a couple versions where I move and hide tiles, but this ended up being faster. (almost all GPU)

 

@zombiegorilla: Nice!

Bones can be pretty expensive, though, since they increase the amount of work that needs to be done per vertex. I wouldn't use them for large-scale, rigid animation like this, especially since most of your bricks (I assume) wouldn't be moving.

That's an important point, though: how many of your bricks are moving compared to how many are static?

The equivalent approach in 3D is batching. Unity has some general case stuff built in, but for this specific case it might be worth implementing something of your own with the Mesh class. Wherever bricks aren't moving you'd copy their verts into meshes that represent batches of identical bricks (based on material). As an added optimisation you could also remove any non-exterior faces. To do this you'd probably want to abstract the idea of a brick so that it was no longer tied directly to its GameObject/Renderer, as you'd need to be able to create/destroy them independently of one another. (I can only assume this would be covered in detail in the thread @Arowx linked to earlier.)

Edit: A consideration for the moving bricks is that you can render 3D objects as a part of a particle system. So you could batch static ones as parts of manually controlled meshes, and moving ones as parts of particle systems. I haven't looked into the performance of 3D objects in particle systems, though, so I've no idea how it performs.

 

That's excellent. I haven't done any performance tests with Unity mainly because I don't think any project I'd like to do would be an issue. Years ago though it was always an issue and the bottleneck was always on the rendering side. So I ended up using dirty rectangles, only processing the active area (around the visible playfield) and so forth whatever I could come up with to make things fast. That experience combined with the many posts I've read about performance issues dealing with a large amount of objects in Unity I figured it was the same ole thing again... the rendering sucking up all of the frame time! Sounds like you have the answer to the OP.

 

Rendering has advanced quite well in that time period. Efficiently dealing with "large amounts of objects" often means doing some things in fairly "old school" ways, though.

 

Exactly. For example:

I often equate it to Theater. Your audience only sees the things you want them to see. Viewing from even a slightly different angle, the illusion crumbles. I abuse the hell out of the particle system. In our live game, I even use it for UI elements (on stage cards/feedback). You can use all kinds of tricks. Though, I didn't work on it, the Marvel Contest of Champions game uses a ton of really cool cheats for lighting.

To the OP, what I did is sort of along the same lines as blitting. I too come from a flash background and leverage a lot of the same tricks I built up in flash. When you blit, your main savings comes from getting rid of all the layers, objects and vector data, and burning it down to a bitmap that is 1:1. For my tiling system, I am kind of doing the same thing. I make a single mesh, and dump everything else. I don't save any info about the maps except the path data, the rest is read and discarded, and even that isn't complete. I only save and store variants. The path is stored and specific elements, anything not set, is procedural (weighted random). The same system also handles 3d, but as the concept was always going to be iso(ish), it only handles the front 3 faces.

Just use the bear minimum of information needed set the scene, then fake the rest.

 

Absolutely. Everything in a simulation is "faked" anyway. You want to fake things to the minimum degree possible for your audience to suspend disbelief. Anything more is a waste of resources.

 

Has no one asked what for yet? Why do you need to render 1 million bricks when no other game or application has had that need before?

Also you say that in 2D you could just blit, but then you say you want to use rigid bodies of varying sizes and rotations. So whatever 2D engine you would use must support 1 million 2D rigid bodies. Seems to me that would be just as hard/impossible as 1 million 3D rigid bodies. I fail to see how rendering is the bottleneck here.

Do you need 1 million rigid body cubes to be visible and interactable at the same time? That would make each cube/brick the size of a pixel and whether it was 2D or 3D would barely matter.

 

First rule of game development: Fake it. Fake it. Fake it.

Ways you can fake it:

• Add lots of fog so you can only see nearby cubes.
• Have the far off scenery rendered to a sky box.
• Have the far off blocks lower level of detail with some texturing to make it looks like tinier blocks

Second rule of game development: Work within your limitations. So you can't do a million bricks? Do a thousand. Work with it. You can still make a decent game with a thousand bricks.

Yeah. These aren't really the rules of game development. I just made them up just now.

 

Fantastic point. If it can't be fun with a thousand things then will having a million things fix that? Probably not.

Also a good point. I assumed that it's a scene with a million bricks, but that not all million bricks need to be visible at once. Is that the case?

 

After watching the videos linked by arrow and gorilla: a million or a half million can really have a kind of special quality to it. Sure, you can probably make due with a few thousand and sneak it past the viewer. But really pushing the envelope can provide something different entirely. If it's worth the headache or not, only you know!