Map/level workflow

Help & Support
1

In my todo list, there were three big hurdles:

  1. Get player and weapon logic and physics working
  2. Get multiplayer working
  3. Generate a solution for maps.

Now that I’ve solved the technical challenges on #2 I need to start thinking about #3.

So, I want developing maps for my game to be easy. I want to be able to whip up a model in blender, chuck some lights around, put in an empty or two to represent spawn-points, do some UV-unwrapping. Then I want to somhow get it into my game. Something like this:

Brain --> Blender --> ???? --> My game

For all the assets I’m relatively happy using the playcanvas website because they’re static and rarely change, but levels are different. Development is more incremental and levels also contain light data and spawn-point data which the JSON model format doesn’t support.
So I need some process that takes in a model and spits out a bunch of JSON files.

  1. A month or two ago I entertained the idea of a python Colladae to JSON converter. (with separate files for lighting and spawn information) I determined it was possible, but was not something I wanted to maintain and would take a long time to develop.
  2. Another option was to write an extention for playcanvas allowing it to import collada. A brief look told me this would take even longer. I don’t know the code-base well enough. and the javascript collada importers are all aimed at three.js
  3. I’ve even thought of funding someone to develop either of these ideas. (This is still a serious possibility. I’ve no idea if the playcanvas team accepts bounties on feature requests, but I’d be happy to put several hundred on either an offline JSON exporter (must be cross platform and open-source) or getting playcanvas engine to support a standard format).

So where does this leave me? Well, it leaves me with a slow, multistage process. I need to write one script to export light and spawnpoints, then for each level made, they need to be exported to .dae, uploaded to playcanvas, texture-paths corrected, downloaded, uploaded to the games webhost. That process will take at least half an hour. For level development, a very much incremental process, that’s too slow.

At this stage, there is still a couple months before this becomes the limiting factor in development, but it’s time to start thinking about it.
So. Any ideas or suggestions?

2

There is another option, which would be if you make nodes in Blender, with specific naming convention, that would represent different objects and their data. That you could simple parse in Editor via script, or on runtime from game.
First option, to parse model using script, and produce some entities based on that is good that will allow you to see how your level would exactly look in game already in editor, and alter some other stuff right within editor.
Second option, is to parse your stuff during game loading to create specific entities.

Another option would be to create you geometry in Blender, but actual level data in Editor. You do self host your project, so you must already know that there is json hierarchy data available. Editor is great to alter that data. You can do it as separate Scene in Editor. Or do in single Scene, under different entities, then you can just take piece of that hierarchy JSON as you need.

I think using Editor is more intuitive way, and will let you to setup visually your game in more controlled way for PlayCanvas Engine. It is easier to get desirable end results by altering data in Editor, rather than in Blender.

3

I’m not just wanting to be able to place predefined assets (which I had already thought of doing via method 1), but to be able to do a mesh+image workflow. So the person works in blender creating a level as a mesh and assigning textures:

mesh.jpg946×742 91.2 KB

Data like light positions and spawn-points can be easily encoded in separate JSON files, but the mesh data has to be able to be parsed by the playcavas engine.

Is there an externally accessable API for converting collada to .JSON?

4

You can save this model as FBX, then import in Editor, our assets server will do conversion for you. Then you can modify its materials, textures, appearance etc, as you need to.
If you need to download JSON with related data to load off tools, then you can do it by hitting “archive” button in inspector by selecting model asset.

5

There are two reasons I want to go from blender -> playcavas engine without going through the editor:

First:
I don’t want to be the only person making levels. Requiring people to sign up for an account at a third-party website is a sure way to make sure no-one else makes levels.

Second
It also means that I have to keep updating my models to fit with all the changes you make. At some point I want to freeze the version of playcavas I’m using so that maintinance of my project becomes easier.

Over the next three years I’m working on this project, playcanvas will get much much better, but the bigger my project gets, the more maintinance each tiny change to the engine has on my workload. I experienced this in the Blender Game Engine. The changes were tiny, the way materials were handled changed mean I had to go through and tick a tickbox on every single object. Needless to say, four years in I was tired of trying to figure out what broke and how to fix it.
Because my project is small at the moment, I can keep up with maintinance, but If I were always updating to the latest playcanvas, and had dozen levels. Then if you change the engine’s format for handling models, then I have to update the dozen levels and can not make any new ones unless I do.
Already I haven’t updated playcanvas in months now. There’s no point. If I do it will only break things. Already the slight changes in the way materials are handled means that I have to hand-edit the materials to get them to work. (As well as to fit within my project folder-structure, but that’s my own personal choice)

