Rendering large amounts of geometry

Graphics
#1

Hello everyone!

I’m looking into optimizing the rendering of large amounts of meshes.
Originally I was keeping each mesh separate, which results in thousands of Entities.
I tried a little optimization by combining all meshes into one, which made an insane difference:

vs

The issue with this is of course that I lose control over the transformation of objects and the materials set to each mesh…
Would there be a way to optimize the draw calls (or whatever causes this problem) while keeping the “separation”?

Thanks,

Hugo Peters

#2

You would want to look into instancing I’m not sure if this is possible with the entity system, but I know you can manually implement this, or should be able to.

#3

Hmm… Most of the geometry is unique, so I think instancing wouldn’t help (much)… or am I wrong?

#4

If the geometry is unique then no that wont help much. You could transform each vertex by that vertex’s world matrix when loading the data in. I imagine this would get rather slow though for a large amount of vertices. You could write a better scene manager with octree/occlusion culling:

I think in d3d 11 there is a way to batch together your draw calls and then run them all at once it’s called a command list:

I’m not sure if this is possible with paradox.

#5

:smile: Maybe you can combine the mesh with the same material。 It’s the same FPS with combine all i think。 because the drawcall is same. it’s the drawcall times problem actually! I don’t know combine the same material mesh in engine automatically can optimization, maybe must multiply the transforMatrix in CPU or offer a static Mode to optimization the can’t move mesh。 I have’t use paradox actually,i alos don’t know it can success in Paradox,I only give you an Analysis and suggest.

#6

Well the reason why one draw call is faster then a bunch of draw calls has to do with the CPU overhead. I’m fairly certain that using a command list would be a good route to go, however only for PC projects. If you want to get better performance beyond that for mobile then some sort of scene management data structure(like bsp trees, octree, occlusion culling, etc) would be ideal, and even with a command list you should still use those things. A octree is fairly easy to setup combine that with occlusion culling and you can remove a lot of entities that would normally be hidden, but are still rendering.

#7

Next version should hopefully see some improvements in that area.
Many changes in the rendering system.

Also, longer term, we are planning to completely rewrite our high and low-level rendering system to better support high number of objects and newer API (D3D12, Vulkan, etc…)

#8

How soon is the new version? Days, weeks?

#9

It must be pretty soon because it was 1-2 weeks away around the middle of march. I’d rather have a polished version than a buggy version so I’m glad they are taking their time to fix things up! :slight_smile:

#10

Our apologize for the delay of the new version. We are struggling with the last bits of fixes.It turns out that we had some resource constraints on another internal project that has delayed the release of the new version. We are trying to make it happen asap (hopefully more in term of days than weeks!..)

2 Likes
#11

Awesome glad to hear! :slight_smile:

1 Like
#12

No apologies necessary, was just curious - looking forward to it!

#13

Can’t wait for it! :slight_smile:

#14

Here it is!

http://paradox3d.net/blog/new-version-1-1-0-beta-physically-based-rendering-and-scene-editor

#15

Excellent, thank you.