Key Bindings

The first preferencesI added was key bindings customization. Everyone likes to do their work faster, and shortcuts help to achieve that by not having to reach time and time again for the tools you need from some cluttered menus. This is also something everyone is vocal about, everyone has their own preferences on what keys each actions should be bound to. With this system, everyone can change the bindings to their own liking, and there is also support for key profiles. This can be used to ease transition for people that are used to key bindings from other tools, like Unity, Maya or Max.

Plugins

Another thing that I added was support for managing plugins. If you don’t know me, I think plugins are a pretty big deal in software, they not only make your software more extensible, but they also allow for easier management of the code base and complexity. In my editor architecture, all core functionality is implemented via plugins. Of course a couple plugins depend on each other, but that is fine, as long as they communicate via well-defined interfaces. This is pretty similiar to the component-based approach way of thinking, that is getting pretty popular for scene management.

Right now it allows you to enable and disable plugins, install and uninstall them, as well as checking for updates. I am still not completely happy with the GUI layout, but for now it does its job.

I’ve also started adding more preferences, but they’re still a work in progress and will be shown later.

Resource Browser

Previously to this feature, if you wanted to add a model in the scene, you had to add a new entity, add a new Model component, and choose the mesh resource file. This still works, but is quite slow and has no preview. So I worked on a resource browser that will render all the meshes it finds the resource locations to a thumbnail. Then you can add it to the scene with a simple drag and drop to where you want it placed. The thumbnails are cached and an hash of the original file is also saved, so they can be regenerated only if the mesh changes.

Particles

A particle system was introduced in the engine. They are used to simulate effects like fire, rain, snow, smoke and also used in games to model combat effects. Our system is quite basic at the moment, using OpenGL point sprites to render the particles. It’s all on the CPU for now, though a GPU shader-based version might be added in the future. Further developments will be done to make this system more flexible, to allow more types of effects.

Lua Scripting

The editor is based on a scripting workflow paradigm, very much like the popular Unity3D engine. You work on your visual of the game in the editor, while adding behaviour with Lua scripts. So it’s no surprise that Lua has been already integrated with the engine. Scripts work like regular resources, so they get things like automatic reloads in case you change the code while working.

I started the binding process with Luabind, which is a template-heavy library that helps to bind C++ to Lua. It worked fine, but I didn’t like the increase in compile times and code size. Also the bindings had to be mantained manually in the source code. So I switched to SWIG, a tool that you run on your code, and automatically generates bindings. I’m still not satisfied with some of the way it binds some constructs but in general it’s stable and is working fine.

Here’s an example of a simple script:

function onUpdate()

    local pos = transform:getPosition()

    pos.y = pos.y + 0.1

    transform:setPosition(pos)

end

Fixed Pipeline

Since the start of vapor3D, I had the goal of using only shaders. Well, in the real world this doesn’t cut it. Some friends of mine with an old graphics card wanted to try the editor, but since I was relying on OpenGL 2.0 only features, and their graphics card only had OpenGL 1.5, they couldn’t run it. So I added support for a fixed pipeline path. It was actually easier than I thought, but since the engine and renderer itself are nicely modularized, it was made in a couple of hours.

Of course in this path some features might not work, and you might have degraded graphics quality, but it’s better to run with slightly worse graphics than not run at all. I think this will be important for vapor3D, especially since I want to do casual games later with it. The last statistics I looked at regarding this, showed that Intel graphics card are still very popular, and some models don’t have shader support.

Mobile platforms like the iPhone and Android also have a lot of devices that only support OpenGL ES 1.0/1.1 (no shaders) so this will be pretty good to later port the engine to those devices.

Build System and Dependencies

In the past, we have been using Visual C++ 2008, which needed to be upgraded to the Service Pack 1. We also needed Boost because we were using some new C++ stuff that wasn’t available.

Now the default IDE and compiler is based on the Visual C++ 2010 platform. All the dependencies were recompiled with this new compiler. Boost was removed, and due to that, some of the code that depended on it (threads, events) had to be replaced. The code is now simpler and with reduced size, since Boost is a little heavy on templates.

I also took quite some time to make the engine more modular, reducing the headers that have to be included in many files. This should result in a faster build in all platforms. Some measures to combat symbol bloat were also implemented.

www.youtube.com/watch?v=KUzN8DGfKHo

Right now only Milkshape3D animated meshes are supported, but it’s abstracted in the engine, so there’s nothing preventing, say, an FBX mesh importer to be made in the future.

