BlackMojito Posted January 17, 2018 Share Posted January 17, 2018 Hi Folks, I have several questions regarding rendering performance. Question 1: about the acceleration structures. As we know that in Babylon we have Octree, it seems to be used for both frustum culling and picking. But I saw that we had also an interface called IActiveMeshProvider. Is it used for implementing other acceleration structure like BSP or BVH? I've seen some rendering engine which use BVH to do frustum culling. What are the advantages of Octree against BVH? @Deltakosh told me that we have a complete frustum culling stuff internally. How does it work? Does it work by using the Octree? Question 2: About sorting. Do we have bulit-in pre-sorting process so that we can avoid useless shader binding? Question 3: About mesh merging. I think I can use MergeMeshes to merge the meshes which share the same shader. However I need to keep the original one for picking. How can I distinguish the "Visual Tree" and the "Selection Tree"? Thanks guys Quote Link to comment Share on other sites More sharing options...
Amarth2Estel Posted January 17, 2018 Share Posted January 17, 2018 Hi BlackMojito, I cannot answer the first two questions but I faced the same issue and found a solution for Question 3. I have done as follow : - Merge meshes, without disposing sources - Disable the original meshes (not in the render anymore) - When picking, use predicate function to set only disabled meshes as selectable. For other reason, I had to use my own picking system with call on Scene.MultiPickWithRay but I guess you can also use pointer[Down/Up/Move]Predicate attribute on your scene to override default predicate function, which -from what I remember- is 'mesh.isPickable && mesh.isVisible && mesh.isReady()' This way, you have a drawable part of the scene composed by few meshes after the merging process and an interactive part, not drawn, to use interaction. There may be a better solution, and it would be a pleasure to know it to increase performances again, if somebody has an idea ! Quote Link to comment Share on other sites More sharing options...
GameMonetize Posted January 17, 2018 Share Posted January 17, 2018 Hello! 1. We use octree for mesh selection only if user enable it as the cost of maintaining the octree could be bigger than just going through a list of meshes. When you have a lot of static meshes then the octree is a good idea. BVH or Octree is a good question and there is no good response It clearly depends on your scene topology and this is why you have the opportunity to provide your own mesh selection algorithm. By default, the scene will go through all enabled and visible meshes and will do frustum clipping based on current camera view. This will generate the list of active meshes used for rendering. 2. By default only transparent meshes are ordered back to front. But you can decide to also order opaque and alpha test meshes with this API: http://doc.babylonjs.com/classes/3.1/scene#setrenderingorder-renderinggroupid-opaquesortcomparefn-alphatestsortcomparefn-transparentsortcomparefn-rarr-void. Quote Link to comment Share on other sites More sharing options...
brianzinn Posted January 17, 2018 Share Posted January 17, 2018 Question 2: This is a good read:https://doc.babylonjs.com/resources/transparency_and_how_meshes_are_rendered if you have a really expensive object to draw you may want to try occlusion queries - new in 3.1:https://doc.babylonjs.com/features/occlusionquery GameMonetize 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.