Introducing the new Code Editor

Code Editor

Today we’re excited to unveil the new code editor for all our PlayCanvas users. We’ve been taking your feedback since we launched Scripts 2.0 last year and we’ve updated the code editor to make working on scripts in PlayCanvas much easier.

Some of the new features introduced by the new editor:

File view & tabs

The most obvious difference is now we let you browse all your text files in the code editor and open multiple files in the same window. No more hunting through browser tabs to find that file you were editing.

Goto Anything

Editor Goto Anything

Goto Anything (Ctrl/Cmd+P) is the power users dream option. Jump to any text file in your project with a few keystrokes.

Enhanced keyboard shortcuts

We’ve had a complete overhaul of the keyboard shortcuts. All your standard text editor shortcuts are there. Including using multiple cursors and expanding selections.

Better find & replace

Editor Find

We’ve beefed up the find and replace with a new interface and easy to use extras like case-senstive and regular expressions.

We hope you enjoy using the new code editor as much as we do!

WebVR support in PlayCanvas

Today we’re really excited to announce support for WebVR into the PlayCanvas Editor.

This week Google announced that WebVR 1.1 (the latest current version of the spec) should be released in Chrome for Android in January 2017. But for a feature as complex as virtual reality, browser support is only one piece of the puzzle. At PlayCanvas, we know how important great tools are to making high quality experiences so today we’re launching our WebVR engine integration to make sure that you can create applications right now.

PlayCanvas WebVR

Optimized Engine Support

The PlayCanvas graphics engine is an advanced WebGL graphics engine. We’ve worked hard to make sure our renderer is optimized specifically for stereo rendering. Unlike most engines we don’t simply render the scene twice for each eye. Instead, our renderer knows that a lot of the main render loop is the same for each eye. So, for example, expensive operations like culling, sorting draw calls and setting uniforms and render states only have to be done once before we draw the scene for each eye. This can lead to a significant performance increase, particularly on mobile.

Polyfill for unsupported platforms

It’s still early days for WebVR which means it’s not yet supported on all platforms. When you enable WebVR in your PlayCanvas project, we make sure your browser can support it using the WebVR polyfill library from Google. PlayCanvas is smart enough to load the library only if you need it.

Tutorials and Documentation

PlayCanvas is renowned for its extensive documentation and VR is no different. Basic instructions, API reference and specific optimization tips, we’ve got it all.

Samples and Starter Kits

These sample projects show you how to construct a VR scene and give you sample code to start from.

Hello World – A very simple 3D scene

360 Image – Just drop in your own 360 panorama

360 Video – Add a link to your own video

Room Scale VR – A more complex scene designed for HTC Vive and other Room Scale VR

The Future

We believe the future for WebVR is very bright and we’re committed to making PlayCanvas the best tool for creating WebVR applications. Sign up for free today, we’d love to see what you build!

PlayCanvas Scripts 2.0

We’ve just launched “Scripts 2.0”, a complete re-design and re-implementation of the scripting system for PlayCanvas applications. Our goals were to fix an array of small irritations that had built up over using the PlayCanvas scripting for the last few years and take the opportunity to clean up the interface and simplify the creation and usage of scripts.

Here’s a list of the improvements you can enjoy with the new script system:

  • rapid iteration by hot-swapping code at run-time
  • real-time collaborative code editing
  • script concatenation and minification for publishing
  • better error handling and fault tolerance
  • full folder support for script assets
  • multiple script definitions in a single file
  • simpler interface and boilerplate

Live hot-swapping

If you choose to, you can now allow your scripts to update all running instances of your application. We dynamically reload scripts after they change. By implementing a single swap() function, you can transfer state into your new script instance and carry on as if nothing had happen. Except you’ve got all your new code!

Real-time collaborative code editing

Now that scripts are first-class assets, we now support real-time collaboration in the Code Editor. This means you’re no longer in danger overwriting other people’s code. In fact, you can see it appear as they type.

To help support this, we’ve also improved the error handling and fault tolerance of scripts while they’re running. This means bad scripts won’t bring your game screeching to a halt, preventing everyone from working.

Script Concatenation

With the new script format we now support multiple script definitions in a single JavaScript file. We’ve added the option to concatenate and minify all your scripts into one file when you publish. This will save you many HTTP requests and reduces the size of your application, making for a much quicker start up time.

How do you find these new scripts?

