News

Autoreload of rules and scripts in Cyphesis

Posted by admin on May 21, 2018

I've done some work in Cyphesis to allow for much more powerful features for live editing of the world, mainly editing rules and scripts.

Cyphesis have since long before had support for live editing of rules. It has been possible to send Atlas operations from clients for editing or installing new rules.
However, this is not really the workflow you would want, since any rule change would be detached from the source code.
Instead you want a workflow where rules are stored in the source tree, using Git, and then updated in the running server when they are installed into the server installation location.
 
To achieve this I've worked on these areas:
1) Rules are no longer stored in the database (which used to be PostgreSQL, but now is SQLite). Only accounts and entities are stored in the database. The rules are instead stored on disk, as Atlas files (xml).
2) The Cyphesis server process will observe all file changes in the rules directory, and automatically reload any changed files.
3) The server will also observe all file changes for the Python scripts directory, and reload any Python scripts that changes.
 
This setup works nicely with CMake, since it will by default only install files that have changed.
The workflow is now instead
1) Make edits in the Cyphesis source directory for the rule or script you want to change.
2) Execute "make install" which will CMake copy only the changed files into the Cyphesis installation location.
3) Have Cyphesis automatically pick up on the change and reload or add the changes.
 
Having tried this workflow I can say that it's a huge improvement compared to the previous one. It's now much more easier add or alter entity types and alter their behaviour.
0 Comments Read full post »

SQLite used in Cyphesis

Posted by admin on May 21, 2018

Our main server, Cyphesis, now uses SQLite instead of PostgreSQL by default.

The main reason for this change is to make the system less complex and to make setup easier. For a long time we've used PostgreSQL as backend for all persisted data. Our persistence needs are however very modest. We only store accounts (created once) and entity state. As such we don't really need a complex database system; it's good enough with a simpler system.

Add to this that a lot of newcomers have had issues with getting postgreSQL properly setup. By switching to a less complex setup with SQLite we hope that it will both make the system easier to reason about and easier to setup.

0 Comments Read full post »

Updated Blender Addon

Posted by admin on April 20, 2018

The Worldforge Blender Addon has been seen a large update, adding some cool features and fixing some long standing issues. In this post I'll describe what's changed.

But first,

What is the Worldforge Blender Addon?

Blender is the designated tool used by the Worldforge project to create 3d assets ("meshes"). It's a fully featured, professional and totally free 3d creation tool. Since all of our assets are provided as Free Software it's important that the source material is in a format which allows anyone to access it. Hence we use Blender.

The Worldforge Addon provides an easy way for content creators to export meshes and armatures from Blender into a format which both the Ember client and the Cyphesis server can understand (the OGRE mesh format).

Worldforge Blender Addon

What's new?

No OGRE addon dependency

We no longer depend on the separate OGRE Blender addon. Previously our addon depended on the OGRE Blender addon also being activated, and delegated the actual export to it. This is no longer the case. It's now sufficient to solely install the Worldforge Addon.

Easier installation

The addon was previously split into two addons which interacted. Not anymore; now everything is contained in one (large) file. This makes installation for content creators easier.

Exporting scaled meshes and armatures

Previously the addon couldn't correctly handle export of scaled meshes and armatures (due to how the OGRE addon worked internally). This is now fixed, so any scaled object will be correctly exported.

Combine multiple meshes in export

If multiple meshes are selected they can be exported as one mesh, with many submeshes. The currently active object will be used as center.

Automatic material name generation

When exporting a mesh the addon will now take care of automatically figuring out the correct OGRE material name to use for submeshes. This is done by looking for which diffuse texture is used, and from it's location in the asset repository deducing the material name.

Automatic skeleton links

Animated meshes will now have the link to the skeleton used automatically deduced.

OGRE material generation

Any missing OGRE Material definition for textures used can now be automatically generated with the push of a button.

0 Comments Read full post »

Automatically built client

Posted by admin on March 13, 2018

The Open Build Service is a pretty awesome service which allow for (fairly) easy setup of automatic builds of packages on most major Linux distributions. We're currently using it to automate builds of all Worldforge components on OpenSuSE, Fedora, Debian and Ubuntu. Our own little space can be found here.

Check out the current status of the builds here

Apart from creating RPM and DEB packages there's also support for AppImage, which is an executable format for Linux. We already have it setup to automatically build the Ember client whenever the source changes.

The final AppImage binaries are put here, and a direct link to the latest Ember binary can be found at https://download.opensuse.org/repositories/games:/WorldForge/AppImage/ember-latest-x86_64.AppImage

We would love for users to try the client out and report any issues they are having with it. Packaging stuff on Linux can be a bit tricky.

4 Comments Read full post »

Recent changes to the client

Posted by admin on November 26, 2017

Screenshot_20171126_163942.jpeg

There's been a couple of changes to Ember lately. I'll try to summarize them here

 
* The biggest one is that we now use OpenGL 3 and later. Previously we used OpenGL 2. The main reason is that OpenGL 3 has a couple of features that we really benefit from, especially when it comes to instancing techniques. Support for this version should also be solid, with all modern GPUs providing compatible drivers.
Using OpenGL 3 also allows us to use more modern features for diagnostics.
This also sets us up better for a possible migration to OGRE 2.1+.
 
As part of this I've also removed our support for DirectX. The main reason is that I simply don't have time enough to support a second render system, with the need to provide matching HLSL scripts for all of our GLSL shaders. OpenGL works on Windows as well, although performance might suffer in some cases.
 
* The usage of Cg has been completely removed. The Cg shaders that we used have all been rewritten in GLSL.
 
* Almost all use of the standard OGRE Entity class has been replaced with InstancedEntity. This means that we're now much more efficient when rendering multiple entities of the same type.
OGRE is especially inefficient when rendering multiple entities of the same type, since each entity will result in at least one (often many) rendering call. 
Modern GPUs are however designed to easily handle large sets of data, with as few rendering calls as possible.
This is one of the reasons Ember often struggle on seemingly powerful enough GPUs.
With this change performance should improve.
With OGRE 2.1+ a lot of this has been redesigned however, and my impression is that Ember should perform even better on this platform.
 
* Hardware skinning has been added, so that all animated entities are now skinned on the GPU rather than the CPU.
 
* Support for the OGRE profiler has been added, so that an overlay showing time spent in various parts of OGRE can be shown. Enable this through the "Developer" tab in the settings dialog.
 
* We now have a benchmark in place, to be used for evaluating performance. It can be run by issuing the "/benchmark" command while logged in.
 
* Ember will automatically now detect when some media has been changed on disk, and reload it automatically. It currently mainly supports textures. I.e. if you alter a texture while Ember is running it will automatically reload it. Pretty nifty when working with media.

 

0 Comments Read full post »