#1 Holy shit this is cool!

#2 Free!!! Wow guys..a little speechless but thanks I'll give it a go and see how it compares..Also will be looking for the final release in a few weeks!

#3 Awesome!

#4 It sounds very interesting but...

Does it support DX11?

Does it support OpenGL 4.x?

Does it support Mac?

Does it support Linux?

Does it support any game consoles?

Does it support fbx?

#5 Since my expertise is not in any of the above questions I am deferring to the community. As soon as a solid PR is released on each of them they will be included in OMNI.

#6 It does sound very interesting indeed, the exact license terms though will be the most interesting part. I will say "no comment" on that part until the exact terms are published.

#7

Quote:I will say "no comment" on that part until the exact terms are published.

Well, somebody has to be the one to say it, so here goes.

I'll tell ya straight. I'm impressed by all the additions and updates. But(always a but...):

Why is there some new licensing being put into place?

Quote:
...only clause is you can't copy the code and say you wrote it or sell it as an engine that you wrote.

But isn't that exactly what you're doing by updating T3DMIT, slapping on some community resources, and laying claim to it? I'm sorry, but that just doesn't make a lot of sense to me. I mean, Sahara, really? That's fairly recently released by Conrad and a community resource. I use the zOffset community resource in my projects as well. I'm just wondering at what point the line is drawn here because I'm not going to stop using community resources because someone stuck a license on 'em.

I understand that you guys worked really hard to get all this done and I respect that, I really do! But here's the problem:

T3DMIT was released on good faith that the community would maintain and update it, so that its future could be secured. So why all the separate licensing? Why update the engine and then slap a label on it? Why not contribute all that effort to the actual T3D committee's efforts? If the intent is really to provide something 'free' to our community why isn't it exactly that and why aren't you guys working side by side with the T3D committee? Please enlighten me!

I may not be anyone special to you guys, but I'm a Torque fan. I care about the future of Torque, and I can't see all this as a good thing. I mean, you are literally 'pitching' OMNI as a replacement for Torque now...in the Torque community. Why not put all of that effort into the actual committee?

Look man, I'm sorry if I stepped on any toes but please look over my posting here and give it some serious thought. I have no ill intent here at all, I promise! Please just help me to understand the reasoning. What caused this fork in the community, where we have 2 different efforts to improve and secure the engine's future?

#8 I never expected them to release it for free and I don't have a problem that they slap over community resources, that is what should have been done anyway and what is allowed by the license. But we will have to wait for the exact license terms. My guess it, that it will not replace the original Torque3D project since additional licensing terms and become more like some kind of premium version of it, where they offer you support and keep the engine up to date.

#9 @Jesse,

I don't think you realize the scale of the C# Omni Framework implementation. It isn't just a one liner or a minor resource.

The Omni Framework is just not slapped onto T3D. It was a process that took over 3 years to write debug and inhance.

The Omni Framework brings T3D as close to Unity as possible.

We use to charge for the C# implementation, because what it brought to the engine was order, intellesense, and simplification. We made a decision to release this to the community for free.

We realized that there was no way we could ever recover the our financial investment in the engine, so instead of charging money for it we decided to open it up to the world.

This is why there is the license change. We have invested tens of thousands of dollars into the Omni Framework and we wish to hold onto our intellectual property.

In regard to the resources we added, we just didn't slap them onto the engine either. We went through the process of evaluating them line for line, optimizing them and debugging them so that they were stable.

Ultimately, the choice will be yours on whether or not you wish to use the Omni T3D engine.

You always have the choice to use the MIT project. Or if you want a version of the engine that is being improved constantly and supported by a paid dedicated team of developers you can use Omni.

Vince

#10 @Jesse,

The final reason, of course is that the community cannot decide on which script language to implement in T3D. Everyone talks about it and no one does anything about it.

We made a decision, we choose c#.

As of MIT 3.6 the code base will be diverging since they will be moving away from the project manager, they are getting rid of the T3D.DLL among other things.

Unfortunately none of this is compatible with the OMNI Framework. This means that the Omni T3D engine will slowly be different that T3D.

As much as I don't agree with them getting ride of the T3D DLL, (cause well that means the web based game will never work again, and Demolishm's Python won't work, etc.) I still must respect the decisions of the MIT Group and accept it.

So with this, the Omni Framework will no longer be something that can just be added to T3D, in a sense it will become it's own engine based on T3D.

This doesn't mean I won't be posting code back to T3D when I can, I still submit code and bugs to the MIT project. It's just our two projects are no longer compatible.

#11 Your links are dead and giving us the 404 error...

#12 Ahh, they are working on the website, I'll update the links in a second.

#13 @Vince,

You are correct, I hadn't the faintest idea about just how much has been vested into implementing OMNI. Your response was both professional and courteous, thank you Vince. I have followed some bits of your works and others from your team in the past and I have always been duly impressed. I'm sure that OMNI will be no exception.