Scripts 2.0 is live right now and any new projects you create will have the new script system enabled. However, if you’re not quite ready to move to the new system or you need some of the features that are currently only available with the old system, you can still create projects using the “Legacy Script System”. Look for the option in the new project dialog.

If you haven’t tried PlayCanvas before:

SIGN UP TODAY

Runtime Lightmap Generation for WebGL

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.

… 

Easy Cardboard VR in WebGL

Today we’ve launched a new library and developer tutorial and sample project showing you how to implement your own Cardboard VR web applications using PlayCanvas.

cardboard-vr

Google’s Cardboard VR is an excellent low cost device for experiencing virtual reality via your phone and a simple head mounted display. At PlayCanvas we immediately saw the benefit of using WebGL to display 3D VR experiences right in your browser. With WebGL VR you can distribute VR content quickly and easily to every user with a mobile web browser. With nothing to install there is no barrier to entry.

The PlayCanvas WebVR plugin makes it simple to add support for VR to your application. Simply add a couple of javascript files to your PlayCanvas project and add the VR Camera script to your camera entity. That’s all it takes to add VR support to your project

Our demonstration project shows you a example of a simple interactive VR scene that you can use to learn.

On a mobile device just tap the view above to enable the Cardboard VR mode. Our tutorial will walk you through how to add VR to your projects.

This is the start of VR support in PlayCanvas and we’ll be working to integrate Cardboard VR and WebVR closer into the editor as they get more popular.

Moving playcanv.as to HTTPS

tanx

TANX running on HTTPS

From today we now support HTTPS URLs on all published applications. So anytime you see a link to something on http://playcanv.as you can also use https://playcanv.as. After a short period of testing we’ll be changing all default links to point to the HTTPS versions of the applications, though we will keep support for non-secure HTTP versions for the short term to ensure compatibility for applications that require a non-secure page.

There are many reasons to use a secure HTTPS page, especially if you are doing transactions or taking money. But primarily for you as a PlayCanvas developer we’re supporting HTTPS for two reasons.

Embedding

With an HTTPS page you can now embed the your PlayCanvas applications in any other page that requires a secure URL. Of note, this includes Facebook Canvas games, so you can now publish your PlayCanvas game directly to Facebook.

Secure Powerful Features

Major browsers such as Chrome and Firefox are currently in the process of securing all “powerful features”. Which means only allowing access to these features on secure pages. These features include:

  • Device Motion
  • Device Orientation
  • Encrypted Media Extensions
  • Fullscreen API (including pointer lock)
  • Geolocation
  • getUserMedia (webcam access)

Soon it won’t be possible to access these Javascript APIs without using a secure HTTPS page. In advance of this time, we want to make sure your hosted PlayCanvas applications can support all these features.

What this means for you

As a developer our transition to HTTPS should be seamless and you shouldn’t notice. Though one area to watch out for is that an HTTPS page is not able to load resources from a non-secure page. So if you are loading fonts or images from other servers that are insecure they may be blocked (depending on exactly how you load them) when running your PlayCanvas application from HTTPS. The solution is to make sure all external resources are loaded via HTTPS.

 

Feature Update: Import Pipeline Improvements

Today’s new features are part of our on-going process of making your PlayCanvas experience easier and easier. And despite the title, we’ve released some awesome changes today.

Asset Import Pipeline

Asset tasks

We’ve introduced a lot more control over the way that assets are imported into PlayCanvas. You will discover these options in the Asset Tasks panel and the Asset Task Settings.

You can read all about new asset pipeline features in our developer documentation. But here are the key facts.

Auto-run

You can now choose whether to run the pipeline automatically when you import an asset. This gives you more control over the options you apply to each individual asset.

Non-power of two textures

You can now disable the conversion of textures to the nearest power of two. If you’re using images in HTML or in your user interface. This can be very useful.

Overwriting behaviour

When you start iterating on models you often want to upload a new FBX file, but only update some parts. For example, you will often have created your own materials and don’t need to original materials from the FBX file. You can now choose which parts of a model file you wish to import, model, animations, materials or textures.

In other news:

Project Settings

You can now access your project settings directly in the Editor. Click the settings cog to see the update settings panel.

Script Uploading

You can now upload scripts from your computer into the asset panel.

Model meta data

model-meta

When you upload a model, we now show you properties like the number of vertices and mesh instances in the asset properties.

Asset References

references

If you right-click an asset in the asset panel. There is references option which will tell you everywhere in the scene where that asset is currently used.