It is in my best interests now to make sure I have an alternate path for importing models, because at some time in the future, I’ll have to have one.

This is the universal problem with open-source game engines. and is why closed-source engines like Unity tend to do better with large projects. Unity updates both minor (bugfixes) and major (new versions). You stick with the version you started the project on. With open-source engines, there are just releases, and changes are introduced gradually. As your project dates, you start to see this:

ProjectTime.jpg1563×731 68.5 KB

(Some of that is due to bugs, but a lot is due to libraries. Just have a look at all the archaic dependancies you need to build big pieces of open-source software)

6

Actually, it is a more of a problem to off-tools users.
With Editor users it is less of a problem, as we are very careful when we make defaults changes, or handling changes. We always work of migrations of fallback solutions, that allow seamless transition for Editor users.
It does happens rarely that it is too complex to migrate, so we have to do certain things to reduce the “pain” but unfortunately, change always comes with some cost. This wouldn’t allow us to get to the level of features and quality we have now if we would not be able to change that easily.

With model format, if we change model format, it shall not break any existing games, and shall not have any implications on public API functionality. It is totally internal thing. Unless you need to deal with that format and go to internals - then yes, you will be affected.

Model format it self is fairly simple, and straight forward. We’ve seen some users writing their own converters already. If you just do some simple examples, you’ll see that JSON model format is self explanatory, and should be able to write simple converter for you needs yourself.

7

Yes, it is easier if you use the editor. Indeed, you have provided a (as far as I’ve played with it) seamless experience there. But that assumes a stable and fast internet connection. Unfortunately I do not have that.

Yes, you do need to make breaking changes, it is impossible develop properly future-proof software.

With model format, if we change model format, it shall not break any
existing games, and shall not have any implications on public API
functionality. It is totally internal thing. Unless you need to deal
with that format and go to internals - then yes, you will be affected.

Unfortunately anyone who uses the engine external to the editor has to deal with that format.

Model format it self is fairly simple, and straight forward. We’ve seen
some users writing their own converters already. If you just do some
simple examples, you’ll see that JSON model format is self explanatory,
and should be able to write simple converter for you needs yourself.

That was probably me. I’ve written a basic offline material editor a month before you changed the format, and wrote a blender -> model exporter that didn’t support UV’s (due to lacking documentation on blender’s side).
I think I’ll have another shot at it, see if I can find a nice model format blender can export that I can parse into .JSON. Any suggestions?

8

Sorry if it did affected you that way.
Engine actually had code to handle legacy material format.
New format in fact is way simpler and easier to work with, and is smaller.

Sorry, but I didn’t worked with Blender plugins.

9

New format in fact is way simpler and easier to work with, and is smaller.

I do now work with the new format. I jsut need to re-code my material editor to support it. However there was another, small, more recent change that (as of my last model a week or so ago) all materials came out black for. I couldn’t see anything obviously wrong, so I just took some copies of my existing materials and tweaked them.

Sorry, but I didn’t worked with Blender plugins.

I’ve just discovered that three.js has a json exporter for blender. The format is slightly different, but it’ll give me a much better base to work from than last time (where I started form scratch).

Thanks for all your suggestions and the interesting discussion.

1 Like
10

You might want to take a look at the FBX SDK. There are python bindings if you don’t want to use the C++ libs. It will handle a lot of the nastier bits of loading anding parsing all kinds of files. Then you can use their internal representation to output the json.

11

Case in point:
Today I tried to update my version of playcanvas from 0.173.9 2e4ec51 to 0.179.0 65961bc. And physics broke. Triangle mesh collisions no-longer work, though sphere and capsule do.

No errors in console.

What changed in the way physics is handled between these two versions?

The relevant code:

    level.addComponent('collision', {
        type:'mesh',
        asset: app.assets.find(level_name+'.json')
    });
    level.addComponent('rigidbody', {type:'static'})
12

Well I now have a working mesh exporter from blender. It exports meshes and a single UV layer. It doesn’t do animations because I don’t need to do them for my levels (yet).

I’m hoping to have materails done by this evening.

13

this is interesting to note since this is supposed to be an issue with ammo.js and not playcanvas?