I've been a Torque fan for some time. Not quite as long as many of the vets you find here in the GG community, but long enough I consider myself vested in Torque and I do want to continue to develop using Torque. It's good to see someone taking the bull by the horns, so to speak, and riding it home. I'm sure that in a situation such as this
it's easy enough for things to get a bit hairy, no reason for me to add fuel to that. I didn't fully test the water before jumping in I suppose.

I do look forward to taking a look at the potential 'alternate' future of Torque. I know that, if nothing else, you have been here in the past for the community and there's no reason that you wouldn't continue to do so. I am very glad that you still submit bugs to the MIT team, because I have grown to like those guys :) They have been overly helpful to me as of late, and that could have made me a bit more defensive.

I'm not fluent with C#, in fact I've just started to dig deeper into C++(actually picking that up rather quickly, I feel like TorqueScript was a fantastic primer), so I suppose that's one hurdle I'd have to overcome. May as well, what's yet another syntax? Starting to feel like candy at this point lol.

In any event, please accept my humblest apology. I know you guys are all very excited to share this with everyone! I'm also truly thankful that you cleared up all of that. I was aware you guys were up to something big, but I guess I never understood the entirety of what it was going to end up being. Now, man, get us some license details :)

Sincerely,
-Jesse

Edit: Hey, while I've got your attention allow me to report a 'bug' with the ShapeBase Player Culling resource. It's a very specific closet case that was hard for me to track down. What I was doing was implementing a sideview camera and with the resource in place it was causing the Player's Control Object to change, thus making the Player invisible and changing the view to the camera. I discovered it was the Culling resource causing this. More details here. If you read that posting and the posting above it (#12) you'll see how I noticed it. If you really wanted to be awesome you could suggest a solution for the player possibly dropping 'out of scope' later on if he runs so far off. As indicated in post 12 :)

#14 @Jesse,
Just for a little perspective on MIT and BSD licenses. The first TCP/IP stack for Windows 95 was pulled out of FreeBSD. The license allowed for it and they needed a TCP/IP stack "now" back then. That is why there is still a "hosts" file and a directory structure similar to the original directory structure for Unix style stacks.

IMO I see T3D as something that coders from all engines and programs can draw almost 2 decades worth of code wisdom from. I fully expect people to gut pieces and parts of the engine as time goes on. The networking especially. There is a lot of very well written code in the engine that could see new life in other places.

I see the Omni and other Winterleaf projects as a step in the natural maturation of the tech. People are going to fork the engine for various reasons and purposes. The challenge the community has is to NOT alienate those efforts. Because the talent that is able to fork the engine and use it in a project/product will inherently give back over time. I really like that the Winterleaf folks are always "trolling" (in the most positive sense of the term) the forums and helping out. This tells me they are as much invested in this community as the anyone else. This is healthy. When money is involved with companies participating the community can grow.

When in doubt always refer to the proper music to get your head back in the game:
www.youtube.com/watch?v=QWWsWP9bPAg

#15 Just stepping in to note that the DLL has not gone away, but CMake is currently not set up to generate it. The project generator functions as usual and we are still supporting it until we have full feature parity, and have found an alternative for the project manager to use.

#16 @Jesse,

I'd be more than happy to help you chase it down. If it is culling the player object on the edge of the screen that has me confused. It shouldn't be. Is the camera off the edge of the terrain?

If you are still using the resource, we can arrange a desktop share so I can see the breakpoint in action. Wouldn't take much to fix it once I understand the scope of the error.

As always, my email is vgee@winterleafentertainment.com and I'm always open to questions.

#17 Well, now that you've opened the door...Haha, between you, Danny, and Andrew I might actually stop stumbling over silly problems =) Nah, it wasn't on the edge of the screen. I'm a bit busy tonight so it may be tomorrow before I get a chance but I'll drop you an e-mail with a little bit more detail. If it can lead to improving the culling in any way that'd be great! I had to yank the resource for now, since it was causing me the troubles but I think you'd be able to knock it out easily once I explained the specifics. Cheers!

#18 Links are still not working...

#19 Link for download C# game is Here

#20 Well, I wasnt expecting this...

Havent been about much on here for probably the good part of a year, honestly, lost my thirst for torque as it seemed to be stalling too much, aswell as certain characters in the community just grating on my nerves a bit too much... this has got my attention back though, and first impression is that it loads incredibly fast, and that LoD mission, damn, I remember trying a test scene on the BaG building packs, lodding them like crazy with the old BSP stuff, managed about 500 in a scene but the load time on the mission was ridiculous, that one loads in an instant and I'm impressed. The only concern I do have though and I have no idea what would cause it within omni is the way my GPU fan goes banana's straight off the bat when it loads up... doesnt happen with t3d standard until its been running for a while, it gradually builds up speed, any ideas ? it actually sounds like its going faster than when i pull up afterburner and set it manually to 100% if i have afterburner running with omni on, it states its only running at about 65% speed, yet if i override it and manually set it to that speed, you hear it going slower ? Kinda confused by it