Don’t be put off by the dry sounding tech-talk these are great new features which will make you more productive. Get into the Editor and give them a try.

Enhanced Asset API

Today we’re pleased to update the engine and tools with a new Asset API. We’ve finessed the API to make it more intuitive and also added some extra features to make it easier for you to preload or stream in assets at any stage of your application.

This post should introduce some of the new APIs, plus give you an upgrade guide for areas of the API which have changed.

First some terms. When we talk about a “resource” we are referring to some data, usually stored in a file, that can be loaded by a PlayCanvas application. When the resource data is loaded, the engine creates a instance of some class that came from that data. e.g. the resource “image.png”, is loaded to a creates an instance of a `pc.Texture`. The same applies for a 3D model, an animation or sound effect.

When we talk about as “asset” we are referring to a reference to a resource, with some associated data. For example a texture asset looks something like this:

{
 "id": 14761,
 "name": "Cerberus_G",
 "type": "texture",
 "preload": true,
 "file": {
  "url": "files/assets/14761/1/Cerberus_G.jpg",
  "size": 816084,
  "hash": "dc49dac4f4775191b7643b4583b3ac3f",
  "filename": "Cerberus_G.jpg"
 },
 "data": {
  "minfilter": "linear_mip_linear",
  "name": "Cerberus_G",
  "magfilter": "linear",
  "addressu": "repeat",
  "addressv": "repeat",
  "anisotropy": 1
 },
}

You can see the asset data for this texture as an ID, a Name, a reference to the file where the resource data is, plus some additional data which isn’t stored in the image file. This data is used to create the texture resource. Some assets contain lots of data (materials) some none (a text file).

Once loaded into the engine, you can use the asset registry to find assets, and you can access the loaded resource (if it is loaded) from the asset using the `asset.resources` property.

On to the changes:

Editor Changes

Asset Preloading

preload

The first new feature is asset preload. Previously we would load any assets that were referenced by your scene. We changed this behaviour so that now assets have a specific preload property which you can enable or disable. Any asset marked as preload, and we default this to true for new assets, will be loaded during the loading screen stage and will be ready to use when your application starts. Any that are not marked as preload, will remain on the server, ready to be loaded when you need them.

We’ve updated existing assets to mark all existing target assets are preload. So you may need to uncheck this option on some assets if you don’t actually need them.

Export and Publishing

When you publish an app or choose to download an export of your app, we now include all assets in the package. As you can choose whether or not to preload assets, this means that you can select only a subset of your assets to be loaded before your application starts. Then you can load other assets at any other stage later on. This lets you use many more assets in your games and applications but not worry about start up time. Just stream your assets in later on.

Script Loading Order

Script loading has had an overhaul, we now load scripts in parallel with other assets so load times should be reduced. We have also changed which scripts are loaded. Previously, we’d only load scripts which are referenced in scenes. We now load all scripts in your repository. Because of this we’ve introduced a way to set the order in which your scripts are loaded.

script-priority

Found in the menu, you can use the script loading priority dialog to choose scripts you wish to load first.

API changes

Asset Registry

The `AssetRegistry` object has changed slightly in the new API. The core methods are shown below. As before the `AssetRegistry` object is available in your scripts as `app.assets`.

app.assets.get(id) - get by id
app.assets.find(name, type) - search by name, return first result
app.assets.findAll(name, type) - search by name, return all
app.assets.load(asset) - load remote resource for asset

The main change here is that `load()` no longer accepts a list of assets and it no longer returns a promise. We’re removing promise from the engine in favour of node.js style callbacks and events.

Note, we have left in a compatibility version of assets.load which accepts a list of assets and returns a promise. You should update your code to remove this as it will not be in the engine forever.

Asset Events

The asset registry (and the asset object) fire a consistent set of events which you can use to react to changes on the registry. These can be used to monitor loading progress or respond if you wish to dynamically add assets to the registry.

assets.on("add", callback) - triggered when asset added to registry
assets.on("add:{id}", callback) - triggered when asset added to registry
assets.on("add:url:{url}", callback) - triggered when asset added to registry
assets.on("remove", callback) - triggered when asset added to registry
assets.on("remove:{id}", callback) - triggered when asset added to registry
assets.on("remove:url:{url}", callback) - triggered when asset added to registry
assets.on("load", callback) - triggered on successful load
assets.on("load:{id}", callback) - triggered on successful load
assets.on("error", callback) - triggered on asset loading error
assets.on("error:{id}", callback) - triggered on asset loading error
asset.on("change", callback) - triggered when asset data changes

