next »

[quantaloid]

Hey everyone! Development is starting to pick up, so I thought I'd start a devlog for my project: a portal rendering engine designed specifically for non-euclidean/impossible spaces. This video I found uses the Source engine to demonstrate some of the things that can be done:

.

Currently I'm working on the level editor, which is semi-procedural - I'm generating architectural features like arches in code to cut down on the amount of fiddling with brushes that you normally have to do in an editor like this.




I'm excited about getting the portal functionality in, which should be within the next couple of weeks. I have a bunch of ideas for level topologies that I'm itching to try out.

[quantaloid]

Devlog #1 - Camera Basics

One of the first things a 3D level editor needs is a mouse controlled camera. There seems to be two main ways to do this: the first is basically a first person shooter camera controlled by the mouse, and the second is what I call a "look at" camera. The main difference between them is that when you rotate the view, the first person camera rotates in place while the look at camera rotates around its target, which is some distance away along the camera's direction vector. As examples, Autodesk Maya uses a look at camera, and UDK uses a first person camera. Trenchbroom, a Quake editor, rotates the camera in place by default, but lets you rotate around the target if you hold a modifier key.

It seems that there are at least two ways to handle the target distance of the look at camera. In Maya, the target distance is a property of the camera and changes to be closer or farther away as you zoom in and out. In Trenchbroom, the target distance is instead determined by the distance from the camera to any brush surface that is under the mouse cursor when you press the mouse button down.

For my editor I decided to go with a UDK-style first person camera, mainly because it feels more natural for level editing. The look at camera can get awkward to control when you need to navigate a space with it. It seems to be better suited to 3D modeling software where you typically have an object that you want to focus on.

What I like about the camera in UDK is that holding the left mouse button down lets you both zoom (move back and forth) and rotate horizontally at the same time, which is pretty convenient, so I implemented that as well. However it makes the left mouse button less useful for other tasks, so I might have to change it at some point or require that you hold a modifier key while using the camera.

There is one other subtlety I discovered about editor cameras, which is that panning vertically can either be relative to the camera direction, or move the camera up and down along the Y axis. I decided to have it move up and down, since it's more consistent with the first person shooter camera paradigm. I'm also going to put in WASD controls for convenience.

Here are the mouse controls I went with:

left mouse button: zoom (move forward/backwards) and rotate left and right
right mouse button: rotate the camera
middle mouse button: pan the camera (move up and down along the Y axis, strafe left and right)
left and right mouse buttons together: same as middle mouse button

I'm a little sleep deprived while writing this up, so I hope that all makes sense! I realize that some animations would make it easier to understand, but I'm not set up for generating animated gifs yet. I'll have to look into that soon.

[quantaloid]

Devlog #2: Object Organization

Here is an explanation of how I'm organizing things in the editor. The main objects I have so far are sectors, blocks and portals.

Sectors are basically box shaped rooms that contain the level geometry and can have portals along their walls. Sectors are box shaped for two reasons: first, they must be convex for the portal rendering to work efficiently and second, portals can only be placed on the axial planes. Therefore sectors must be a convex volumes with axis-aligned faces, or in other words, a box. Earlier in development I was hoping that I would be able to place portals anywhere in a level, kind of like the portal gun in Portal, because not having to manage sectors would have simplified the level design process. Unfortunately my rendering technique seems to require partitioning the level this way.

Blocks are procedural chunks of level geometry. They contain a list of Quake-style convex brushes that are used for both rendering and collisions. There are a number of block types, such as boxes, ramps, arches and stairs. Blocks are treated as simple boxes by the editor interface, which makes them easier to work with than manipulating brushes directly. The procedural generation means that resizing a block doesn't just make it scale up or down. For example if a stair block is resized to be bigger, the step height stays the same but more steps are generated. Blocks also impose what I hope are interesting constraints with which to design levels since level designers must make the best of a small set of reusable pieces of geometry.

Portals are at the heart of the engine. They come in pairs and can connect any two sectors together, or one sector to itself. I decided to constrain them to axis-aligned rectangles because it keeps things from getting too complicated (gameplay, physics and rendering-wise). I'll talk more about things you can do with portals and how portal rendering works in future posts. For now I'll just say that it goes a lot farther than the portals in Portal.

I don't have all of these objects fully implemented yet, so they might change once they're in, but that's the general overview for now.

[gaarlicbread]

I love the idea of non-euclidean games. It was a delight to see some of the geometry hacking done in Antichamber, for example. I would be interested to see some gifs of what your editor can do, or maybe hear about specific ideas you have in mind beyond Portal portals.

[quantaloid]

Hi gaarlicbread, I don't want to reveal too much at this point. For now I'm focusing on documenting my progress with the editor, which necessarily involves a lot of minutiae. I will be posting about portals at length when I'm ready, so I hope you'll stick around.

[quantaloid]

Devlog #3: Manipulation Tools

There are 3 kinds of manipulation that every 3D editor needs to be able to do: translate, rotate and scale. Typically there is a manipulator that appears when you select an object that lets you interact with it by clicking and dragging with the mouse. The manipulator has 3 components to it, one for each axis, so that you can specify which axis to act on.

I'm doing things a bit differently: when you select a block, 6 points appear on it, one in the centre of every face. You use these points to manipulate the blocks. The normal of the face that the point is on determines the axis used for the action.

Translation is straightforward, you grab a face point to move the block back and forth along that point's axis.

Scaling is done by clicking and dragging a face point to move that face along its axis. It's better thought of as resizing, since you are changing the dimensions of the block directly. You can resize faces on multiple blocks simultaneously if the blocks are selected and have a face that is coplanar with the face you are modifying.

For rotation, I decided there should be two types, a regular rotation that rotates the entire block, and what I call "rotate inside" which rotates the shape inside the block but keeps the dimensions of the block the same. Since rotation is constrained to 90° angles, I made it so you just have to click on a face point to rotate the block around that point's axis by 90°. Rotate inside is useful for situations where you have created a block in the correct dimensions but need the shape to be oriented differently within its bounds.

These 3 tools allow for the full range of transformations that can be applied to blocks in the process of making a level. They are already functional and the workflow seems like it will be suited to the task even though it's different from the standard tools used in most 3D editors. I'm in the process of cleaning them up and adding some visual hints, such as highlighting the current face point that the mouse cursor is hovering over.