Geometry attributes compression example #18208

LeonYuanYao · 2019-12-20T06:48:47Z

Created an example on geometry attributes compression util with a customed material 'PackedPhongMaterial', which can display how much gpu memory can be reduced by applying these compression algrithms. Any suggestions are welcomed and appreciated!

…/Minimap.js" and commit the added files only

…-example

looeee · 2019-12-20T12:42:09Z

Live version for testing

Mugen87 · 2019-12-27T10:26:41Z

Can you please explain a little bit the approach of your PR? What do you understand by geometry attributes compression?

LeonYuanYao · 2019-12-29T14:37:13Z

Can you please explain a little bit the approach of your PR? What do you understand by geometry attributes compression?

Oh, sorry for not providing enough description! In this PR, the geometry attributes (position, normal and uv) are compressed by some of the compression algorithms provided in the GeometryCompressionUtils.js (whose name is temporary and may be changed according to you).
The main algorithms used in GeometryCompressionUtils includes:

"Quantization Encode" for default positions, normals and uvs compression, which can reduce the memory size of each vertex data from "Float32" to "Uint16" (half of the original size);
"Oct Encode" for normals. This encoding method can reduce the memory size of each vertex's normal from "Float32" to "Uint8" (1/4 of the original size!).
Besides, a customed material "PackedPhongMaterial" is also created for the decoding implementation in shaders. Although using these encodings will bring some loss of accuracy, it is extremely useful when dealing with large complex scenes (with triangles over 100 million and when user is using a phone web browser).

So after I did the implementation of these compression methods, I think this can be helpful for others who also needs geometry attributes compresion (maybe solving a very complex and large scene). If you want more explanation or codes improvement, I'll be glad to provide!

mrdoob · 2020-01-02T10:30:53Z

I bet @zeux will like to see this 😁

zeux · 2020-01-02T16:16:17Z

I would consider using 16-bit components for octahedron normal encoding because the vertex attribute strides that aren't 4 byte aligned can have a performance penalty on some WebGL implementations. That gives 3x savings (12->4 bytes) at no perceptible quality loss. 8-byte octahedral encoding can have visible quantization errors in reflections on highly tessellated geometry, although of course if you are crafting a compressed vertex manually you can put the 2 bytes in an interleaved vertex somewhere to avoid the 4-byte alignment issue.

Alternatively you may want to pack normal & tangent together in a 4 byte per vertex stream with 8-bit octahedron encoding and two components for each.

Similarly, using 3 uint16 components can sometimes lead to performance cliffs on some WebGL implementations. So the performance-optimized layout is unfortunately slightly more memory hungry than memory-optimized. gltfpack pads everything to 4 bytes, although this also due to glTF alignment requirements (that exist for similar reasons).

LeonYuanYao · 2020-01-03T01:39:26Z

Learned a lot from @zeux 's comment! So can you please provide some more information on what webgl implementations will be potentially affected/harmed from vertex data compression? As I am currently dealing with large scenes and geometry compressions right now, thank you and appreciated!

Also, perhaps I should add a "bytes" option which accept "2" or "4" (stands for uint8 or uint16) for octahedron normal encoding? Or any suggestion on just using uint16 instead of uint8?

zeux · 2020-01-03T06:48:54Z

I haven't done a specific survey on various implementations, but a couple more concrete examples (note that again, the issue isn't with compressed data per se, it's with vertex attribute data that's not aligned to a 4 byte boundary):

