[x3d-public] Render optimizations

Thu Aug 15 15:19:27 PDT 2024

Hi Nic,

On Thu, Aug 15, 2024 at 4:40 PM Polys, Nicholas <npolys at vt.edu> wrote:
>
> Thanks for these thoughts!
>
> I see great benefits in reducing draw calls. Many big scenes would not be accessible without this technique....
>
>
> I agree we should think about this at the scenegraph level and the requirements...
>
> For example , are switches and lods

I think not. Switches would not be able to be reached by Routes, so
would not make sense and Lods are dynamic not static although I am not
sure if the spec. may still allow those.

> Allowed under staticgroup?
> Can shapes inside them they be animated or used with sensors?

No, no changes to any field are allowed with StaticGroup.

However, for dynamic batching as outlined these restrictions do not
necessarily apply. Geometries and texture coordinates can change each
frame. Also Appearances can change as long as all merged Shapes use
the same changed Appearance. Of course, there is then overhead merging
those Shapes. So there needs to be an option to turn off dynamic
batching, perhaps per Shape.

> The cases and rules could multiply quicky...so what are the rules?

I guess the question is what hints need to be available to an engine.
One could imagine a supersmart engine finding batchable drawables
intelligently, perhaps dropping fidelity as necessary or observing if
an object is actually static during runtime. So perhaps no hints are
strictly necessary. But practically, the question is if more than
StaticGroup is needed. I think there may be an argument for hints on
the Shape level in terms of eligibility, similar to the Frustum
culling for dynamic batching. Only marked Shapes would need to be
considered for dynamic batching. But it would always be the engine's
decision what to batch. I think the main hint would be the number of
Shapes using the same DEF/USE Appearance.

> Is it just that the geometry and appearance are not changed during run time
> ?

Yes, that is the main use case. Geometries using the same drawing
primitive can be drawn in one call using the same shader. It is pretty
basic and can often be achieved on the editor level but that can be
impractical for authors.

Batched shapes could not be picked individually anymore and
StaticGroup does not allow in/out events.

> My understanding is that it is the appearance properties that drive such batch drawing.

Yes, from an X3D viewpoint, imagine that all IndexedFaceSets can be
pretty easily combined into one and if all use the same red Material,
we are already done. If there are textures, there can be only one (or
limited number of) Texture image or map (could be a large image merged
from small images) (per channel) and the Texture coordinates need to
be merged properly, eg. following indices in the merged geometry. If
there are TextureTransforms these would have to be applied, eg. for
flattened Texture coordinates. Since TextureTransforms are often used
for animations and are typically applied on the GPU, they are probably
not a good candidate for such batching.

> And that batching draw calls is distinct from gpu instancing

There are probably many varieties of gpu based instancing.

Cheers, Andreas

