[x3d-public] Render optimizations

Thu Aug 15 13:44:43 PDT 2024

Guys, this is unrelated, but I'm interested in batching interpolators.

John

On Thu, Aug 15, 2024 at 3:41 PM Polys, Nicholas via x3d-public <
x3d-public at web3d.org> 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
> Allowed under staticgroup?
> Can shapes inside them they be animated or used with sensors?
>
> The cases and rules could multiply quicky...so what are the rules?
>
> Is it just that the geometry and appearance are not changed during run time
> ?
>
> My understanding is that it is the appearance properties that drive such
> batch drawing.
>
>
> And that batching draw calls  is distinct from gpu instancing
>
> Br,
> N
>
>
>    1.
>
> ------------------------------
> *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
> <https://castle-engine.io/apidoc/html/CastleViewport.TCastleViewport.html#DynamicBatching>
> . 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
> <https://castle-engine.io/wp/2023/06/30/big-renderer-improvements-correct-and-automatic-blending-sorting-more-powerful-batching-now-cross-scene-easier-and-more-reliable-occlusion-culling-and-occlusion-sorting/>
> 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
> <https://castle-engine.io/viewport_and_scenes> ).
>
> 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
> <https://github.com/castle-engine/castle-engine/blob/master/src/scene/castleinternalbatchshapes.pas>
> . 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
> <http://web3d.org/mailman/listinfo/x3d-public_web3d.org>
>
> _______________________________________________
> 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
> <http://web3d.org/mailman/listinfo/x3d-public_web3d.org>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20240815/9866b7f2/attachment-0001.html>