|
I am working on a game with a large, dynamically generated terrain. The method uses many identical instances of a simple square geometry to create the terrain. As the rectangles change VERY quickly, I would rather not create new gameobjects for each and every one of these squares, as it is comparatively slow against directly calling the renderer API with the mesh and the correct transformation matrix. I don't have Unity Pro, so I can't use the GL library. My question is whether I can use the MeshRenderer to render the same object into a different position, without creating a new object.
(comments are locked)
|
|
No, the MeshRenderer is a component. So it's responsible to render the attached mesh at the gameobjects position. The GL class actually works in the free version (but since the docs states it's pro only it can change at any time). Also the GL class isn't suited for your task. There is the Graphics class but this is unfortunately truly pro only ;) However depending on your needs it's propably better to pack all those squares into one mesh and adjust the vertices manually. Keep in mind that Unity has a hardlimit of 64k vertices which means you can only have a limited count of quads in one Mesh so you might need to split your terrain into chunks. Packing the squares won't work for me - the mesh manipulation is far, far too slow, especially when compared to true instancing. If I could cause the MeshRenderer to re-render with a new transformation matrix, that would be best, but as far as I can tell, that is completely restricted to pro with Graphics. My terrain is going to overrun the number of indices more or less immediately. I am already using the mesh generation features to create the base squares, so I know roughly how fast it is. The algorithm does frustum culling, so I need to be able to alter what is rendered very fast. I really do need hardware caching as well in order to make it be anywhere near real time as well.
May 21 '12 at 12:10 AM
ckfinite
Also, since purchasing Pro is an option for me, does the Graphics class support keeping the mesh on the GPU, or does it to the transfer every time DrawMeshNow is called? For your reference, here is the paper: http://www.vertexasylum.com/downloads/cdlod/cdlod_latest.pdf I have already done an implementation in XNA, which is way, way closer to the rendering hardware than Unity is.
May 21 '12 at 12:11 AM
ckfinite
Why is manipulating the mesh data too slow? What platform do you want to build to? If you draw each little piece manually this would kill your performance since every of your manual draws is causing a drawcall. In this case it would propably faster to use seperate gameobjects since Unity can batch them together into one Mesh automatically. In the old docs i've read somewhere that changing up to 1M vertices a frame should be no problem. If you want to target mobile i think the best way is to pack all in one Mesh like the sprite manager. The drawcalls is the real bottleneck. ;)
May 21 '12 at 12:31 AM
Bunny83
Btw. The particle renderer does actually the same. It displays a lot of individual quads which are packed into one mesh. That's why a single particle emitter / renderer can only render up to 16250 particles.
May 21 '12 at 12:35 AM
Bunny83
The vertex limit per mesh is actually 65354. (2^16, minus two for some reason.) Triangles can have shared vertices (which would be common in terrains), so the vertex limit doesn't tell you how many triangles you can have. There isn't any hard limit on triangles as far as I know, though practically speaking it's somewhat limited by the number of vertices.
May 21 '12 at 12:44 AM
Eric5h5
(comments are locked)
|
