[x3d-public] Render optimizations
Michalis Kamburelis
michalis.kambi at gmail.com
Thu Aug 15 13:39:50 PDT 2024
As for "Do you think it would be better to have a "static" field on
Shape or perhaps Scene rather than having a StaticGroup node ?"
I think the StaticGroup node from X3D is a good invention, I mean: we
will not practically improve things by adding/replacing "StaticGroup
node idea" with e.g. "new Shape.static field" (and we would complicate
things :) ).
The shortcomings of StaticGroup node in practical use-cases are a bit
outside of X3D specification control:
1. It's not used by authors.
One reason is that it's not supported by exporters. The
Blender->X3D exporter has at this point so many missing things, that I
don't even dream it would one day allow authors to mark things as
"static" on Blender side and export it to X3D StaticGroups.
2. In context of a "larger viewport", like Castle Game Engine or
Unity, there's a need to mark things "static" anyway at a
higher-level.
To signal that a component like TCastleScene (CGE) or GameObject
(Unity) is not even transformed at runtime. The X3D author doesn't
have a knowledge about it, not knowing everything about the whole
world where the X3D model will live.
That is why I think of introducing in CGE a checkbox "Static:
Boolean" at TCastleScene. It would signal that you don't use
animations on this TCastleScene, but also that you don't change the
Translation/Rotation etc. of this TCastleScene, or any of it's
parents. It's a very strong guarantee, but it is often true (e.g. for
game levels, most of which are static 3D models) and it allows some
strong optimizations: static batching (merging all the static stuff
together, into as few shapes as possible), also loading them as static
for the physics engine.
That's the plan at least :) For now we're happy with only
DynamicBatching in CGE :)
Regards,
Michalis
czw., 15 sie 2024 o 22:08 Andreas Plesch <andreasplesch at gmail.com> napisał(a):
>
> Hi Michalis,
>
> super interesting ideas and features. This is very helpful.
>
> I was not sure if dynamic batching would be very useful with slow
> javascript checking each frame what shapes may be combined/batched but
> now I think it might be worth trying. I think it is still ok to rely
> on identical Appearance (DEF/USE) for quicker checking for mergability
> but not on StaticGroup since it is not used. This also has the
> advantage that all primitives are already compiled into points, lines
> and triangles.
>
> Do you think it would be better to have a "static" field on Shape or
> perhaps Scene rather than having a StaticGroup node ?
>
> Thanks, Andreas
>
> On Thu, Aug 15, 2024 at 10:06 AM Michalis Kamburelis
> <michalis.kambi at gmail.com> wrote:
> >
> > Castle Game Engine can be told to do this at run-time, it's called
> > DynamicBatching.
> >
> > It's just a checkbox really, see
> > 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://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://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://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
> > > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453
More information about the x3d-public
mailing list