7 posts tagged with "graphics"

It's here! 🥳 Today, we're excited to announce that WebGPU support has officially arrived in the PlayCanvas Editor.

WebGPU on the Rise​

Since its inception back in 2010, PlayCanvas has been layered on top of WebGL. In 2017, we were proud to launch support for WebGL 2.0 in partnership with our friends at Mozilla. April 2023 marked the beginning of a new era for web graphics when Google enabled WebGPU by default in Chrome 113. Since then, WebGPU adoption has exploded and today, Web3D Survey reports that 62.19% of end users can now run WebGPU. With Firefox and Safari due to launch their WebGPU support in the not-too-distant future, expect this number to rise dramatically in 2024.

Why WebGPU Matters​

If you enable WebGPU for your PlayCanvas project, you may not notice much difference to begin with. In fact, we have put a great deal of effort into ensuring your WebGL projects look identical under WebGPU. But over time, there is are a great deal of opportunities to achieve performance improvements due to WebGPU's reduced driver overhead.

Another key feature unique to WebGPU is support for Compute Shaders which allow for general computation on the GPU. Support for Compute Shaders landed in Engine v1.70.0. Here you can see Computer Shaders in action simulating 1 million particles on the GPU:

Click here to run it for yourself in a WebGPU-enabled browser (i.e. Chrome or Edge).

In short, WebGPU represents the future for PlayCanvas and you can expect some incredible advances in performance and functionality over the coming months.

Getting Started with WebGPU​

WebGPU support in PlayCanvas is still considered 'Beta'. There are still some unimplemented features (for example, the run-time lightmapper is still not supported). Therefore, you have to currently 'opt in' to WebGPU support. To do this, open your Project's Settings in the Inspector and expand the RENDERING section. Then update Graphics Devices to include WebGPU (beta).

Once we are satisfied WebGPU support has matured enough, it will become the default.

Your Feedback is Important​

Since WebGPU support is new, we rely on the community for feedback. What works and what doesn't? Please submit an issue if you discover any problems or kick off a new thread on the forum if you want to discuss WebGPU support in more detail. We want to hear what your opinions! 👂

PlayCanvas Bytes is where we talk about upcoming work with PlayCanvas and related topics.

Today we have our tech lead, Donovan and our graphics engineer, Gustav who are here to talk about work they've done and planning to do with the Shader Chunk system

• 00:00 Intro
• 00:45 Why are we making these changes?
• 06:19 Work on glTF extensions
• 08:50 Versioning of Shader Chunks
• 10:24 Process for communicating these changes in the Engine 1.55 release
• 11:00 Who will be affected by these changes?
• 11:30 Documentation of these changes and where to get help
• 13:40 Expected new features from these changes
• 17:15 How are we testing rendering changes?
• 23:10 Outro

Let us know your feedback in the forums!

Our team has been working on a new lighting system for a while now, and it has reached the stage where we're excited to share it with the community!

Pool Demo from Solar Games using Clustered Lighting

The new system leverages the clustered lighting rendering algorithm and represents a significant advancement over our current lighting approach. New benefits include:

• Increasing the maximum omni and spot light count to 254.
• Improved application performance with more omni and spot lights.
• Quick enable/disable of omni and spot lights without expensive shader recompilation.

Some of our early adopters are already using it to enhance scenes dynamically with fireflies at night, gunfire muzzle flashes, and highlighting objects in the world.

We've reached a milestone where the feature is stable, and we invite you all to try it! We are eager to see how you will integrate it into your games and applications.

Full documentation is available detailing all the features and explaining the options. Although Editor integration is still in development, we've created an example project linked in the documentation. This project includes a script that simplifies enabling clustered lighting, which can be copied and pasted into your own projects.

We plan to make clustered lighting the default system in the midterm, with the option to use the current system, as the advantages are significant. In the longer term, we aim to phase out the current lighting system to reduce engine file size, fully transitioning to clustered lighting.

As always, we value your feedback and would love to hear your thoughts on using the clustered lighting in the forum thread here.

Useful links​

• Clustered lighting documentation with example project
• Feedback forum thread

Way back in 2014, PlayCanvas was the first WebGL Engine to integrate PBR (Physically Based Rendering). To mark the event, we built the Star-Lord tech demo:

In the intervening 6 or so years, PlayCanvas has moved on dramatically. So we decided to leverage all of the latest engine features and republish it.

The most significant improvements are related to load time. Let's start out by comparing some key stats:

	Star-Lord 2014	Star-Lord 2021	% Change
