Blockspell is a 32 person multiplayer magical combat game. Users cast procedural spells by pressing keys bound to different elements (ie: air, earth, water, fire, etc). The client will be closed source and the server will be open source. The client is currently written in C++, and the server is written in Erlang.

Looks very nice! I particularly like the second one with the skybox.

I've also got a .vxl map loaded now and I'm seeing a constant 60 FPS. However, I reduced the map to 16-bit RGBA which means adjacent voxels are more likely to merge during simplification (I add noise later to cover this up). So technically my data isn't exactly the original. I'm also splitting the mesh into 64x64x64 voxel regions though I don't know how that's affecting the framerate.

New video:

http://www.youtube.com/watch?v=xSU04l4mIeU

Looking very nice, I particularly like the ambient occlusion. What approach did you take did you take for that in the end?

The shading is the minecraft smooth shading algorithm as described here: https://github.com/overviewer/Minecraft-Overviewer/blob/master/docs/design/designdoc.rst#smooth-lighting

Additionally each face has another scalar value associated it to help with differentiating between different faces on the same block. In my engine, the top face of the block has a scalar value of 1.0, the bottom has a value of 0.55, left and right have a value of 0.85 and the front and back faces have a value of 0.7.

I ran the game on my 7 years old laptop (ATI Radeon Xpress 1150). I got a frame rate of about 20 fps on an average vertex count map (Ravenloft) with the smooth shading and anti-aliasing disabled, and the viewing range turned down. Pretty much unplayable.

I tried it on my parent's computer with a Radeon HD 7350 and got a frame rate of 150. This computer is about a little over a year old (and not a gaming pc).

On my computer with a GeForce GT 555M I get a frame rate of about 500 fps.

Do you think that the performance is acceptable? I don't think it's anywhere near the performance of voxlap or other engines like this http://www.forceflow.be/2013/02/07/spar ... ss-report/

I'm not sure what other optimizations I can make... I'm not even using any special lighting stuff right now. Everything is baked directly into the vertices.

Edit: another issue that I discovered when running it on the super slow machine was issues with the physics system (ex: falling through floors). I talked to mat^2 and he said that he switched from a custom implementation to using bullet3d for the game he is working on currently, Subversive Takedown. Have you integrated physics into Cubiquity?

The ambient occlusion looks very nice, but as you are baking it into the vertices I assume this is limiting your ability to perform mesh simplification of the generated meshes. You have probably turned this feature off? If so I think it can have a significant effect on your framerate due to extra work in both physics and rendering.

You need to identify the bottle neck in you code really. Is it the rendering or physics code which slows things down? If you want per-vertex lighting and so can't simplify the rendered mesh, maybe you can still simplify the physics mesh?

Also consider how many batches you are using to render the world. What size regions are you using?

The other engines you linked use raycasting rather than surface extraction. This has pros and cons but in particular note that no physics mesh is available.



Do some research into continuous vs discrete collision detection. The problem is that with a low frame rate the can pass through a wall between frames. An engine like Bullet will indeed make this much easier to handle.



I've been doing that in the last couple of wweks. The map is currently very small though (128x128x32). See the video here: http://www.youtube.com/watch?v=d5RjcXvDMeY

First post has been updated with some details about my game.

I've also been re-evaluating my use of Irrlicht for Blockspell. I've been looking at Unity in particular. The integrated physics and animation system is a huge win moving forward. Also the lighting system is much more mature in Unity, which is pretty important since I plan on having lots of glowy things.

Moving to Unity also means the possibility of using Cubiquity! Any updates on that? I've never used Unity before and I would like to know what your opinion is of it.

Still looking very nice!

Unity is a really cool system. A little depressing in some ways, because it actually makes you regret all the time you spent doing things the hard way! It also feels a bit like cheating but ultimately you're much more productive.

Cubiquity is progressing well - I recently updated this post with some details of our plans: http://forum.unity3d.com/threads/180334 ... ost1232740

However, we're currently expecting to limit the free version to volumes of 256^3, which won't be enough for .vxl maps so you'd need a license (which aren't actually available yet). As mentioned in that post we're planning to move Cubiquity into a public repository and I think that should happen over the next couple of weeks so you can at least check it out then.

But basically it will work - I assume you saw our tank demo?

I read your post on the Unity forums and saw the screenshots with the shadows. They look really good! The shadows in Irrlicht are pretty bad irrc - they still use stencil shadows.

Based on your shadow post on the Unity forums it looks like you don't have Unity pro. DLLs work in the free version of Unity? I will probably also have to run some external C code since I want to use ENet for networking.

If you have pro, I'm curious as to what the SSAO looks like in Unity. It looks like it's as simple as checking a box

Yes, and there seems to be a lot of mis-information surrounding this. As far as I can tell, there is a difference between a native-code .dll and a 'plugin'. Unity Pro is required for plugins but native code .dlls can be called from Unity Free. I think it's only a plugin if it uses the Low-Level Native Plugin Interface.