5 posts tagged with "compression"

Introduction​

3D Gaussian Splatting is a new method for digitizing and rendering real world objects. With gaussian splatting, you can digitize a scene from a few photos using services like Luma Labs or Polycam. These services take the set of photos and generate a 3d Gaussian Splat scene in PLY format.

For example, this is a Gaussian Splat scene rendered in PlayCanvas.

What is a Splat?​

Gaussian Splat Scenes are not made up of polygons and textures. Instead, they are made up of many (up to millions) of individual, unconnected blobs called splats. A splat is just a particle in space with size, orientation, color and opacity.

Below you can see a single brown splat selected. The splat bounding box shows its orientation and size:

The gaussian part of the name comes from the shape of splat itself: the splat opacity has a gaussian falloff from its center to its edge.

Engine Support​

The PlayCanvas team has been adding support to the engine for loading and rendering Gaussian Splat PLY files:

Since the resulting files are often messy and require cleaning, we released SuperSplat, a tool for cleaning and processing gaussian splat PLY files:

PLY Format​

However, the default gaussian splat PLY format as exported by training tools is large.

This is because the uncompressed format stores a large amount of data per splat:

Name	Data Format	Bytes
Position	3 x float	12
Orientation	4 x float	16
Scale	3 x float	12
Spherical harmonics / color	48 x float	192
Total		232

For example, the original guitar.ply scene file takes 132.8 MB (32 MB excluding spherical harmonic data).

Compressed PLY Format​

So we introduced a compressed PLY format for use in runtime applications. The compressed PLY file format ignores the unused spherical harmonic data and stores the rest of the elements in quantized integers.

The format can be summarized as follows:

• Split the scene into chunks of 256 splats
• For each chunk, store the min and max (x, y, z) for position and scale in floating point
• For each splat in the chunk, store a normalized and quantized value for position and scale (relative to chunk extents) and orientation and color

This data layout results in the following data per chunk:

Name	Data Format	Bytes
Position bound	6 x float	24
Scale bound	6 x float	24
Total		48

And the following data per splat:

Name	Data Format	Bytes
Position	uint32 (11, 10, 11)	4
Orientation	uint32 (2, 10, 10, 10)	4
Scale	uint32 (11, 10, 11)	4
Color	uint32 (8, 8, 8, 8)	4
Total		16

As a result, the compressed version of guitar.ply takes only 8.7 MB.

Do It Yourself​

The easiest way to generate a compressed PLY file yourself is using the SuperSplat tool. Load the PLY file into SuperSplat and export it again using the 'Compressed Ply File' option:

If you are interested in the file format specifics, see this code which demonstrates how to decompress the file data.

See this editor project for an example of loading and rendering a compressed gaussian splat PLY file. Or you can run it here.

Summary and Future​

We have introduced a new compressed PLY format for gaussian splatting which is roughly 4x smaller than uncompressed data and can be used in realtime applications.

In future we hope to:

• store splats hierarchically for optimized rendering and culling
• implement realtime splat LOD
• test skinning and animation of gaussian splats
• further compress gaussian splat data
• optimize WebGPU rendering

References​

The compressed format is largely based on the fine work of Aras Pranckevičius and his blog posts.

Today we're excited to announce that PlayCanvas now supports WebP and AVIF images natively in the editor. Two new, efficient image formats built for the web.

This is not just an exciting update for us but a game-changer for anyone looking to optimize their projects for faster load times and better quality.

JPGs and PNGs have served us well. They're reliable and you can use them everywhere. AVIF and WebP are the new kids on the block. They offer better compression with a wider range of features like alpha channels, HDR and wide color gamut. But how do these formats work in practice and are they really that good? Let's dive in.

Take a look at the following images:

They look strikingly similar, but the file size tells a different story. The AVIF image on the left has a file size of just 18Kb, and the JPG counterpart over 4 times larger at 74Kb! This level of compression is not just impressive on its own. When you're working on a project with multiple textures, switching to AVIF and WebP formats could considerably reduce your overall load time.

