I am trying to add a texture to the PointPrimitiveCollection class, so each point in the collection may have the same texture attached to it. I am looking at other Collection classes (cloud, billboard). I noticed they have two sets of attribute locations, rather than just one, attributeLocationsBatched, and attributeLocationsInstanced.
I have a suspicion that one of these sets of attributes is passed to the individual object (for instance, one set of the attributes goes to a single billboard shader, not the collection shader).
Can someone please offer more information on this design pattern? Examples can be found at Source/Scene/BillboardCollection.js and Source/Scene/CloudCollection.js
I’m not familiar with the PointPrimitiveCollection class, but I can try to explain the billboard / cloud rendering system.
Ideally, we’d use instancing to render billboards and clouds; all they require are a set of four points with some offset that can be scaled to the size of the billboard. However, we want to offer functionality for any devices that don’t support instancing. Hence the difference between the attributes for batched vs. instanced rendering. I’ll break down the system in the context of CloudCollection since that’s a simpler variant of the BillboardCollection code.
In batched rendering, all of the cloud billboard vertices are explicitly committed to a vertex array buffer. This is then passed into CloudCollectionVS.glsl for rendering. There are four entries per billboard, one for each corner.
This is different from instanced rendering. Instanced rendering specifies an extra attribute, called direction, which specifies a unit square. For reference, the values of direction are always [(0, 0), (1, 0), (1, 1), (0, 1)]. The index buffer for instanced rendering is also different: it is always [0, 1, 2, 0, 2, 3]. This vertex and index buffer specify the geometry to be instanced. Every billboard, therefore, only needs to submit its unique properties to the attributes array once, instead of four times (one for each vertex).
This might be better illustrated by the difference between getIndexBufferInstanced vs. getIndexBufferBatched. The latter is more complicated because it has to go vertex by vertex. It’s the difference between saying “I have a square, let me render it forty times at these forty positions,” vs. “Let me render these 1600 points in one draw call.” That’s why we have different attribute setups, to accommodate the difference between attributes in batched vs. instanced rendering.
I am trying to process a large amount of billboards (1 million) on the screen, brought in through a collection of say, 100 BillboardCollections. When I try to do this though, I take large hits to the application’s performance, dropping the frame rate extremely low, or just crashing the software.
I assume my computer supports instancing, and is therefore using it to create these BillboardCollections. Do you think me running 100 large BillboardCollections might be a task better suited for using batched buffers / rendering instead of doing it in instances? Or is the task still going too computationally expensive regardless?
Would it perhaps be better to split up the 1 million Billboards to be in 1000 BillboardCollections?
I’d love your thoughts on this, thank you for the info.
After further experimentation, it seems that I am able to create 10 billboard collections, each containing 100k billboards, and add them to the Cesium Viewer, without my app crashing or having the framerate drop for a significant period of time.
Sorry for the delayed response. I have never stress tested the batched vs. instanced performance of BillboardCollection myself, so it’s hard to say.
Generally, reducing the number of draw calls that are made leads to better performance. As an extreme example, drawing 100 billboards batched in one draw call is better drawing each billboard separately. So it makes sense to minimize the number of BillboardCollections as much as possible, since each BillboardCollections manages its own draw commands.
Regardless, glad to hear that your app is able to handle so many billboards!