Is there a way to make some geometry instancing in EE?

I'm trying to make a random generated dungeon, similar to those in old roguelike games, just in 3D - made from some cuboids and cuboid-like walls. The problem is, I don't know how to place them memory efficient (in mobile SDK).

I tried to use objCreateNear with the simple wall object (mesh+phys) - it worked OK, but only on desktop. Android mobile (the target platform) can't handle 20000 objects put this way (bails out in about half way) :-/

Then I tried to use Edit::Blocks feature - it works, even quite well, but it's extremely limited. I can't have element other than simple AxAxA cubes with material... When I scale it looks very unrealistic. It looks bad, isn't elastic and just doesn't fit my needs.

Is there some other way I can draw about 20k simple meshes (but not always cuboids) in something like instancing (or the grass - just not bound to the area)? It would need to handle physics also, because walls must have collisions...

Just imagine the 128x128 classic roguelike dungeon (with gaps between corridors and rooms) made from simple cube and cuble-like shapes :-)

Lets do some math:
a cube has six sides, with 2 tris per side thats 12 tris per cube.
Now you want a grid 128x128 thats 16384.
Now if we multiply that by the number of sides of a cube we get: 196608
So... the question is can you draw that many tris. I have no idea, but from what you are saying, the answer is no. You may instead want to try using some form of Fog of War or simply not drawing what you can't see. My guess is that somewhere between the 196 thousand tris and the 16 thousand physX objects your device decides it hates you.

Roguelike solved this by only drawing a small portion of the map at once. I would suggest this for your game. You may also want to try using some simple Fog algorithm, similar to what is used in Terria or the old Roguelike games.

Finally, I think Esenthel has a feature for rendering similar objects, I remember reading something about that a while ago. I don't have Esenthel on this computer so I can't be very helpful sorry...

Essentially you are running into the same issue as this one:
http://www.esenthel.com/community/showth...p?tid=4272

Basically would be way too slow to draw 20K separate meshes in EE, especially on mobile. You will have to manually merge mesh geometry taking into account materials, memory tradeoff, geoemtry spatial location to still allow efficient frustum culling... ouch.
Probably you should be doing this during loading or at runtime if you are using random generation.
To be honest not even modern PC game engines will render 20K objects without HW instancing, they are limited to around 2K unique meshes maximum. in EE case I'll try and keep below 200 separate meshes.
I think many other people will run into this very same issue once they start creating production level maps.
Also regardless of EE, 16K physics objects is a lot. In your case You should try and create bigger bounding boxes therefore reducing the number of actors by merging adjacient cubes (for instance contiguos floors, walls etc.)

Actually I have no problem with drawing 20k and more meshes (even more complicated, than simple cube) in EE. Even with physics :-)

My problem is relating only to mobile platforms - because of its limits I cannot use techniques from the desktop.

For now, I managed to use physics from blocks feature and draw meshes manually only in player fov.

BTW. My problems may sometimes seem wired, but I'm crazy on the dynamic world topics. I'm trying to get as much as possible from EE without using the World Editor at all (to draw world)

(11-21-2011 02:57 PM)kulesz Wrote:  Just imagine the 128x128 classic roguelike dungeon (with gaps between corridors and rooms) made from simple cube and cuble-like shapes :-)

you can use Edit::Blocks for the blocks parts (walls)
where you need some more complex object, just use Mesh instead.
if you want to have good performance with many objects you need to think about merging meshes (just like Edit::Blocks does)

So there is nothing like dynamic batching, which is automatically combining identical small meshes (for example 50 instances of one flower in the garden) to by able to render it once? I have to combine it manually?

engine does group rendering meshes with similar materials internally:
1. engine sets material (for meshes that share the material) to the GPU
2. engine renders all meshes with that material (however draw calls are still separate for all visible meshes)

if you want to have less draw calls you need to merge the meshes

(11-25-2011 07:34 PM)Esenthel Wrote:  2. engine renders all meshes with that material (however draw calls are still separate for all visible meshes)

Hang on, I'm confused. Are you saying that two visible meshes that share the same material still results in two draw calls?

(11-26-2011 07:43 AM)fatcoder Wrote:  

(11-25-2011 07:34 PM)Esenthel Wrote:  2. engine renders all meshes with that material (however draw calls are still separate for all visible meshes)

Hang on, I'm confused. Are you saying that two visible meshes that share the same material still results in two draw calls?

Yes, they do

---

(11-25-2011 07:34 PM)Esenthel Wrote:  engine does group rendering meshes with similar materials internally:
1. engine sets material (for meshes that share the material) to the GPU
2. engine renders all meshes with that material (however draw calls are still separate for all visible meshes)

if you want to have less draw calls you need to merge the meshes

And how are you sorting meshes with multiple materials? Seems like you are assuming 1 mesh=1 material here.

What is faster on EE, 20 small meshes each with 1 unique material, or if I combine them to one mesh with 20 materials?

(11-26-2011 12:21 PM)Abril Wrote:  

(11-26-2011 07:43 AM)fatcoder Wrote:  

(11-25-2011 07:34 PM)Esenthel Wrote:  2. engine renders all meshes with that material (however draw calls are still separate for all visible meshes)

Hang on, I'm confused. Are you saying that two visible meshes that share the same material still results in two draw calls?

Yes, they do

Makes no sense at all... batched geometry rendered with the same material results in a single draw call. That is a basic video card principle, not an EE principle. Perhaps it is just a misunderstanding and we are misinterpreting Esenthels meaning.

(12-11-2011 11:45 PM)Demostenes2 Wrote:  What is faster on EE, 20 small meshes each with 1 unique material, or if I combine them to one mesh with 20 materials?

in terms of rendering only - equal performance

And in other terms?

I noticed, that build is significantly faster than editor when using lots of trees and grass on the terrain. What are you internaly doing with this? Some combining? I would like to know details, because I think there are performance reserves and if I can help it somehow with custom code. Visibility has very little impact, so bottle neck is not there.

Could you please add a function to the Renderer to retrieve the number of drawcalls (including shadow generation)? and number of polygons rendered... thanks.