What does this mean for you? Well, that's simple: it's all about efficiency and speed without sacrificing quality. Textures are one of the biggest assets in a 3D project and AVIF and WebP significantly reduce image sizes compared to traditional JPEGs and PNGs and that means faster load times and happier users. 🙌

AVIF all the things?​

Ok, so browser support for AVIF is good, but not great according to caniuse, so always check support and use the right format for your users. Different formats are better suited for different content. It's not a one-size-fits-all solution, so we encourage you to explore various options and choose the one best for you.

Getting Started​

Easy! Just start uploading your AVIF and WebP files into the Asset Panel, and for those of you wanting to convert your existing assets, you can now right-click on your asset in the Asset Panel and quickly convert your asset into a PNG, JPG, WebP or an AVIF.

So there you have it! This is not just a feature release; it's our way of saying we're listening and we care. We're excited to hear your thoughts on these new features. Give them a try and share your experiences with us.

Till then, keep creating, keep innovating!

We are thrilled to announce the immediate availability of Draco Mesh Compression in the PlayCanvas Editor! Our latest feature allows developers to compress meshes using Google's Draco technology, reducing file sizes and enhancing the end-user experience.

At its core, Draco Mesh Compression reduces the amount of data needed to represent 3D graphics without compromising visual quality. The technology achieves this by applying a lossy compression algorithm to the mesh data. With less data to transfer, the result is faster load times and lower bandwidth costs for your applications.

The open source PlayCanvas Engine has been able to load Draco-compressed glTF 2.0 files for quite some time now. But now you can generate these Draco-compressed glTF files in the Editor at import time. Check out how easy it is to use:

"1972 Datsun 240k GT" by Karol Miklas is licensed under Creative Commons Attribution-ShareAlike.

In the example above, a 49.9MB GLB file is crunched down to only 3.67MB. That's a 92.6% reduction is file size! And for the majority of scenes, you should notice no difference in terms of visual quality. The only cost is decompression time when the compressed GLB is downloaded by an end user, but this should be significantly less than what is saved in terms of download time.

To enable the feature, open your Project Settings in the Inspector, expand the Asset Tasks panel and edit the Mesh Compression setting. Then, simply Re-Import any existing FBX or GLB and compression will be applied. Any FBX or GLB subsequently imported will also respect your mesh compression setting. Read more on the Developer Site.

We believe that mesh compression is going to take many types of applications to the next level, particularly e-commerce applications like product configurators, which need to load detailed meshes as fast as possible.

Get started with PlayCanvas today and make your WebGL dreams a reality!

PlayCanvas implemented the fantastic hardware texture compression workflow in 2016 which allowed users to build bigger and better WebGL apps, even on low memory devices like mobile phones.

JPGs and PNGs are great formats for transmission over a network because they tend to compress nicely. But once the images are downloaded and handed over to WebGL, they must decompressed to raw RGB(A) data. Using hardware compressed textures is important as decompression is performed in silicon on the GPU which avoids the need to utilize lots of memory.

This 4096 x 2048 Earth texture is a 1.81MB JPG but takes a huge 33.6MB of VRAM when uncompressed!

With hardware supported texture formats, we can retain a similar file size while massively reducing the amount of VRAM as seen below.

Now, what if you reduce file sizes as well as the VRAM usage?!

That is what Basis gives us and it is available right now to all PlayCanvas users! Compressing the same Earth texture above, produces a 521KB Basis Texture.That’s a 68% saving over the smallest file size from the hardware supported formats 💪

Basis is an open sourced, texture codec that produces a highly compressed intermediate file format (.basis) that can be converted at runtime to a format that the hardware supports in GPU hardware. This means that there is only a single (and often smaller) file that is created to support a wide range of platforms.

As shown by the numbers above, Basis offers huge savings in download times for the end user which in turn, can lead to improved user engagement and click to open metrics for your application.