> Br,
> N
>
>
>
> ________________________________
> From: x3d-public <x3d-public-bounces at web3d.org> on behalf of Michalis Kamburelis via x3d-public <x3d-public at web3d.org>
> Sent: Thursday, August 15, 2024 10:05 AM
> To: Extensible 3D (X3D) Graphics public discussion <x3d-public at web3d.org>
> Cc: Michalis Kamburelis <michalis.kambi at gmail.com>; Andreas Plesch <andreasplesch at gmail.com>
> Subject: Re: [x3d-public] Render optimizations
>
> Castle Game Engine can be told to do this at run-time, it's called
> DynamicBatching.
>
> It's just a checkbox really, see
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcastle-engine.io%2Fapidoc%2Fhtml%2FCastleViewport.TCastleViewport.html%23DynamicBatching&data=05%7C02%7Cnpolys%40vt.edu%7Cf4153cf113214ee288f408dcbd33862e%7C6095688410ad40fa863d4f32c1e3a37a%7C0%7C0%7C638593276240790010%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=dWDyUxgXJXDWOE6NGEBhxVU7xo95wb4yqDR6KGlExR0%3D&reserved=0
> . In Castle Model Viewer you can activate it with "View -> Dynamic
> Batching".
>
> Doing it at run-time has naturally benefits and drawbacks:
>
> - The benefit of doing it at run-time is that we can "glue" any
> shapes, not necessarily within StaticGroup.
>
>     We even work "cross-scene", that is in Castle Game Engine you
> typically display multiple models (X3D, glTF, etc.) in your viewport
> and we can "glue" into one shapes from various scenes. See e.g. news
> on https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcastle-engine.io%2Fwp%2F2023%2F06%2F30%2Fbig-renderer-improvements-correct-and-automatic-blending-sorting-more-powerful-batching-now-cross-scene-easier-and-more-reliable-occlusion-culling-and-occlusion-sorting%2F&data=05%7C02%7Cnpolys%40vt.edu%7Cf4153cf113214ee288f408dcbd33862e%7C6095688410ad40fa863d4f32c1e3a37a%7C0%7C0%7C638593276240799006%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=3zj75lO%2BGNt2oEgQYOsKRfYfE7VLl015ffpT6cFA2AQ%3D&reserved=0
> when we introduced "cross-scene" batching.
>
>     Doing it at run-time also means we can do it after frustum culling
> has eliminated shapes outside of frustum. So by "gluing many shapes
> into one" we don't negate the benefits of frustum culling.
>
> - The drawback is that effectively DynamicBatching does some
> additional comparisons and processing at run-time. This consumes time,
> and can (in theory) defeat the gains of batching. But it practice it
> (almost) never happens -- the comparisons are rather fast.
>
> Sometimes it's a huge huge gain. As you say, in some models there's a
> big opportunity to effectively have 1 draw call instead of thousands
> -- which translates to big performance gains. And sometimes it's zero
> gain. I haven't found a case when it's "negative gain", that is when
> the extra work at run-time done comparing / merging actually
> outweights the benefits, but I'm sure it exists (I can construct an
> artificial example of this in my head, but does it happen in real-life
> usage?).
>
> All in all, this is a significant feature with some maintenance costs,
> but it is worth it (on *some* cases).
>
> We plan to introduce also StaticBatching to do it at load time. For
> this we plan to invent a way to tell "this model in completely static"
> -- we don't want to rely on X3D StaticGroup nodes, because
>
> - Many X3D models don't use them (even when it would make sense). It
> requires authoring tools support also (e.g. Blender -> X3D exporter to
> honor some "static" setting from Blender).
>
> - And other 3D formats (like glTF) don't have a StaticGroup equivalent.
>
> So we plan to instead have a "Static" checkbox at TCastleScene
> component ( https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcastle-engine.io%2Fviewport_and_scenes&data=05%7C02%7Cnpolys%40vt.edu%7Cf4153cf113214ee288f408dcbd33862e%7C6095688410ad40fa863d4f32c1e3a37a%7C0%7C0%7C638593276240804124%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=rr4YEEwKzJyWOmNpyyR%2FbciQb2t0KBn7LQi2oy9fFoQ%3D&reserved=0 ).
>
> The implementation contains hardcoded a number of rules / comparisons
> (to compare and merge things that are important visually, and ignore
> everything else). See
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcastle-engine%2Fcastle-engine%2Fblob%2Fmaster%2Fsrc%2Fscene%2Fcastleinternalbatchshapes.pas&data=05%7C02%7Cnpolys%40vt.edu%7Cf4153cf113214ee288f408dcbd33862e%7C6095688410ad40fa863d4f32c1e3a37a%7C0%7C0%7C638593276240808932%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Z5%2FGgY95qBFcIVUjX0GhlEVu9IybCpZ3IZ5hdU7GUO0%3D&reserved=0
> . It's of course not perfect, right now it doesn't merge *everything*
> possible. It is coded carefully, i.e. we're not sure can 2 shapes be
> merged -> we don't merge (possibly losing performance, but not risking
> rendering bugs).
>
> To compare, Unity also has both static and dynamic batching. They
> probably don't use X3D underneath :), but still the concept underneath
> is likely similar to what CGE is doing and to what you describe. They
> also have a checkbox "Static" at GameObjects, to help with this.
>
> Regards,
> Michalis
>
> wt., 13 sie 2024 o 23:12 Andreas Plesch via x3d-public
> <x3d-public at web3d.org> napisał(a):
>
> >
> > I think there may be an opportunity for some relatively simple tools
> > to achieve meaningful rendering improvements using the declarative
> > nature of X3D.
> >
> > The idea is that it is much more efficient for (at least for GL based)
> > rendering to send a single draw call with a large object compared to
> > many draw calls with smaller objects. In effect, if it is possible to
> > combine multiple Shapes into a single larger Shape, it can have huge
> > effects on rendering speeds. For example, it is possible to easily
> > render hundreds of thousands of points in a single cloud while it may
> > be nearly impossible to render hundreds of thousands of Shapes with a
> > few points each.
> >
> > StaticGroup is designed to help a browser with such optimizations and
> > I was wondering if there are existing tools which already do this,
> > perhaps in a preprocessing step.
> >
> > The simplest, while useful tool I can think of is this:
> >
> > Inside a StaticGroup, it should be possible to identify Shapes which
> > use the same Appearance (by DEF/USE). We group these Shapes by the
> > drawing primitive they would use (points, lines, triangles). Combining
> > the geometries into a single geometry would be most involved but only
> > considering IndexedFace and TriangleSets should be already useful.
> > Transforms and TextureTransforms would need to be flattened but this
> > can be neatly separated. Finally, a single Shape with the shared
> > Appearance and the combined geometry can replace multiple Shapes.
> >
> > The underlying reason for such a tool is that (machine and human)
> > generators and editors tend to produce many Shapes because it is a bit
> > harder to keep track of them and organize them into single, larger
> > objects.
> >
> > So any thoughts or pointers to existing X3D optimization tools will be
> > very welcome,
> >
> > Andreas
> >
> > --
> > Andreas Plesch
> > Waltham, MA 02453
> >
> > _______________________________________________
> > x3d-public mailing list
> > x3d-public at web3d.org
> > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fweb3d.org%2Fmailman%2Flistinfo%2Fx3d-public_web3d.org&data=05%7C02%7Cnpolys%40vt.edu%7Cf4153cf113214ee288f408dcbd33862e%7C6095688410ad40fa863d4f32c1e3a37a%7C0%7C0%7C638593276240813793%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Ydzv2CO7GpAFAP5NM0%2FsYwvGu5slcacu6Vj%2B4DO4QnE%3D&reserved=0
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fweb3d.org%2Fmailman%2Flistinfo%2Fx3d-public_web3d.org&data=05%7C02%7Cnpolys%40vt.edu%7Cf4153cf113214ee288f408dcbd33862e%7C6095688410ad40fa863d4f32c1e3a37a%7C0%7C0%7C638593276240818630%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=LIqWNX%2FojJzXreHbbJdIz%2FcQNfyBG2zt9RjFC%2B6sQFE%3D&reserved=0

--
Andreas Plesch
Waltham, MA 02453