Even though I’m satisfied at the moment with the animation system, it’s still quite basic. It’s missing nice features like animation blending and attachment points, but they shall be added once needed.

Hope you enjoyed. Thanks to Relfos for having lots of patience and helping me fix some issues.

I got curious and found some tools that can plot some nice graphs for us. I tried StatSVN which was very simple to set up. Just get the log file from the repository and feed it to the plot tool. Let it run, and it will calculate lots of useful information from all the metadata stored in the Subversion log.

Here are some interesting graphs that it generated:

This graph plots lines of code vs. time. I think it shows a very healty activity around the project. A slow start, where I mostly thought about design and researched new techniques, followed by some good ol’ coding.

This one plots file count vs. time. I actually had no idea that there were some many files but I’m not surprised. I create new files for every new separate concept introduced in the engine, so it makes sense there are so many files.

Now let’s hope that in some months from now, I can generate the plots again and reach the same conclutions.

I started by implementing plugin support on the editor. I came up with a quite simple plugin API and event system which I used to reimplement all of the core tools. It took a few days to do it properly, but it was well worth it. Now each tool is completely decoupled from each other and they communicate via events. This allows plugins to be enabled and disabled at runtime via a simple plugin manager (with few mouse clicks).

After the editor was stable again  and all tools were ported to plugins, I wanted to improve them. I only had transformation tools (gizmos) for positioning, so I added support for scaling and rotation.

White I was at it, I fixed a long-standing feature that I couldn’t get working before: object picking. This allows you to select the objects with the mouse. Most people use the gluUnproject function call provided by the GLU (OpenGL Utility library) but it’s been deprecated, so I had to implement it myself the hard way. It’s working now and it’s very accurate.

As you can see on the previous editor screenshot, I’m also adding a brush system to the terrain editing tools. To make this really neat, I will need to project the brush in the terrain, a technique known as projective texturing. I could hack it fast and make it work just for the terrain, but I like to do things properly, so I added a Projector component that will be more flexible and allows decals and simple shadows.

The projector is still not working, because I needed to add frustum support in the engine first. I had to research how to extract the frustum planes from the projection matrix, which turns out to be very simple. Thanks to Gil Gribb and Klaus Hartmann for their paper: Fast Extraction of Viewing Frustum Planes from the World-View-Projection Matrix. This frustum support will be extended to perform hierarchical frustum culling which should provide a nice speed up for complex scenes.

To finish, today I’ve fixed a small problem in the mesh loader that wasn’t providing the correct vertex normals and played a bit with the shading. I’m using a simple Half-Lambert model with constant ambient factor. This can be improved later by sampling the ambient factor from a cubemap. This is known as image-based ambient lighting and will make things look better.

]]> http://www.vapor3d.org/editor-plugins-picking-frustums-and-shading/feed 0 http://www.vapor3d.org/editor-plugins-picking-frustums-and-shading http://feedproxy.google.com/~r/vapor3d/~3/SVOttSwBq3w/procedural-clouds http://www.vapor3d.org/procedural-clouds#comments Fri, 16 Jul 2010 22:16:50 +0000 triton http://www.vapor3d.org/?p=214 Hey there. I’ve finally finished my exams and started working more on the engine. These last days I’ve been working on adding some clouds to the sky. I wanted the clouds to be animated and also to allow for more or less coverage of the sky. To get these features I thought about using procedurally generated content. They allow you to change the mood of a game by just tweaking some parameters. The basic building block of procedural content is noise. Not true random noise, but what is known as coherent noise.

Coherent noise

This type of noise is generated by interpolating between random values. The most known type of coherent noise is Perlin noise. It was created by Ken Perlin in 1985 and is used in all sorts of things in the special effects movie industry. By manipulating this noise we can generate clouds, water, fire, grass, planets, well, pretty much everything.

So the first step was creating a Noise class in the engine. After this was done I added support for animated clouds in the sky system component. I didn’t tweak it yet, but I’m already quite pleased with the results.

www.youtube.com/watch?v=j1aAAuK80do

There are still some seams in the sky, probably due to badly generated sphere texture coordinates. If someone knows how to do spherical mapping properly, I’d love if you could give me some tips on how to get it perfect. In the future I’ll work on some animated water, but it’s going to be a lot of work to do it properly, since I want to base it on splines, instead of the usual “water planes”. That will be more flexible and allow curved rivers and also waterfalls. Take care.

