<div dir="auto"><div><div class="gmail_quote"><div dir="ltr">On Tue, Apr 10, 2018, 12:15 AM Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com">michalis.kambi@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2018-04-10 4:40 GMT+02:00 Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank" rel="noreferrer">andreasplesch@gmail.com</a>>:<br>
> Another way to approach the question if there is an opportunity or if such<br>
> an idea is just a distraction, is to consider why there is not a SFInt16 or<br>
> SFInt8 type. The thinking at the time may have been that there is a need for<br>
> integers for indices but also a need to keep it simple and only have a<br>
> single one, int32. On the other hand, for floats let's have both 32 and<br>
> 64bit.<br>
<br>
Note that it is a reasonable optimization to pack mesh indexes into<br>
8-bit or 16-bit integers, instead of full 32-bit integers. Even today,<br>
with incredibly fast GPUs :)<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">The drive will always be there to utilize hardware to the fullest amount. The trade-off is the increased effort in programming.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Looking at others:<br>
<br>
- glTF 2.0 allows providing indexes as 8-bit or 16-bit integers<br>
(<a href="https://github.com/KhronosGroup/glTF/tree/master/specification/2.0" rel="noreferrer noreferrer" target="_blank">https://github.com/KhronosGroup/glTF/tree/master/specification/2.0</a><br>
allows to use UNSIGNED_SHORT, UNSIGNED_BYTE as an alternative to<br>
UNSIGNED_INT for indexes).<br>
<br>
- And the APIs -- like OpenGL[ES], WebGL, Three.js -- all allow<br>
indexes to be 8-bit or 16-bit integers, not only 32-bit integers.<br>
<br>
- Unity3d explicitly advices using 16-bit indexes for meshes, not 32:<br>
<a href="https://docs.unity3d.com/Manual/FBXImporter-Model.html" rel="noreferrer noreferrer" target="_blank">https://docs.unity3d.com/Manual/FBXImporter-Model.html</a> : "Note: For<br>
bandwidth and memory storage size reasons, you generally want to keep<br>
16 bit indices as default, and only use 32 bit when necessary." . Note<br>
that it's a new setting -- before 2017, Unity3d was *forcing* to use<br>
16-bit indices, limiting all mesh sizes to 64k chunks, and there<br>
wasn't even an option to use 32-bit indices.<br>
<br>
- In Castle Game Engine, we use 16-bit indexes for rendering on<br>
OpenGLES (mobile) and for all 2D user-interface rendering. We keep<br>
using 32-bit indexes on desktop OpenGL for 3D rendering.<br>
<br>
I'm not proposing to introduce MFInt16 to X3D :) But I wanted to note<br>
that "the size of integers still matters for GPUs". While the hardware<br>
is incredibly faster than it was 20 years ago, some of the "old"<br>
optimizations still matter. The gain you get from using smaller types<br>
still matters when you have a large mesh data and need to send it fast<br>
to GPU. ("coordIndex" expressed using 16-bit ints is 2x smaller than<br>
32-bit ints, "Coordinate.point" expressed using half-floats is 2x<br>
smaller than 32-bit floats and so on.)<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Well, it does actually sound like having an explicit MFInt16 may be a good idea, for mobile targets.</div><div dir="auto"><br></div><div dir="auto">Alternatively, it would be more transparent to have a generic MFInt type which would make it obvious that it is up to the browser how many bits to use, eg. 16 on mobile and perhaps automatic subdivision into fitting chunks, or 32 on OpenGL.</div><div dir="auto"><br></div><div dir="auto">Regards,</div><div dir="auto">Andreas</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Regards,<br>
Michalis<br>
</blockquote></div></div></div>