In Metal, vertex buffer stride must be aligned to 4 bytes (https://developer.apple.com/documentation/metal/mtlvertexbufferlayoutdescriptor/1515441-stride?language=objc) and each attribute must be at an offset aligned to 4 bytes (https://developer.apple.com/documentation/metal/mtlvertexattributedescriptor/1515785-offset?language=objc). Thus I'd expect Safari implementation of WebGL to pay extra cost during upload or rendering to support misaligned data
Apple additionally warns about this in their GLES docs (https://developer.apple.com/library/archive/documentation/3DDrawing/Conceptual/OpenGLES_ProgrammingGuide/TechniquesforWorkingwithVertexData/TechniquesforWorkingwithVertexData.html, see "avoid misaligned vertex data"). In general, GLES/GL don't restrict the alignment but the implemenations are notorious for having sudden performance cliffs so it's possible that on some other non-Apple drivers (e.g. Android?) there might be a performance penalty for misaligned data.
Direct3D11-based implementations (ANGLE on Windows) require alignment to be min(component size, 4) which should mean that there's no extra penalty for data that's not aligned to 4 byte boundary, at least during API translation: https://microsoft.github.io/DirectX-Specs/d3d/archive/D3D11_3_FunctionalSpec.htm#4.4.6%20Element%20Alignment

It might make sense to extend the sample to provide both uint8 and uint16 normal storage - uint16 storage wouldn't suffer from alignment issues and, perhaps as importantly, could demonstrate the possible difference in quality between 8-bit and 16-bit octahedron encoding.

…oding reference info.

added some info about compression functions

mrdoob · 2020-01-28T00:01:07Z

Thanks!

mrdoob · 2020-01-28T00:13:31Z

I renamed the example to webgl_buffergeometry_compression.

gkjohnson · 2020-01-28T05:31:47Z

examples/webgl_geometry_compression.html

+			mesh.material.map = data.texture ? texture : null;
+
+			var normalEncode = "";
+			if (data.oct1bytesEncode) {


@LeonYuanYao This should probably be changed to a dropdown in the example GUI since they're all mutually exclusive options. It's a bit confusing at the moment because all of the normal packing options can be checked but it will only use the last one.

gkjohnson · 2020-01-28T05:33:38Z

examples/webgl_geometry_compression.html

+		}
+
+
+		function computeGPUMemory(mesh) {


There's already an estimateBytesUsed function in BufferGeometryUtils if there's interest in using that.

gkjohnson · 2020-01-28T05:35:36Z

examples/jsm/utils/GeometryCompressionUtils.d.ts

+
+export namespace GeometryCompressionUtils {
+
+	export function compressNormals( mesh: THREE.Mesh, encodeMethod: String );


These functions should have : void return values.

Thank you 👍 , will improve the codes in the next PR.

gkjohnson · 2020-01-28T05:45:53Z

Sorry for the late review but I saw a few things that felt comment worthy! I do like this addition, though -- thanks!

I've also had success in the past just compressing UVs and normals to UInt8 or UInt16 values (assuming the UVs are [0.0, 1.0]) which is a pretty nice savings and doesn't require a new shader. A few comments on the functions:

It might nice to provide packed attribute shader functions as shader chunks so they can manually be used with other materials. At the moment this would be hard to use with something like the standard material. In that case you might want compression functions that take geometry or attributes so the material can be handled separately.
Maybe a comment should note that this will break raycasting on the given geometry?

LeonYuanYao · 2020-01-28T09:04:58Z

Sorry for the late review but I saw a few things that felt comment worthy! I do like this addition, though -- thanks!

I've also had success in the past just compressing UVs and normals to UInt8 or UInt16 values (assuming the UVs are [0.0, 1.0]) which is a pretty nice savings and doesn't require a new shader. A few comments on the functions:

It might nice to provide packed attribute shader functions as shader chunks so they can manually be used with other materials. At the moment this would be hard to use with something like the standard material. In that case you might want compression functions that take geometry or attributes so the material can be handled separately.

Maybe a comment should note that this will break raycasting on the given geometry?

Very nice and useful comments! Thanks. Since this PR is merged already, I would consider making these improvements into a new PR in one or two weeks (it is chinese new year vacation now). And for the question of Raycasting, yes I think the traditional CPU-based raycasting may not work properly. It should be noticed when using position attribute compression. However it can be solved by using GPU-based raycasting, I don't know if it is supported by three.js? This could be another new feature to be considered.

mrdoob · 2020-01-28T20:05:17Z

Happy New Year! 🐀

Mugen87 · 2020-02-27T11:04:45Z

examples/jsm/utils/GeometryCompressionUtils.js

+
+            if (currentCos > bestCos) {
+                best = oct;
+                bestCos = currentCos;


It seems the value of bestCos is never read, see https://lgtm.com/projects/g/mrdoob/three.js/snapshot/8ff9714090676d3f766f88d95e8c841b4250d541/files/examples/jsm/utils/GeometryCompressionUtils.js#x3ada8d6e7c54300f:1. It seems octEncodeBest() can be refactored/simplified to avoid this lgtm issue.

Mugen87 · 2020-02-27T11:08:37Z

examples/jsm/utils/GeometryCompressionUtils.js

+                    var tempx = x;
+                    var tempy = y;
+                    tempx = (1 - Math.abs(y)) * (x >= 0 ? 1 : -1);
+                    tempy = (1 - Math.abs(x)) * (y >= 0 ? 1 : -1);


Another lgtm issue: tempx and tempy are always assigned values here so you can write the code like so:

var tempx = ( 1 - Math.abs( y ) ) * ( x >= 0 ? 1 : - 1 ); var tempy = ( 1 - Math.abs( x ) ) * ( y >= 0 ? 1 : - 1 );

and delete var tempx = x; and var tempy = y;.

LeonYuanYao added 9 commits October 28, 2019 10:35

reset to "added examples/webgl_camera_minimap.html & examples/js/misc…

8d32899

…/Minimap.js" and commit the added files only

2019.12.09

0809b0b

Merge remote-tracking branch 'upstream/dev' into normal-packed-material

f35f2fd

PackedPhongMaterial

2ed3600

improve packing geometry

5b2e5ad

1213

e3ce148

geometry compression example

45e8b77

webgl geometry compression example

4f00d96

fixed some left minimap.js codes

34cc4ef

LeonYuanYao changed the title ~~Geometry compression example~~ Geometry attributes compression example Dec 20, 2019

Merge remote-tracking branch 'upstream/dev' into geometry-compression…

fb89b55

…-example

mrdoob added this to the r113 milestone Jan 2, 2020

LeonYuanYao and others added 3 commits January 5, 2020 15:16

Added 1 & 2 bytes options for oct encoding. Some clean ups. Added enc…

84cf2e0

…oding reference info.

added GeometryCompressionUtils.d.ts;

6119955

added some info about compression functions

Some clean ups, added detail option to gui.

1a4b46a

mrdoob merged commit 896b87b into mrdoob:dev Jan 28, 2020

gkjohnson reviewed Jan 28, 2020

View reviewed changes

Mugen87 reviewed Feb 27, 2020

View reviewed changes

LeonYuanYao deleted the geometry-compression-example branch April 17, 2020 03:32

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Geometry attributes compression example #18208

Geometry attributes compression example #18208

LeonYuanYao commented Dec 20, 2019

looeee commented Dec 20, 2019

Mugen87 commented Dec 27, 2019

LeonYuanYao commented Dec 29, 2019 •

edited

Loading

mrdoob commented Jan 2, 2020

zeux commented Jan 2, 2020

LeonYuanYao commented Jan 3, 2020 •

edited

Loading

zeux commented Jan 3, 2020

mrdoob commented Jan 28, 2020

mrdoob commented Jan 28, 2020

gkjohnson Jan 28, 2020

gkjohnson Jan 28, 2020 •

edited

Loading

gkjohnson Jan 28, 2020

LeonYuanYao Feb 29, 2020

gkjohnson commented Jan 28, 2020

LeonYuanYao commented Jan 28, 2020

mrdoob commented Jan 28, 2020

Mugen87 Feb 27, 2020 •

edited

Loading

Mugen87 Feb 27, 2020 •

edited

Loading


		export namespace GeometryCompressionUtils {

		export function compressNormals( mesh: THREE.Mesh, encodeMethod: String );

Geometry attributes compression example #18208

Geometry attributes compression example #18208

Conversation

LeonYuanYao commented Dec 20, 2019

looeee commented Dec 20, 2019

Mugen87 commented Dec 27, 2019

LeonYuanYao commented Dec 29, 2019 • edited Loading

mrdoob commented Jan 2, 2020

zeux commented Jan 2, 2020

LeonYuanYao commented Jan 3, 2020 • edited Loading

zeux commented Jan 3, 2020

mrdoob commented Jan 28, 2020

mrdoob commented Jan 28, 2020

gkjohnson Jan 28, 2020

Choose a reason for hiding this comment

gkjohnson Jan 28, 2020 • edited Loading

Choose a reason for hiding this comment

gkjohnson Jan 28, 2020

Choose a reason for hiding this comment

LeonYuanYao Feb 29, 2020

Choose a reason for hiding this comment

gkjohnson commented Jan 28, 2020

LeonYuanYao commented Jan 28, 2020

mrdoob commented Jan 28, 2020

Mugen87 Feb 27, 2020 • edited Loading

Choose a reason for hiding this comment

Mugen87 Feb 27, 2020 • edited Loading

Choose a reason for hiding this comment

LeonYuanYao commented Dec 29, 2019 •

edited

Loading

LeonYuanYao commented Jan 3, 2020 •

edited

Loading

gkjohnson Jan 28, 2020 •

edited

Loading

Mugen87 Feb 27, 2020 •

edited

Loading

Mugen87 Feb 27, 2020 •

edited

Loading