
Wed, 06/18/2025 - 10:26
Hello!
I’m currently receiving controlled-size chunks of vertex data over time and accumulating them into a final vertex array/vector. Each packet may contain between 1 and 1 million vertices. Once I received the final packet of data, I build a Graphic3d_ArrayOfPrimitives with Graphic3d_TOPA_SEGMENTS and pass it to the rendering pipeline in Compute().
However, this accumulation process is inefficient for my use case. Once the data is displayed, it becomes obsolete and is no longer needed. I would prefer to build and display a Graphic3d_ArrayOfPrimitives on-the-fly with each incoming data chunk, without keeping a full history of all vertices. This means I would be managing multiple Graphic3d_ArrayOfPrimitives instances, one per data packet, possibly stored in a vector or list. I'm unsure if this is a recommended or performant approach.
Is there a way to construct and immediately render each incoming batch without accumulating everything into one big array? Are there built-in mechanisms or recommended approaches for dynamic, streaming-style rendering in Open Cascade?
Thank you!!
Wed, 06/18/2025 - 18:26
You may try different strategies depending on the nature of your data.
I. Mutable array of primitives. This approach would preallocate VBO on GPU level, which will be sequentially modified afterwards. 1. If your input data is unindexed. - Preallocate
Graphic3d_AttribBuffer
with the maximum amount of points you expect to be streamed or of a reasonable size for grouping. - Make it mutable (Graphic3d_AttribBuffer::SetMutable()
) and interleaved (default). - Fill in first portion of the data, assign number of defined pointsGraphic3d_AttribBuffer::NbElements
(should be smallerGraphic3d_AttribBuffer::NbMaxElements()
specified on construction), and invalidate sub-range viaGraphic3d_AttribBuffer::Invalidate()
; - Fill in other portions of the data, started from previously initialized portion. 2. If your input data is indexed. - You'll have to upload all vertex attributes first, and then you might useGraphic3d_MutableIndexBuffer
to stream which indices to display.II. Multiple VBOs. This approach considers that you create new
Graphic3d_ArrayOfPrimitives
, while preserving previosly computed ones. The main challenge is to avoid reuploads of data to GPU. - The simplest way would be creating a newAIS_InteractiveObject
instance for each new streamed VBO. - You may also use a singleAIS_InteractiveObject
and add new groups/primitive arrays to existingPrs3d_Presentation
, created by lastAIS_InteractiveObject::Compute()
call (but avoid recomputing presentation). This would require implementing some hacks. - You may also create multiplePrs3d_Presentation
within the sameAIS_InteractiveObject
(but would also require some hacks to avoid bugs).This is for updating visualization part. For selection part you'll have to implement custom
::ComputeSelection()
. But as this doesn't involve interoperation with OpenGL, this layer is more straightforward to profile and optimize for performance (like caching BVH sub-trees for each primitive array sub-group).Thu, 06/19/2025 - 09:41
Thank you very much for your response!!
I will analyse the first strategy from your response based on my current data for each packet.
Thank you very much again!!