Annwvyn C++ Open Source designed-for-VR game engine and application developement framework
This release is mostly about making the code nicer to work with, the library nicer to use, the documentation nicer to navigate and is fixing low level problems, making the engine more flexible. Everything works on Visual Studio 2017, and on the latest version of GCC and Clang on Linux. There's untested OpenVR (HTC-Vive) support on the Linux side. I'm going to get around to try it out in the near future, so... Expect updates on that, I guess.
The developement of the engine will focus on a few things
exit() based error handlingThis is a "mid cycle" release that should steer the development toward what should be Annwvyn 0.4
This release include : New rendering through Ogre and PBR, new build system. New testing system, repackaged resources and dependencies.
There are some graphics problems that need to be addressed. .There's also functionality of the touch controllers that aren't actually used (hand "finger pose" tracking")
I'm going to do a little roadmap and to update the Annwvyn.org blog with that information, instead of here.
This release is mostly tweaks, fixes and adjustment.
Eh, that's a big one!
After starting to implement motion (hand) controllers, I needed to actually get my Oculus Touch controllers to have them actually implemented in the engine, and it's done (except for the state of the capacities finger things, and buffered haptics). And you can rumble the controllers (vive too, but the effect is different)
To continue on the extension of the API, user-defined subsystems can send custom events, string can be hashed to not waste time in tests, and a lot of duplicated code has been removed.
The VR Renders are simpler. Everything that was common and that could put in the parent class in in the parent class.
The template is more streamlined and commented with documentation. The wiki at https://wiki.annwvyn.org/ is still seriously lacking and need some love.
What seriously needs work also is tools. The Engine can swallow level loading description in XML, but there's no good way to create these files. I have a prototype of a Qt based editor privately but it's buggy has hell and it's not usable. I actually tried to make a level editor 3 times but it really need more time and more architectural planning. That's not on the road-map right now.
I have a school project to finish, it's running with Annwvyn and I need to integrate some networking, it will be done by the UserSpaceSubystem interface (hence why it's been finished here :wink:)
So, this new 0.3 "phase" of development will be dedicated to getting the performance consistent, correcting eventual bugs, maintaining compatibility with both OpenVR from Valve and OVR from Oculus and getting the documentation together.
A "big" milestone in the future will be to do the transition from Ogre 1.9 to 2.1 that is making prettier render easily, is faster, has a better material system and a more modern architecture.
The ChaiScript interface is probably still lacking a lot of useful features. They will be added progressively. The spatial triggers still need to be redone via Bullet, I'll got to make it work at some point, but the problem is this is some work that may finish to be undone by the transition to 2.1, so we'll see.
Some aspect of having actual games running aren't streamlined yet. For example it's impossible to have an actual loading screen. The engine just stops submitting frames.
This is becoming less of an issue while looking at how the last SteamVR beta of the compositor display an actual "loading" spinning wheel in a Steam window in your SteamVR space. Oculus just keeps the last good frame and tiemwarp it, with a hourglass logo in the corner of your eye.
So, here a changelog, in the chronological order of the commits, because I'm too lazy to regrom theses points by theme and I have stuff to build and upload! ;-)
I was looking for some time into integrating a scripting language to the engine. This makes content development easier and quicker because you don't need to re compile everything after each changes.
I've thought about Lua, and even though about putting python on the engine, and then I discover a really interesting project called ChaiScript.
ChaiScript is a scripting language for C++. It's made to be easy to bind with C++, and it is.
So, this release add the possibility to attach "behavior" scripts to AnnGameObjects (in a similar way Unity deal's with this).
The Scripting API itself is documented here : http://api.annwvyn.org/namespace_annwvyn_1_1_chai_script_a_p_i_doc.html it's functional but not actually finished. The inner working, syntax and naming conventions could change (but I don't expect to do it)
Each behavior script is defined in a file with it's name and the ".chai" extension. They are written in ChaiScrip, a language that will appear fairly simple for any C++ developer (the syntax is more JavaScript-like than anything else).
Scripts define a class bearing the name of the script file, implementing a constructor taking the name of the "parent" AnnGameObject that own the script. An "update" method with no arguments is called at each frame of the game.
They can optionally implement any of the "Event" method of the AnnEventListener class as method. They will be called accordingly with the correct event type as parameter. These are usable as described in their representation in the API documentation.
class MyBehviorScript
{
attr Owner;
def MyBehavirScript(owner)
{
this.Owner = owner;
}
def update()
{
//This is called at each simulation frame
}
def KeyEvent(event)
{
//This is called at each keyboard event
}
}
Now AnnGameObject are globally identifiable by a name, and can be retrieved from the AnnGameObjectManager, or via a function in scripts. Level owned "ID" for object has been replaced by this for the AnnGameObjects, but API-wise it's the same thing.
Some cleaning has been made on the template project, and some code cleaning has been made too in general thanks to ReSharper's static analyzer, and making it more C++14. In the effort of improving the quality of the code, some processing of object collection that was done by hand has been replaced with std algorithms. This makes the code cleaner and the standard implementation of theses algorithms is probably better than anything I could come up with myself.
There's still some work in that regard, but this is not a priority.
Collision now push event through the event manager. Overriding the CollisionEvent and PlayerCollisionEvent methods of a listener permit you to get them.
In the previous release statement I was talking about either running the logic or the resource management in a separated thread as the rendering. This proves a bit more difficult to do because of Ogre's non thread-safeness in this regard. I've done some experimentation and concluded that I shouldn't bother with this before porting the graphics code to Ogre 2.1
Pretty much everything has been said in the title, this is a minor patch. It seems than when I finally want to tag a state of the engine I don a bunch of cool stuff that could have been in the release... Anyway
Now the engine is actually using MSAA.
You just need to call
OgreVRRender::setAntiAliasingLevel(4);
with a valid AA level (any number in { 0, 2, 4, 8, 16 })
There's a very basic integration of hand-controllers within the event system. The OgreVRRender object is the one piece of the engine that is depended of the VR system you are using. The special VR controllers (or at least the way to talk to them) are also API/Specific and is "abstracted away" at the same place.
This is only active on the OpenVR renderer (the "-vive" mode of the engine.) Since it's the only one with public access to the actual controller. They can be actually online and tracked after the starting of your application sometimes, if they have been put in "sleep mode". They will only appear being actually moved by the user.
Put simply, the AnnEventListener class now has a virtual method called HandControllersEvent that will be called with an AnnHandControllersEvent passed by value. It only contains a pointer to the AnnHandController object that is owned by the VR Renderer.
It's a naked pointer and it's only sure it points to something valid at the time you got it so you're not supposed to store it.
I think I'll directly expose the state of the controller via the event object, but for now it's good enough. You can call any public stuff from this class without breaking anything : http://api.annwvyn.org/class_annwvyn_1_1_ann_hand_controller.html
It's also checked to run with OVR 1.9
0.2.6 should have the "don't render while loading content" problem fixed. And probably some multi-threading going on for that, and done with the new C++ standard concurrency library. Some C++11 and C++14 fun stuff!
Now, I have to go re-build and re-upload some stuff.
Annwvyn got a a few new features, a lot of bug fixes and some structural improvement since the last release.
I'm progressing to the goal of having a lightweight, easy to use VR engine that is VR system independent.
This release add 3 main things, and they have some side effect :
This also added a way to make a level able0 to automatically unload non-managed movable objects you add to the environment if you use RAII by writing a proper destructor. You have to subclass the AnnAbstractMovable class for that.
Also a nasty bug was due to a really stupid mistake. I will not be bitten twice, so I'm now compiling with the maximum warning level, and using static analysis to make theses things less likely to happen.
I'm also changing my way of doing some things from "a C99 guy that learned C++03" to modern C++. I already adopted newer features like range-for loops, auto, and nullptr. More recently I'm using smart pointers instead of naked_type* pointers and newer STL containers.
Feature wise, I need a way to cleanly push hand controller events from the VR integration to the event manager, in a way that I will easily implement Oculus Touch support to it in December when I will got them. For now I just have a pair of Hydra (borrowed to a teacher at my school) and I use them through SteamVR as Vive controllers.
The other thing I absolutely have to work on is to not be that mono threaded. Currently, Annwvyn run the logic, then the physics, then the graphics. There's some work to make this better 😉
The last, and least fun issue that bother me is that I have currently no way to turn on any anti-aliasing on the intermediate render buffer. For some reason, adding FSAA to a Render Texture makes Ogre render a black image. So for now, we're still stuck with jagged edges 😢
After changing the API to use an abstract "OgreVRRender" object as the renderer, The path for compatibility with other VR system was open.
This rerelease comes with 2 major improvement :
AnnEngine will use the correct renderer object if "-rift" or "-vive" is provided as a command line argument. This is completely transparent for the library user.
And now, a change sumary:
"0.3" will be the support for "hand controllers" and a proper way to specify "untilisation context" (seated, standing, room scale, virtual cocktpit".
Also, there's some problems in the physics implementation. Sometimes the time doesn't update in the physics. This is a known problem for a while, but I'm unable to track it down.
There's multiple things I'm not happy with the way the physics is handled, I don't know if BtOgre is to blame. I will probably ditch it completely and write my own physics object initialization code.
Hello there,
I'm mostly working on the XML level system, on another project that's not public yet, so the main Annwvyn repo did not see much activity.
Nonetheless, the Input system was not exposing the joysticks POV controllers, I corrected it, and intended to do other things before adding a new tag here, but since it's taking too much time, we'll go for 0.2.3 now.
Changelog:
That's it. There isn't much to see. Next one will probably be about the animation system, or the physics.
Yes, it's time for 0.2.2!
Things are going the same way as the previous one. Lots of API change, the engine init has been redone, more segmentation of functionality into subsystems, improved compatibility with the Consumer Version of the Oculus Rift I FINALY GOT MINE!!!!!!, and a bunch of stuff as listed below, in commit order.
The two main things for this release are the fact that an abstraction layer as been added between the "OgreOculusRender" object and AnnEngine. Now AnnEngine wants an "OgreVRRender" object. This class is abstract, it's only child for now is the older OgreOculusRender. The API of OgreVRRender is generic and doesn't reference anything from the Oculus Rift. Same goes for the rest of the engine.
Direct access to the renderer can be made with AnnGetRenderer(); This gives you a pointer to the renderer as a generic VRRenderer. You shouldn't need to call anything from a specific renderer so that's all good.
A scenery manager handles skyboxes/domes. The VRRenderer handles the (few) camera config' you are allowed to touch (near/far clip planes)
The whole developement environement has been moved to Visual Studio 2015. I will rebuild from scratch the binary installers of the SDK and complettely eratdicate VS2012 (exept the legacy branch from a school project)
The good stuff (changelog):
Engines feature did not evolve. I think I'm mostly done with this refactoring frenzy... So, let me check the todolist... mh... AnnGameObjectManager is a factory for GameObject, LightObject and TriggerObject, so that thing is done. ObjectParenting is not important for now, and it's a matter of playing with Ogre SceneNodes (the tree allready exist, it's Ogre's SceneManager. :wink: ) So, the next things on the list are to fix the way the animation system works (= create an animation system that works, or see if Ogre's animation state system is less stupid than I thought) and some work on the physics engine, that is boring, and that I will do later...
When I'll found the time, I'm going to build the SDK installer for this version and put it on http://annwvyn.org/ Then I will concentrate into writing on the wiki here : http://wiki.annwvyn.org/