Sign in to follow this  
  • entries
    235
  • comments
    509
  • views
    172042

Camera fun

Sign in to follow this  
SimmerD

69 views



I have always hated my camera controls in the editor. Not sure why I didn't fix them before, but tonight I added a drag-button toolbar to allow you to move the camera around in a sane way. The old method left the cursor in the screen while moving the camera, which caused issues when it got outside of the viewport or the app rect, etc. It also did left/right rotations relative to the camera's local Y axis, which tended to make the camera roll when you were trying just to rotate left/right. Insanity.

Now, the cursor disappears, you can drag around for a while as needed, and when you let go, the cursor is right back where you left it.

I have pan, dolly, roll, two rotation options, and nice FPS-style WASD controls as well. The horizontal rotation is world-Y-axis relative, which is what you want. It does nothing if the camera is facing +-Y.

I also added more vertex options, fixed up the texture mapping, and fixed a few bugs here and there. It's pretty usable at this point.

I have been having some ideas about how to add a good automatic hole-triangulator function, but I'm not sure it's really needed at this point, although it would solve some issues, and be a nice ramp construction tool as well.

The idea is two-fold :

1) Select a bunch of vertices around a hole, or perhaps 4 verts defining a ramp.

2) hit the 'stitch' button, and the editor would create a poly, then tessellate it nicely for you, that filled up the space between the selected vertices.

The simplest way to go is just to assume the verts are convex & planar, and then create a bunch of tris from each edge of the selection to the center. This is good for patching up simple holes, but is not much better than just collapsing the hole verts to their average.

The fancier method involes creating the plane of the selected verts to start.

Then for each selected vert, find its neighbor, by trying a vert, building a plane along the edge perpendicular to the selection plane, then making sure all other verts are on the inside of this plane. If not, try the next vert. Eventually, you'll find the neighbor, and you can then put it in an ordered list of verts that defines a polygon. You can create a triangle vertA, vertB, center, to decide if the edge goes a->b or b->a by comparing this tri's normal to the original selection plane's normal.

Next, you clip the polygon into smaller polys by the 1x1x1 meter cubic grid. This is just to make editing easier later, and to keep polys from becoming long & skinny.

Lastly, turn all of the clipped polys into triangles, and add them to the geometry database.
Sign in to follow this  


3 Comments


Recommended Comments

The editor is looking pretty good - after only about two weeks of work you pretty much have the whole thing redone. That's pretty impressive.

You have mentioned before that your levels are just a triangle 'soup'. What exactly does that mean? I understand the idea that the triangles are all considered one entity, most likely with some material properties to select textures and so on.

I suppose you could pack the entire vertex list into a single VB, but what data structure do you use to select the correct triangles to render? Some form of an octree? Does this mean that you perform a per-triangle traversal of a tree triangle structure each frame for visible tris and for each light for affected tris? I don't think this is the case since your framerates are quite good for the LOD that you are using.

Share this comment


Link to comment
Good question.

By triangle soup I mean that there is no meta-structure for the data that could be used to derive the triangles, like a bsp, voxel grid, or saurbraten deformed cube idea. At the end of the day there's just a vector of tris. This makes it harder to edit, in that there isn't much structure there to assist, so I end up starting levels with a fixed grid and modifying that.

At the lowest level, I have a axis-aligned bounding box triangle tree.

I also have a notion of grabbing groups of tris in a subtree as one rendering chunk. This is needed for rendering speed, frustum culling and light management.

When the tri-tree changes, I invalidate any chunks touching the bounding box of the changes.

Then I go through the tri tree, find any invalid chunks, add up the # of polys under the invalid portion of the tree, and turn it into one or more valid chunks ( which are just a per-material index list range and a vertex vector ), or if the # of invalid tris is too small, I just merge them up with the parent.

So, to summarize, it's an AABB tree to the triangle level, with some extra info in each node as to which render chunk its part of. The renderchunks know which node they reference, and the rendererable tris.

Objects in the scene are rendered separately in the traditional manner.

Share this comment


Link to comment
Very interesting. I'll have to think about this method and see if I can come up with any pros or cons of using it. It's cool to hear about people using non-traditional methods instead of the same old same old.

Keep up the good work!

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now