HTTP Requests	220	39	↓ 82.3%
Preload Transfer (MB)	10.1	5.6	↓ 44.6%
Total Transfer (MB)	13.7	9.9	↓ 27.7%
Total Resources (MB)	26.0	12.1	↓ 53.5%
Load Time (s) *	1.8	1.2	↓ 33.3%

* Cache disabled on 100Gbps connection

Those are some pretty significant wins! So what are the differences between the two builds of the demo? Let's step through them one by one.

Convert JSON Meshes to GLB​

In October 2020, PlayCanvas officially switched from JSON to glTF 2.0 (GLB) for storing all model and animation data. While gzipped GLB is reasonably similar in size to gzipped JSON, it is up to an order of magnitude faster to parse a GLB file once it has been downloaded. Plus, a GLB file occupies less system memory than the equivalent JSON file. Converting all of the assets from JSON to GLB is a simple process. First, flip the project setting 'Convert to GLB' in the 'Asset Tasks' group to true:

Now, simply reupload all FBX files and a .glb asset will be generated rather than a .json asset. The last step is to use the Replace command in the right-click context menu to replace the .json asset with the .glb asset (plus any materials as well).

You can then delete the old JSON asset (plus any unreferenced related materials).

Basis Compress Textures​

Last month, we announced the integration of Basis texture compression into the Editor. Star-Lord was originally configured to use DXT, PVR and ETC compressed textures. A download size comparison is as follows:

Texture Format	Download Size (MB)
DXT	7.56
PVR	6.09
ETC1	7.18
Basis	2.38

This explains much of the download savings in the updated version.

Fortunately, applying Basis compression to the app's textures is literally a two-click operation:

Prefilter Cubemaps in the Editor​

When PBR first arrived in PlayCanvas, the Editor could not prefilter cubemaps. This conversion had to be performed externally with RGBM format cubemap faces being added to the Editor:

Each cubemap had 6 mip levels with 6 faces for each level. And with 5 different cubemaps, that meant 180 of the demo's 220 HTTP requests were for these PNGs!

These days, the Editor makes is super easy to import 6 HDR cubemap faces, build a cubemap and then prefilter it.

So instead of loading 180 PNGs, the demo now loads just 5 DDS files. Much faster. 🚀

Asynchronously Load Assets​

To achieve an optimal load time, it is important to only load what is required to make your app functional. It is arguable that music is not strictly a necessary precondition for your app to start. Therefore, the demo now asynchronously loads the mp3 asset that contains the music track and auto-plays it as soon as it is downloaded. It is 3.9MB which accounts for nearly 40% of the app's payload! So be sure to carefully audit your app for assets that can be streamed instead of preloaded.

Read more about preloading and streaming of assets in the User Manual.

Useful Links​

• Star-Lord Project
• Star-Lord App
• User Manual: Optimizing Load Time
• User Manual: Physically Based Rendering

The PlayCanvas team is super excited to announce the Editor support of glTF GLB conversion with model and animation imports.

This gives developers an order of magnitude reduction in load times compared to the JSON format while keeping similar gzipped download size.

Using the Stanford Dragon model (2,613,679 vertices, 871,414 triangles), we can compare GLB and JSON parse times on a Macbook Pro 16 inch.

The JSON format took over 3 secs just to parse the data, a peak memory usage of ~498 MB and a gzipped package size of 28.1MB.

GLB speeds ahead taking only 0.193 secs which is 17x faster, uses a peak of ~25.2 MB of memory and a gzipped package size of 25.7MB! 🚀

That’s a huge saving in time and means applications will become snappier and more responsive to users, especially for content heavy games and product showcases.

We will be deprecating the use of JSON and the default format that model and animations files. Newly created projects will default to converting to GLB and in existing projects, this can be enabled in the projects settings:

If you would like to replace your current JSON assets with GLB, the User Manual has more information about the process to migrate over.

The conversion to GLB supports the importing of multiple animations in a single FBX which will help improve content workflows.

Remember our awesome glTF 2.0 Viewer? That is now integrated into the Editor to inspect any GLB asset from the project. Just right and select ‘Open In Viewer’!

Also, we have exposed Animation Import Settings under Asset Tasks in project settings. These will allow developers to adjust a balance between animation quality and fidelity against file size.

Our next steps are to add support for viewing and editing a model hierarchy in the Editor which will lead onto support for the importing of GLB files.

The team is hard at work designing and implementing these features so watch this space!

May is drawing to a close and it's starting to feel like summer here in London. Let's celebrate with a PlayCanvas Dev Update! We've been busy bees, so here's a rundown of the main changes.

