Jump to content

About acceleration structures


Recommended Posts

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


Link to comment
Share on other sites

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 :D!

Link to comment
Share on other sites


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

Link to comment
Share on other sites

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.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...