Finally! I have a functional camera system. I am not going to talk about the implementation because I would rather forget about it, so I am going to talk about each camera mode.
Top down camera
This camera mode is very similar to the top down 2D mode that was available in the 2D engine. That classical 2D mode will definitely be removed since the 3D one is a lot more powerful. In this mode the user controls the mouse cursor by moving the mouse, directional keys scroll the map and we have smooth zoom. I need to add a camera tilt option, so you can view the scene from a top down but angled view point.
The question is what to show with this mode. I decided that I will center the camera on the currently selected level and keep a constant distance every time you switch the level. Without this, the user would almost always follow a level change operation with a zoom operation, because the perspective causes different levels to have different sizes. So levels above you current level won’t be rendered by default. Rendering levels below the current level has some merit to it, especially if the current level has holes in it, so I’ll render a few levels bellow, but probably not all the way down to level zero.
There is one issue with the entire engine: my LOD algorithms work extremely well with first person cameras that are positioned at the eye level for dwarves. It does not work that well with other camera. If I write a special LOD algorithm that takes advantage of the special square shape of the map in this mode, I could obtain a framerate that is higher than in any other mode.
Angled camera
This mode is very similar to the 2D isometric engine, with the difference that this time we have perspective.
Zooming now works fast and without using tons of memory like it did with my failed attempt at providing this feature with a software based approach.
I’ll keep the camera focused don the current level, like I’ll do with the top down mode.
Here, my current LOD works against the specifics of this view mode. A more specialized LOD would increase performance and keep objects on the side of the screen from switching over to low LOD, but writing this specialized method will be harder than in the top down mode.
Fly camera
This third mode is the one I have been using in my previous videos demoing the 3D progress. You start from up in the sky looking down and you move like you do in first person shooter, but flying without gravity. This is an exploration mode and right now I have no plans for allowing you to interact with the world.
First person camera
And this is the final mode that will allow you to jump in the body of one of your dwarves and look around with his or her eyes. Time will stop and you won’t be able to interact with the world, but to make it more fun I’ll allow you to walk. This mode is not implemented yet and will be very similar to the Minecraft experience, except for not building anything because it is an exploration mode.
Here is a video demoing these camera modes:
Excellent progress!
ReplyDeleteQuestion: If time is stopped, what effect will walking around with a possessed dwarf have? will the dwarf suddenly pop back to it's previous position when time is restarted? or will moving the dwarf count as a "turn" in game?
Pretty nice.
ReplyDeleteWhat about the polygon count? Your current objects seem to be not that high poly and i wonder how much your engine can handle (even more interesting for custom mods and such things). Something like normal/bump maps could be an alternativ?
Still very good, compared to your first posts on the 3d-engine.
I believe in you...
To BrewStew:
ReplyDeleteNo, the dwarf will pop back to his original position. Because he never left. This is an exploration mode. Consider that the dwarf took a walk in his free time while time compression was on :).
This is for the standard game mode. Other game modes may be added later. For example, I could turn this into a single dwarf non block based "Minecraft" in a few weeks if I wanted. Same actions, same time compression, only single dwarf first person.
To Phil:
It is very hard to determine the poly count. I have a LOD mechanism for grass and separate one for trees. And the entire scene is rarely rendered in its entirety.
But the engine routinely renders 80000 to 240000 triangles. Turning off all LOD will probably increase that number ten times or so. I'll add a debug triangle count soon.
On my hardware the engine is strong enough to render all the trees in a scene with tree LOD turned on but without tree culling with a minor framerate drop. This means that every single tree is rendered, even the ones that are far away, but the far ones are rendered with a low poly model. Without using billboarding. Turning off all grass LOD has a more drastic effect, reducing the framerate to at least half.
found this, maybe it could help you...
ReplyDeletehttp://tower22.blogspot.com/2011/09/compressor-part-12.html
Quick progress!
ReplyDeleteI have some comments about the cursor, though I may be jumping the gun talking about UI design while you're focussed on 3D stuff. =D
The tile-highlight style cursor has two pretty undesirable properties:
- It ties the responsiveness of the mouse to the performance of the 3D engine.
- When transitioning to clicking UI buttons, the change in the resolution of mouse movement (pixel when clicking buttons, tile when over the map) is disorienting to the user.
You do need to use this approach when applying actions (dig, build, gather) but when simply mousing over the map and perhaps click-drag/edge scrolling, it will feel quite sluggish. Using a conventional cursor for this also gives a strong distinction between passive and active interaction with the map, which is good UI design. =)
Also the fly camera needs to have yaw instead of roll (with respect to the ground). From the default camera it seems like the 3D engine is expecting the Y and Z coordinates to be around the other way?
To Anonymous:
ReplyDeleteThanks for the link! I need to wait for part 2/2 I guess before I can tell if this is something I could use.
To David:
This is why the real mouse movement is constant. You can interact with the UI at the same speed on all hardware (except when you have really low fps) but your map cursor may be lagging a bit. In that video FRAPS was causing my map cursor to lag behind the mouse cursor. If your map cursor is lagging you can try and reduce the graphics quality, but I hope it will be just fine if you have more than 30-40 FPS.
And yes, the fly camera works very strangely. It is a stock Irrlicht first person camera. Maybe when I write my own I can better control it. This camera expects a differently orientated map relatively to it. My world is built in natural way, with the exception that higher points have a lower negative Z coordinate and the bottom level has a Z of zero.