A good pattern for loading and using an asset is like this:

asset.ready(function (asset) {
    // use asset.resource here 
});
assets.load(asset);

asset.ready() will call the callback when if when the asset is loaded. It’s it’s already loaded from before, the callback is called immediately. asset.load() does nothing if the asset is already loaded.

Resource Loader

The resource loader is a lower level interface than the asset registry. Most users won’t need to access this directly as they will use the asset registry to load data. But this API has changed significantly. We’ve made it much simpler:

app.loader.load(url, type, callback);

I’ll just leave it there, see the API docs if you need more information.

Application Scene Loading

We’ve added a simple API for loading new scene data via the `app` object

app.loadSceneHierarchy(url, callback) - load a scene file, get hierarchy, append hierarchy to app.root
app.loadSceneSettings(url, callback) - load a scene file, apply settings (lighting/physics) to current scene

These two functions accept the URL of the scene file which will be in the format “scene_id.json” e.g. “100.json”.

Upgrade guide

Hopefully you’ll find your application continues work as before, only now it loads faster and you have more options available to you for dynamically loading assets. However, this is a breaking API change so you may need to update your projects.

app.assets.load(asset)

If you are using this and passing in a single asset, we no longer return a promise. You should replace your code with this:

asset.ready(function (asset) {
  // use asset
});
app.assets.load(asset);

app.assets.load(assets);

If you are loading a list of assets, our compatible load should still work. However, you should update your code to use the new loading format. As below

var toload = []; // list of assets
var count = 0;
toload.forEach(function (asset) {
   asset.ready(function (asset) {
   count++;
   if (count === toload.length) {
     // done
   }
 });
 app.assets.load(asset); 
});

app.loader.request()

If you were using this to make resource requests like loading Packs or asking for texture data. This is all new. You should be able to replace these calls with some other method. Maybe `app.loadSceneHierarchy()` or by using asset preloading to delay loading texture data. However if you really need to load a resource directly. You can use the resource loader API:

app.loader.load(url, function (err, resource) {
  if (!err) {
    // use resource
  }
});

That’s it! If you notice any problems or have trouble upgrading, get in touch on the forum.

The DevLog – PlayCanvas Community Feature

We’ve just rolled out the Developer Log or DevLog. The first of several community features coming soon into PlayCanvas.

Keeping people informed

DevLog___Dashboard___swooop___PlayCanvas___3D_HTML5___WebGL_Game_Engine

 

To create a game you have to complete thousands of little tasks over the course of development. Each day you tick off a few items in your todo list, squash a few bugs or updated a few models. When you are using source control with each change you commit to your code you include a commit message. This tells the rest of your team what’s changed and gives you a good reference point to look back on what state the code was in.

We wanted to introduce something similar into PlayCanvas, so that you can log messages which you and your team can use to track development of your game. But we wanted to do more than just that. A PlayCanvas project is more than just a collection of your assets, it’s your link to your game’s fans; it’s an advert for your game and what you want your game to be; and it’s a place to gather feedback about what people love (or don’t love) about your game.

So introducing:

The DevLog

Every PlayCanvas project now has a DevLog, you can find yours on the right-side of the navigation bar with a little speech bubble icon. (Yeah, we know it’s pretty hidden away at the moment, we’re working on that).

Think of the DevLog as part commit message, part blog, part twitter stream. Use it to let people know what you’ve been working on. Perhaps each day you will do a update summary, maybe you’ll do 5 a day, or one a week. Whatever works for you. People who come to your project page can read your log to find out about your project. In the coming weeks we’ll be featuring log posts on the front page of the site so that everyone can see what is going on across PlayCanvas’s thousands of users.

Features

Primary, the DevLog is a place for you to write about your game. But you’re a creative bunch so we wanted to give you a little more than just a text box.

Markdown

Markdown is a simple way to let you add styles, links, images to your text. The markdown syntax is easy to learn and remember. We don’t host images (yet) so you’ll have to make do with images that are already on the web somewhere else (for the moment).

Emoji

Emoji is like smileys++. Use the emoji cheat sheet and enter your emoji by including a keyword between to colons. Like 🙂

Preview

Use the preview tab to see what your post will look like with all the styles, images and emoji.

Let us know what you think of the new feature.