Variance Shadow Maps​

The light component now allows you to select a shadow type. In addition to the current PCF Shadow Maps, there are new options for 8-bit, 16-bit and 32-bit Variance Shadow Maps. 8-bit VSM uses a small amount of GPU memory and is guaranteed to work on any device but is lower quality. 32-bit VSM uses a lot of GPU memory and relies on a device's ability to render to floating point textures but the quality is very good. 32-bit VSM will gracefully fall back to 16-bit and then to 8-bit should the device not provide the required capabilities.

Let's compare PCF with VSM. First, here's PCF:

And here is VSM:

The big advantage of VSM is the ability to apply large blur kernels, which would be prohibitively slow with PCF. As you can see, the results are most pleasing!

VSM is still work in progress so expect more updates to land in the engine in the coming weeks.

Reworked Editor Camera Controls​

We've completely rewritten the controls for the Editor camera in the 3D view. It should be far more intuitive now and also enable you to be more productive. For example, we have changed the behavior of dollying the camera to be based on what the mouse cursor is pointing at. This makes it feel much more similar to Google Maps:

Easy Asset Inspection in Dev Tools​

We've made it so your assets are displayed in your browser's Dev Tools as they are in Editor's Asset Panel. This makes it much easier to locate, inspect and debug when running your game launched from the Editor.

Engine Optimizations​

We've performed a thorough round of engine optimizations, aimed at speeding up your games, but also to reduce memory allocations to avoid garbage collection stalls. Specifically, we have:

• Created a special profile build of the engine which is now only used when you run the PlayCanvas Profiler from the Editor. The regular non-profile build has the code that collects all of the timing and statistical information stripped out.
• Optimized many commonly used functions. Here is a good example.
• Removed many allocations that used to happen at runtime. Here is a good example.

Other Changes​

• Editor tooltips have been refactored with any missing ones added.
• Improved reporting of an asset's references when right clicking it in the Asset Panel.

For many years, lightmapping has been the mainstay of achieving low cost yet realistic lighting. However, it's rarely seen in WebGL applications because generating lightmaps requires third-party modelling applications with complex workflows in order to bake out textures.

All that changes today as we introduce Runtime Lightmap Generation into the PlayCanvas Engine.

Here's a link to full demo.

The demo above shows the engine's lightmap generation in action and this functionality is now available to all users via the PlayCanvas Editor.

How does it work?​

For the uninitiated, lightmaps are extra textures that contain pre-computed lighting information that are applied to models at runtime. This means that instead of expensive per-pixel lighting, you can pre-compute static lighting that is incredibly cheap to render on the GPU.

We've also specially designed our lightmapping solution for the needs of the web. In the Sponza scene above, there are 5 lights which generate 65 lightmaps applied to the 240,000 triangle mesh that makes up the scene. In total, this generates over 60MB of HDR lightmap textures. Even with an excellent compression ratio, it would be very time consuming to download this texture data. So we've designed the PlayCanvas lightmapper to be unique among both native and WebGL engines. The PlayCanvas Engine generates all lightmaps on application start. In a few hundred milliseconds, we generate all the textures required for static lighting so your scene runs super-smoothly across all devices.

What's good about it?​

Performance​

Just see for yourself. Switch between the lightmapped and dynamic lighting modes in the Sponza demo above. On a MacBook Pro or a recent mobile device like a Nexus 5 or iPhone 6, the lightmapped scene runs at 60fps. Using the real-time dynamic lighting we have to sample 5 filtered shadow maps (one for each light) which seriously affects performance.

With this new feature, we're enabling WebGL developers to create beautifully lit 3D scenes that run in all browsers from low end mobile to high end desktop. Not only will your application run smoothly on mobile, it will also load incredibly fast.

Ease-of-use​

The lightmapping tools are built directly into the Editor. To get started, you just need to flick a couple of check boxes on your light and model components and hit the Bake button. Find out more by reading the new documentation.

Features, Features, Features​

Of course, there are also all the bells and whistles that make the lightmapper a dream to use. We generate HDR lightmaps so everything looks great. You can mix and match your static and dynamic lighting to give you the best of both worlds. We even auto-magically UV-unwrap your models if you haven't already generated lightmap UVs.

What's next?​

This is just the first step for the PlayCanvas Lightmapper. We'll soon be adding support for Specular Reflectance to the lightmapper. And beyond that: Global Illumination.

But don't wait, runtime lightmap generation is available to all users right now. Go try it out today!