Let’s check out a real world example. The Space Base Texture Compression Demo from our previous blog article achieves the following VRAM usage and download sizes (gzipped) on desktop in Chrome:

Note that VRAM usage for Basis would ordinarily be the same as with legacy compression. However, PlayCanvas compresses normal maps to YYYX format instead of XYZ for improved quality so utilization is marginally higher.

That’s a big saving of 52% (19.5 MB) in download size from updating the project to use Basis while using a similar amount of VRAM!

And all it takes is a couple of clicks in the asset inspector to get started with Basis compression!

To Recap​

• Only need one compressed file vs many (DXT, PVR, ETC1, ETC2, etc) for every texture
• Up to 2.8 times smaller files and faster download times for your users
• Up to 10x faster compression times with Basis
• Similar savings in VRAM usage as hardware supported formats
• Same one click process to compress textures

Basis texture compression is available to everyone right now so start crunching down those textures! More information can be found in the documentation including a migration guide.

And if you’re new to PlayCanvas, why not sign up today. We can’t wait to see what you make! Let us hear your feedback in the forums!

Big news! PlayCanvas is excited to introduce easy texture compression, enabling you to build bigger and better WebGL apps.

Today, the vast majority of WebGL developers load textures from JPG and PNG images. Unfortunately, while these formats compress well for transmission (especially JPG), they occupy a great deal of video memory when passed to WebGL. For example, let's consider this image of the Earth:

The image is 4096 by 2048 but compresses well to a 1.81MB JPG file. Under the hood, WebGL expands this image to uncompressed 24-bit RGB, using 33.6MB of VRAM! Now imagine a single material with diffuse, normal, metalness, gloss, emissive and opacity maps. 6 of these images will occupy over 200MB of VRAM. Now imagine having 10 or more unique materials in your app. Get ready for crashed browser tabs and unhappy end users!

WebGL solves this problem by providing support for a number of compressed texture formats supported in hardware on the GPU. Each GPU tends to support at least one of these formats. Today, WebGL has fairly widespread support for:

• DXT: supported by all desktop devices and some Android devices
• PVR: supported by all iOS devices and some Android devices
• ETC1: supported by most Android devices

PlayCanvas exposes these formats through a simple inspector panel on a texture asset. For the Earth image, it gives the following results:

The first number is the GZIPed file size and the second number denotes how much VRAM is occupied by the texture. Notice how the compressed images occupy one sixth of the VRAM when compared to the original JPG. This is a stunning reduction!

Let's turn out attention to the demo iframed at the top of this article. VRAM usage is as follows:

Texture Set	VRAM Usage (MB)
JPG + PNG	528.0
DXT	87.7
PVR	66.8
ETC1	87.7

Texture compression suddenly makes the demo mobile friendly. But notice how it loads incredibly quickly after loading a mere 4MB of data. How is this possible? The textures are using a technique called level of detail, where low resolution versions are loaded up front allowing the application to start, while the high resolution versions asynchronously stream in the background. Also note that the app doesn't have to load any lightmaps because they are created procedurally on application start using PlayCanvas' runtime lightmap generation.

PlayCanvas' approach ensures that the most optimal texture format is selected for the device on which your application is running. In contrast, the Unity WebGL solution loads DDS files and decompresses as necessary on platforms that don't support it. This means that mobile devices do not benefit despite mobile devices having the greatest need for compression.

Summary​

• One-click texture compression for DXT, PVR and ETC1
• Achieve at least 6 times compression of all texture data in your WebGL apps
• Most optimal image format selected for device running a PlayCanvas app

PlayCanvas Texture Compression is available from today for Organization and Personal account holders (see the manual for more info). It will be rolled out to all users following a short beta period. So go forth, compress your textures and take your WebGL apps to a whole new level. And if you're new to PlayCanvas, why not sign up today. We can't wait to see what you make!

DIRECT LINK TO RUN FULLSCREEN