The OMNI Engine v1 Released (C# in T3D)
by Vince Gee · 10/10/2014 (10:32 am) · 27 comments
Check out the website at www.omniengine.netHas it really been four years since I started down the path of building a C# interface for T3D? I do not think I can even recall how many different approaches I have taken over the years. Oh woe's is me, all those epic fails along the way. But, I have proved that if you stick with something that seems impossible, you will prevail.
Folks, I would like to present you with the new Omni Game Engine. Yes of course it is based off of T3D, build 3.5.1 to be exact. (Yes I plan to merge in 3.61 soon). I am sure you are wondering why I feel this is a major accomplishment, well let me explain.
The core of the Omni Game Engine is the Omni Framework. The Omni Framework is a C# model that simplifies game programming in T3D. There is no ugly p-Invoke syntaxs, convoluted work a-rounds, or half-baked solutions here. The Omni Framework is a complete end-to-end solution for programming in C# inside of T3D.
Included with the C# Omni Framework are also many improvements to the C++. We have been pouring over the many resources available on the GG site and cherry picked the most useful and used. We figured that if the first thing people do when they get T3D is implement these same resources, why not just put them into our head?
Now some things are different than T3D. For one, we completed our 32/64 bit build a bit ahead of the MIT group so ours functions a little different. In Omni all projects can be switched between 32/64 bit in the build configuration without having to generate a project or run any scripts.
We also fixed some long standing issues in T3D related to game hitches when a camera moves around for the first time in a mission. We also revisited the math inside of T3D to make it more precise and consistent.
We also converted most of the old style syntax for console functions over to the latest format for consistency. We removed Con::Exec and Con::Eval calls and replaced them with proper callbacks. Hopefully, in the very near future we will have our port to C++ 11 finished.
Additionally we also gave the game a visual revamp. Paul and I loved the DarkUI resource so much that we choose to use it for the UI in Omni. The new Dark UI compounded with the Advanced UI Kit really improved the visual experience inside of Omni. Until you are able to Pop windows off the canvas and drag them to another monitor, you really just cannot enjoy building levels.
Oh, did I mention that we implemented our own Datablock caching mechanism for dedicated servers? When a client connects to a dedicated server, the client is sent a hash, if the hash on their local cache file matches the server, the server will direct the client that it is skipping sending the datablocks and the client is to load from the cache. We even set it up so that each mission can have its own cache. So if your game connects against multiple dedicated servers and loads different missions, the clients will not need to re-download the datablocks as they zone between the game servers.
There are a ton of other features in the Omni Build and you can check them out here!
One other thing which is extremely important, our team has spent countless hours documenting the Omni Framework and how it works. The currently 125 page document covers everything from setting up your first project to how the internals of the Omni Framework works. I highly recommend that people read the manual before using the Omni Engine, since there are vital steps covered in the document.
The OMNI Programmers Manual can be found here.
Oh, one other thing of note, we have been building extensions for Visual Studio 2010 and 2013 to help you on your way as you program in OMNI. Expect these little helpers to be expanded on future releases. We have been focusing on the C# mainly so far, but we plan to start adding C++ helper extensions in the next release.
I know, I know, what about licensing. Well in a nutshell,
For the Community License of OMNI,
For the Omni Supporter License,
Well you do not have to do anything. All of the above restrictions are removed.
I still recommend you visit our site here to read the full licenses.
So, I know you are thinking how much does all of this cost, is it a bazillion dollars?
The Community License is free to everyone. You get full source code and all our tools for FREE. Yep you all heard it here, FREE.
If you want to help support the development of the OMNI engine, you can buy a Supporter license for 100 bucks which among other things will get you a discount in our store and consulting, besides removing the splash and stuff requirements.
All of the code is on GitHub
I would like to give a BIG thank you to everyone who participated in making this happen, there were so many people I could not possibly name them all. But for a short list:
Paul Yoskowitz
Luis Rodrigues
Dusan Jordic
Aswin Shrestha
Khalil Hajlaoui
Tim Watton
Lucas Joergensen
John Turner
Dan Polak
Chris McKillip
Josh Leeming
Jesse Allen
And my dog Cody (He did all the hard work)
Hope you all take some time to check it out,
Signing off,
Vince Gee
Winterleaf Entertainment L.L.C.
www.winterleafentertainment.com
www.omniengine.net
About the author
www.winterleafentertainment.com
#3
10/10/2014 (11:17 am)
Congrats on release! May you reap all that you have sown with your great efforts. 
#4
Paul and Vince really are devoted to help with any issues you may have. It felt a tad daunting for me at first testing out the new stuff. Just recently I began altering source code in stock Torque, and I have excelled with that, but OMNI introduces C# as its scripting language so I expected the transition to be very rough. This has not been the case at all, and this is mainly due to Vince's excellent Programmer's Manual documentation and direct contact with me to ensure that I was able to utilize the tools he's provided. These are some genuinely great guys!
Performance is over the top! OMNI isn't Torque, it really is a new engine. When I'm used to seeing my fps metric in the upper 100's on the Empty Terrain level, you can imagine my surprise when I launched up the same mission and was greeted with a fps metric in the upper 400's! Woot!
When Vince was talking about OMNI prior to release I was a bit of a skeptic. Not anymore. This is a ridiculously powerful set of tools which I'm only beginning to skim the surface of. Many sleepless nights ahead of me with OMNI. Thanks for all you do guys, the hard work really shows!
Edit: Oh, and I forgot to mention that if you are not ready to use C# just yet there are still templates in OMNI that you can use with TorqueScript. You will still see a huge performance increase(over 100fps in my case) and can slowly work your way up to the C# transition if you want. I could go on and on, I really could, about all the awesome packed into this release.
10/10/2014 (11:43 am)
I've been doing a bit of testing with OMNI, and there were 2 things that really stood out to me the past few days:When Vince was talking about OMNI prior to release I was a bit of a skeptic. Not anymore. This is a ridiculously powerful set of tools which I'm only beginning to skim the surface of. Many sleepless nights ahead of me with OMNI. Thanks for all you do guys, the hard work really shows!
Edit: Oh, and I forgot to mention that if you are not ready to use C# just yet there are still templates in OMNI that you can use with TorqueScript. You will still see a huge performance increase(over 100fps in my case) and can slowly work your way up to the C# transition if you want. I could go on and on, I really could, about all the awesome packed into this release.
#5
10/10/2014 (12:01 pm)
I also had around 50% more fps on the empty terrain, but 10-20% less fps on a full scene, it looks like you can get really big gains on scenes without much graphics load, where the script engine is the major impact on the performance, but it relativizes itself under load. 
#6
Whats the scene, and was it one built in omni or one that was ported over from a standard t3d build.
The reason I ask is that personally I've seen massive overall gains on pretty much full scenes (no AI, no Physics) when comparing the same scene to a T3D MIT Install, it might be worth debugging your scene a little, possibly a bad model in there if youre seeing a FPS decrease on the same scenes between T3D and Omni
10/10/2014 (12:14 pm)
"I also had around 50% more fps on the empty terrain, but 10-20% less fps on a full scene, it looks like you can get really big gains on scenes without much graphics load, where the script engine is the major impact on the performance, but it relativizes itself under load."Whats the scene, and was it one built in omni or one that was ported over from a standard t3d build.
The reason I ask is that personally I've seen massive overall gains on pretty much full scenes (no AI, no Physics) when comparing the same scene to a T3D MIT Install, it might be worth debugging your scene a little, possibly a bad model in there if youre seeing a FPS decrease on the same scenes between T3D and Omni
#7
I'll take that as a complement on the C# side of things.
10/10/2014 (12:14 pm)
Wait so Duion your saying that the graphics layer needs a revamp in T3D? hmmmm..I'll take that as a complement on the C# side of things.
#8
10/10/2014 (12:46 pm)
I did even get 100fps on a scene with Omni torquescript versus 90 fps on the same scene with Omni C#. I just think you need to make more tests under more controlled circumstances to really tell, since it is fluctuating a lot and 400 instead of 100 fps on a scene does not really help you at all, since 60 is the maximum you can see.
#9
Yes I know that 'scientifically' 60fps is all the human eye 'should' be able to perceive. But as a gamer since the Atari/Odyssey era, and a competitive one at that with FPS games...I can say that I personally can and do see a difference if I'm running at 60fps constant or 200fps. Maybe everyone can't, idk. But I notice it. Now I do have to say that visually I wouldn't notice a difference between, say, 100fps or 400fps. I think the difference is apples to oranges. In real life, our eyes process so many frames. But looking at a computer screen, in real life you are watching a screen shoot out frames which != the same as processing those visuals not looking at that screen.
The point is, though, if I'm starting a project and it's at 100 fps as opposed to a project I'm starting at 400fps - It's just that much more headroom I've got from the word go to add in the additional project specific features. The more AI routines, scheduling, or what have you that gets added the more that headroom gets chewed up. It's good to know I've got so much more room to grow.
It's also good to note that fps is a poor measurement of performance in the first place. It's just the quickest visual indicator to talk about I guess, so that's why I brought it up.
Edit: Oh, and I also wanted to give a special thank you to Cody! lol!
10/10/2014 (1:19 pm)
Didn't want any of this to turn into a fps war...but all of that 60fps mumbo jumbo is for the birds. Yes I know that 'scientifically' 60fps is all the human eye 'should' be able to perceive. But as a gamer since the Atari/Odyssey era, and a competitive one at that with FPS games...I can say that I personally can and do see a difference if I'm running at 60fps constant or 200fps. Maybe everyone can't, idk. But I notice it. Now I do have to say that visually I wouldn't notice a difference between, say, 100fps or 400fps. I think the difference is apples to oranges. In real life, our eyes process so many frames. But looking at a computer screen, in real life you are watching a screen shoot out frames which != the same as processing those visuals not looking at that screen.
The point is, though, if I'm starting a project and it's at 100 fps as opposed to a project I'm starting at 400fps - It's just that much more headroom I've got from the word go to add in the additional project specific features. The more AI routines, scheduling, or what have you that gets added the more that headroom gets chewed up. It's good to know I've got so much more room to grow.
It's also good to note that fps is a poor measurement of performance in the first place. It's just the quickest visual indicator to talk about I guess, so that's why I brought it up.
Edit: Oh, and I also wanted to give a special thank you to Cody! lol!
#10
OMNI and T3D are 2 different animals. You want to throw in a bunch of objects into a scene and spin around, there is a chance that T3D MIGHT outperform OMNI. I haven't seen it happen and Im designing a MMO with OMNI.
What you should see however, is that the FPS spikes are a lot less with OMNI. We have worked on optimizing the Hash and String tables so that its more stable across the board. was it at the cost of a few FPS? Yes. HOWEVER, once u put OMNI under a REAL LOAD (with explosions, AI and the stuff that makes up a real game) youll see that OMNI FPS is overall higher and more steady. We have run 300AI fighting each other and it was at 60FPS (last check) using the standard soldier in T3D.
No game is a bunch of pretty objects. put logic in it and then let us know what the performance difference is.
oh.... and 400FPS vs 100FPS is huge. remember the AI thought process? how about more objects? this will give u a lot more play room to add in more to a real game.
10/10/2014 (1:56 pm)
Duion:OMNI and T3D are 2 different animals. You want to throw in a bunch of objects into a scene and spin around, there is a chance that T3D MIGHT outperform OMNI. I haven't seen it happen and Im designing a MMO with OMNI.
What you should see however, is that the FPS spikes are a lot less with OMNI. We have worked on optimizing the Hash and String tables so that its more stable across the board. was it at the cost of a few FPS? Yes. HOWEVER, once u put OMNI under a REAL LOAD (with explosions, AI and the stuff that makes up a real game) youll see that OMNI FPS is overall higher and more steady. We have run 300AI fighting each other and it was at 60FPS (last check) using the standard soldier in T3D.
No game is a bunch of pretty objects. put logic in it and then let us know what the performance difference is.
oh.... and 400FPS vs 100FPS is huge. remember the AI thought process? how about more objects? this will give u a lot more play room to add in more to a real game.
#11
I just wanted to say, that the performance gain from the script engine is not everything. So if you start with 400 fps compared to 100 fps, it will not scale the same to the end, in the end it may boil down to 120 fps vs 100 or so.
Yes, I noticed it may run more smoothly, but there were still some lag spikes.
I don't want to do down the engine, but people may get false impressions, if someone says 400 fps instead of 100, this is just in special situations, overall it is hard to tell.
10/10/2014 (2:08 pm)
It does not help you, if you start with 400 fps instead of 100, if you still get 100fps in both version if you put it under load, this was what I wanted to say.I just wanted to say, that the performance gain from the script engine is not everything. So if you start with 400 fps compared to 100 fps, it will not scale the same to the end, in the end it may boil down to 120 fps vs 100 or so.
Yes, I noticed it may run more smoothly, but there were still some lag spikes.
I don't want to do down the engine, but people may get false impressions, if someone says 400 fps instead of 100, this is just in special situations, overall it is hard to tell.
#12
10/10/2014 (2:16 pm)
Then plz Duion, test the engine under whatever circumstances you want. tell us what u find and give us the levels so that we can take care of any issues there may be. 
#13
10/10/2014 (2:36 pm)
Nice work guys. Congrats. 
#14
10/10/2014 (3:39 pm)
Congrats guys, looks like a lot of work has gone into this! I shall be taking inspiration from your engine core changes to see what we can do about T3D ;).
#15
Feel free to use our code for inspiration, but of course don't copy it line for line w/out asking :P
10/10/2014 (3:58 pm)
Thanks Daniel,Feel free to use our code for inspiration, but of course don't copy it line for line w/out asking :P
#16
Oh I do know what to say... Why you! Now I once again do not get any sleep because 'll have to play around with yet another engine!!! :O)
Thanks for giving us the option of using C# and a better performance.
Have you tried to implement AFX 2.0 or UAIK with Omni?
And if yes how does it perform?
(perhaps that is not possible or can the Torque Script from addons still run in the background.... thinking, thinking...)
10/10/2014 (5:11 pm)
This is good news. I do not know what to say, really. Awesome stuff.Oh I do know what to say... Why you! Now I once again do not get any sleep because 'll have to play around with yet another engine!!! :O)
Thanks for giving us the option of using C# and a better performance.
Have you tried to implement AFX 2.0 or UAIK with Omni?
And if yes how does it perform?
(perhaps that is not possible or can the Torque Script from addons still run in the background.... thinking, thinking...)
#17
We haven't tried either AFX 2.0 or UAIK with OMNI. neither one is open source and we aren't using them in our own project atm.
NOW.... there is a dirty rumor that VERVE has been made "OMNI Ready".....
10/10/2014 (7:21 pm)
@Dwarf KingWe haven't tried either AFX 2.0 or UAIK with OMNI. neither one is open source and we aren't using them in our own project atm.
NOW.... there is a dirty rumor that VERVE has been made "OMNI Ready".....
#18
Also, Dwarf King, AFAIK Omni can still use TS as well as C#, hence the availability of TS and C# templates.
10/10/2014 (9:09 pm)
Would I do a thing like that?Also, Dwarf King, AFAIK Omni can still use TS as well as C#, hence the availability of TS and C# templates.
#19
HOWEVER, all TS can be converted to C# also......
10/10/2014 (9:19 pm)
absolutely Daniel, we DO have a TS template and that should make the adding in any of the normal add-ons simple. HOWEVER, all TS can be converted to C# also......
#20
10/10/2014 (10:59 pm)
@Duion - the 60 fps limit is not supposedly a visual limit but a reaction limit i.e. one can see faster frame rates but one can't press a button any faster than 60 fps so one gets no gameplay benefit from faster frame rates. No doubt there is some leeway in that. 
Torque Owner Triverske
Triverske LLC