Although you can’t see from a static screenshot, bagic paging support has been added. So as you walk in the world, each new page of terrain will be loaded on-demand, giving endless possibilities on building awesome and big worlds. I’ll try to make a video showing this later. I’ve been working on lots of other stuff on the engine, and seand is also working on an awesome GUI system, so expect more news soon.

www.youtube.com/watch?v=QlMXjeycVXM

The editor now allows for some simple terrain editing like raising and lowering. Other tools like smoothing and painting are in the works. And also support for arbitrary brushes (like Photoshop brushes) which should give artists more creative freedom to use shapes to edit and paint the terrain. Undo and redo support has also been added so you can go wild and go back to a safe version of your work.

About the undo/redo system, it saves the state of the terrain (only the heights are needed!) before and after your editing operation, so it can do undo and redo. First I tried to only save the operation used (Raising, Lowering) and then algorithmically apply the inverse operation, but not much time later I thought saving the state would be better. Operations like terrain smoothing don’t have an inverse operation, so I had to support state saving anyway.

At the end of February, I started fleshing out FBO support. Framebuffer objects (FBOs), are render targets that you ask the engine to render content into. There are 2 types of framebuffer render targets you can attach:

• textures – also known as render-to-texture or RTT,
• render buffers, commonly called offscreen rendering.

FBOs are mainly used to implement screen effects. We will also use them to implement shadow mapping later on.

Then I worked a lot on refactoring the editor code. It didn’t have a clear architecture. When I first started the editor, I didn’t have a clear goal of how I wanted it to work, so I just keep adding code to it, refactoring aggressively as I went. While it was not that messy, clearly when I started adding more functionality I saw a different approach regarding the architecture was needed.

Now the architecture is based on “plugins” (which at the moment aren’t loaded at runtime, but it’s a possibility). There is an interface that provides functionality to what I call “editor modes”, and they can react to events, which are implemented with C++ delegates.

After this work was done, I had to move all the existing editor functionality into this style. While at it, I also fixed a few bugs regarding active modes. Now every editor mode only reacts when it is selected in the toolbar. I also started thinking about undo/redo support and added some code and data structures, but I have yet to finish this work.

Now that this refactoring was done, I wanted to add some new functionality. So I worked on essential manipulation of 3D objects. This is what’s normally called a “gizmo” or “manipulator”.

You might notice those strange red lines in the above screenshot. They were added to aid in debugging picking code, which had a few mistakes. I fixed it and it now seems to work great.

Recently, I’ve been working on adding terrain editing support to the editor. Simple raising of the terrain is already working quite well. To implement I needed to add Bounding Sphere support in the engine, which I use to test if the vertices of the terrain are within the range of the intersection point given by ray picking the terrain location you clicked. It seems to work great, but I still want to work on it. There a couple other terrain editing modes I want to add, like lowering, smoothing, leveling, painting, etc.

Yesterday I also researched about Mono and Lua binding generators. I’m still unsure whether Mono or Lua are better choices for vapor, so let me know if you have any opinion about this. I also came across FireBreath, which is a cross-platform browser plugin framework, so it’s quite possible some day vapor will run on web browsers.

Hope you like it. We’re still looking for a developer to help us develop the engine. Let us know if you’re interested!

As you probably know, vapor is a scene based engine with a component interface. This makes it very easy to serialize each component independently. It should even be possible to share components for some memory savings, though we’ll leave that for later, when that optimization is really needed – premature optimization often leads to trouble.

There are two main ways to format your data when you serialize it, you can either do it in binary or in plain text form. Binary takes up less space and is usually faster to load, while text formats are easier to modify (you can even use plain Notepad) but end up taking more space, though with some simple compression that can be worked around.

Most people choose XML for this task, which is a standard, structured plain text format. There are lots of XML libraries for C++ which make your task considerably easier (implementing a good and fast XML parser isn’t trivial). The main drawbacks with XML is that it is very verbose, thus takes a lot of disk space needlessly. We ended up using JSON instead, a simple and readable file format, which also has gained a lot of support mostly in the web development community, since JavaScript can read it natively.

I found a nice library called json-cpp and in a couple minutes had a simple example working. I liked it’s simple approach and integrated it into vapor. The serialization work will take some more days to finish since there a couple components that need to be integrated. Also for this process to have any use, we also need to implement deserialization, which is, you guessed it, reading the written JSON file and assembling it back into a scene.

Let’s see an example of a very simple scene serialized:

This support will be integrated into the editor and then we’ll be able to finally save and load scenes graphically. One more baby step towards world domination!