Tgea Vs Leadwerks 2.0 Engine
by Morrie · in General Discussion · 05/02/2008 (12:40 pm) · 50 replies
Leadwerks Engine 2.0 Features
Rendering
* Unified per-pixel lighting system with dynamic soft shadows; Every object casts and receives shadows.
* Point, spot, and directional lights.
* Masked shadows for tree and plant effects.
* Specular reflection and normal mapping.
* Parallax mapping.
* Fast instanced mesh rendering.
* Dynamic visibility determination, requiring no pre-placed portals or compiling.
* Hardware skinning for fast animation.
* Bloom, depth-of-field, motion blur, and other post-processing effects.
* Fast hardware particle effects.
* Seamless transitions between indoor and outdoor areas.
* Adjustable rendering viewports.
* Support for ambient occlusion maps.
* Render to any graphics context to create Windowed applications and tools.
* Render to texture.
* Lens flare effects.
* Dynamic shader management chooses from thousands of variations and compiles requested shaders on-the-fly.
* Open-ended materials and shader system.
* Use existing shaders or add your own.
* Optimized rendering pathways for Shader Model 4.0, with render fallbacks for older hardware.
* Features can be scaled to accommodate older hardware.
* Load textures from .dds, .png, .tga, .bmp, and .jpg files.
Meshes
* Load .obj, .md3, and .gmf meshes, or create meshes from scratch.
* Support for animated meshes with fast hardware skinning.
* Create box, cylinder, sphere, cone, and plane primitives.
* Support for arbitrary number of LOD versions.
* Fast mesh rendering using GPU instancing, if available.
Terrain
* Huge landscapes with up to 33 million triangles.
* Simulate areas up to 650 square miles.
* Dynamic lighting and self-shadowing terrain allow day/night cycles and weather effects.
* Modify terrain in real time.
* Vegetation layers can simulate millions of plants.
* Alpha-blended tiling terrain.
Animation
* Hardware skinning for fast animation.
* Blend animations, or mix hard-coded actions or physics with animation.
* Attach weapons or items to animated limbs.
* Attach physics bodies to limbs for animated collision and locational damage.
Physics
* Support for multi-core CPU acceleration.
* Simulate thousands of rigid bodies.
* Create complex machines with ball, hinge, corkscrew, slider, universal, and fixed joints.
* Physics vehicles with any number and configuration of tires.
* Extremely fast solver, with far greater stability than any other physics engine on the market.
* Collisions with polygon meshes, convex hulls, boxes, cylinders, cones, spheres, chamfer cylinders, and capsules, or compound collisions made up of any combination thereof.
* Player controller simulates player movement while participating in complex physics interactions.
* Customizable collision system with support for any number and scheme of collision types and interactions.
* Powered by Newton Archimedes
Rendering
* Unified per-pixel lighting system with dynamic soft shadows; Every object casts and receives shadows.
* Point, spot, and directional lights.
* Masked shadows for tree and plant effects.
* Specular reflection and normal mapping.
* Parallax mapping.
* Fast instanced mesh rendering.
* Dynamic visibility determination, requiring no pre-placed portals or compiling.
* Hardware skinning for fast animation.
* Bloom, depth-of-field, motion blur, and other post-processing effects.
* Fast hardware particle effects.
* Seamless transitions between indoor and outdoor areas.
* Adjustable rendering viewports.
* Support for ambient occlusion maps.
* Render to any graphics context to create Windowed applications and tools.
* Render to texture.
* Lens flare effects.
* Dynamic shader management chooses from thousands of variations and compiles requested shaders on-the-fly.
* Open-ended materials and shader system.
* Use existing shaders or add your own.
* Optimized rendering pathways for Shader Model 4.0, with render fallbacks for older hardware.
* Features can be scaled to accommodate older hardware.
* Load textures from .dds, .png, .tga, .bmp, and .jpg files.
Meshes
* Load .obj, .md3, and .gmf meshes, or create meshes from scratch.
* Support for animated meshes with fast hardware skinning.
* Create box, cylinder, sphere, cone, and plane primitives.
* Support for arbitrary number of LOD versions.
* Fast mesh rendering using GPU instancing, if available.
Terrain
* Huge landscapes with up to 33 million triangles.
* Simulate areas up to 650 square miles.
* Dynamic lighting and self-shadowing terrain allow day/night cycles and weather effects.
* Modify terrain in real time.
* Vegetation layers can simulate millions of plants.
* Alpha-blended tiling terrain.
Animation
* Hardware skinning for fast animation.
* Blend animations, or mix hard-coded actions or physics with animation.
* Attach weapons or items to animated limbs.
* Attach physics bodies to limbs for animated collision and locational damage.
Physics
* Support for multi-core CPU acceleration.
* Simulate thousands of rigid bodies.
* Create complex machines with ball, hinge, corkscrew, slider, universal, and fixed joints.
* Physics vehicles with any number and configuration of tires.
* Extremely fast solver, with far greater stability than any other physics engine on the market.
* Collisions with polygon meshes, convex hulls, boxes, cylinders, cones, spheres, chamfer cylinders, and capsules, or compound collisions made up of any combination thereof.
* Player controller simulates player movement while participating in complex physics interactions.
* Customizable collision system with support for any number and scheme of collision types and interactions.
* Powered by Newton Archimedes
#42
As far as the physics and audio subsystems I have chosen to use, that is correct. I suppose you could replace the physics or audio with something else, but no one has ever bothered to.
06/26/2008 (2:37 pm)
I took your statement to mean something it did not. I thought it meant that object behaviors were sort of hard-programmed into the engine. You would be amazed how often someone asks me if they can specify any camera angle, because they are used to dealing with systems where "camera angle" is a built-in paradigm! :D It makes no sense to me.As far as the physics and audio subsystems I have chosen to use, that is correct. I suppose you could replace the physics or audio with something else, but no one has ever bothered to.
#43
@Leadwerks - Oops, sorry for the "Leadwerx" spelling error :-(
@Ross - I'm not afraid of putting my nose to the grindstone, but I don't like to "just get something working."
I like things to work, but I prefer things to work the right way.
Distributed with source code is one of the great features of Torque... but of course it has to be done that way since you pretty much have to modify the source code in order to create your games.
It's nice that you can modify the source... it's not nice that you must modify the source.
I gave the physics example just because it's one of the things that I'm solving with the Zen Framework.
But, if you're creating something like an RPG game, how much do you have to modify when you're using Torque? Quite a bit.
Making modifications to existing code is risky if you're not familiar with the code (as is true of most people using Torque). If you only had to add new code to make things work the way you wanted then you would be much better off.
Of course, if you had an RPG starter kit then things would be all the more easier.
In fact, making game engine agnostic starter kits is one of the beautiful features that the Zen Framework provides. Being able to pick and choose game engine components is another great feature.
With Torque you can switch physics engines and create an RPG, FPS, RTS game, but wouldn't it be great if you could do it without having to write so much code?
Again, I don't think anyone here is afraid of writing code, but some of this seems like a huge waste of time to me.
Wouldn't you rather be spending time making your game innovative and fun rather than constantly reinventing the wheel?
06/26/2008 (3:24 pm)
@Mika - For Leadwerks, I can see your point. For Torque, I don't necessarily want to add new features, I just want to see some of the existing features refactored so that the engine is more useful for more people. (i.e. an API instead of a bunch of code that requires you to hack and slash to get it to work the way you want it to work.@Leadwerks - Oops, sorry for the "Leadwerx" spelling error :-(
@Ross - I'm not afraid of putting my nose to the grindstone, but I don't like to "just get something working."
I like things to work, but I prefer things to work the right way.
Distributed with source code is one of the great features of Torque... but of course it has to be done that way since you pretty much have to modify the source code in order to create your games.
It's nice that you can modify the source... it's not nice that you must modify the source.
I gave the physics example just because it's one of the things that I'm solving with the Zen Framework.
But, if you're creating something like an RPG game, how much do you have to modify when you're using Torque? Quite a bit.
Making modifications to existing code is risky if you're not familiar with the code (as is true of most people using Torque). If you only had to add new code to make things work the way you wanted then you would be much better off.
Of course, if you had an RPG starter kit then things would be all the more easier.
In fact, making game engine agnostic starter kits is one of the beautiful features that the Zen Framework provides. Being able to pick and choose game engine components is another great feature.
With Torque you can switch physics engines and create an RPG, FPS, RTS game, but wouldn't it be great if you could do it without having to write so much code?
Again, I don't think anyone here is afraid of writing code, but some of this seems like a huge waste of time to me.
Wouldn't you rather be spending time making your game innovative and fun rather than constantly reinventing the wheel?
#44
On the topic of flexibility, I think all engines are, at some level, inflexible. Every game I have worked on has had either myself, or other programmers tasked with doing stuff the engine wasn't designed to do initially; weather that engine is Gamebryo, Torque, Unreal or Leadwerks. That's the essence of game development. We are always going to be taking the engine, and hacking on it. It's the same on the art side. Give an engine, any engine, and a computer, any computer, to an artist, and they'll make the game run at 5fps. The challenge in game development isn't how many features can you pack in, it's how many can you take advantage of/shortcut and still run at 60fps.
@Tony:
I totally re-wrote the skinning loop. It does some horrible things in stock Torque, like operating per-bone-per-vertex, instead of just looping over all of the verts and applying all relevant bone transforms in one go (This is why the mesh skinning code in stock Torque operates on a chunk of memory, instead of just writing directly into a locked vertex buffer, because it needs readback support). I re-wrote the code to create skin batch requests, and separated the data. The initial transforms, normals, etc don't change. The only thing that changes per-frame is the current bone transforms.
On the rendering side, the Torque 2 solution looks like it's going to be deferred shading + shadow maps (PSSM's for the sunlight). For threading, we need to thread input, have a generic asynchronous task processor, and probably split out graphics API calls into a dedicated thread. When is all that going to happen? No idea. Some code is developed in tech code bases, some (like threading and deferred rendering) in games like Rokkitball.
06/26/2008 (3:45 pm)
I don't want to jump back into the feature stuff discussion.On the topic of flexibility, I think all engines are, at some level, inflexible. Every game I have worked on has had either myself, or other programmers tasked with doing stuff the engine wasn't designed to do initially; weather that engine is Gamebryo, Torque, Unreal or Leadwerks. That's the essence of game development. We are always going to be taking the engine, and hacking on it. It's the same on the art side. Give an engine, any engine, and a computer, any computer, to an artist, and they'll make the game run at 5fps. The challenge in game development isn't how many features can you pack in, it's how many can you take advantage of/shortcut and still run at 60fps.
@Tony:
I totally re-wrote the skinning loop. It does some horrible things in stock Torque, like operating per-bone-per-vertex, instead of just looping over all of the verts and applying all relevant bone transforms in one go (This is why the mesh skinning code in stock Torque operates on a chunk of memory, instead of just writing directly into a locked vertex buffer, because it needs readback support). I re-wrote the code to create skin batch requests, and separated the data. The initial transforms, normals, etc don't change. The only thing that changes per-frame is the current bone transforms.
On the rendering side, the Torque 2 solution looks like it's going to be deferred shading + shadow maps (PSSM's for the sunlight). For threading, we need to thread input, have a generic asynchronous task processor, and probably split out graphics API calls into a dedicated thread. When is all that going to happen? No idea. Some code is developed in tech code bases, some (like threading and deferred rendering) in games like Rokkitball.
#45
Now, I will agree that things should be more modular, but they're going that way. The Jugg based directory structure is a good example of this. Now in Jugg-branched Torque versions, there is the paradigm that you have a game specific "source" dir that is separate from the core engine stuff. The project generator is another example. Things are moving in that direction, which may not be apparent from these latest releases.
I don't think your examples give a compelling reason that Torque isn't suitable. Also, what type of RPG? A JRPG? An MMO? Turn based, pseudo-turn based (like all MMOs on the market save Planetside and WWIIOnline), real time (Oblivion, Mount&Blade)? I don't see why you couldn't make any of those types of games in Torque. And in fact, people have done so. Minions of Mirth? Penny Arcade's game? Two examples of those different styles. Those combat systems are obviously something very game specific, and the rest of it is mostly GUI work. The new dir structure facilitates this easily.
Furthermore, how do you propose to make it so all you have to do is "add new code"? I don't see it necessarily being much easier for people, since they'd still have to hook it up into the engine, which brings us back to the current state of things where you're basically hacking your way through to get what you want anyway.
EDIT: Pat is spot on with this ->
06/26/2008 (3:57 pm)
Quote:I like things to work, but I prefer things to work the right way.See, Tony, I think you're digging yourself an endless pit with this sort of thinking. The "right" way is entirely a subjective measure. What is right for me versus what is right for someone that doesn't ever want to look at a single line of C++ or wants their engine to be written in Java (or C# or whatever) is entirely different. If your goal is to have everything done "the right way" your job will never be done. I guarantee that most of the shipped games out there today don't have engines that are doing everything "the right way."
Now, I will agree that things should be more modular, but they're going that way. The Jugg based directory structure is a good example of this. Now in Jugg-branched Torque versions, there is the paradigm that you have a game specific "source" dir that is separate from the core engine stuff. The project generator is another example. Things are moving in that direction, which may not be apparent from these latest releases.
Quote:But, if you're creating something like an RPG game, how much do you have to modify when you're using Torque? Quite a bit.Such as? I have a feeling that most of the stuff you're thinking of is game-specific code. Torque shouldn't have an "RPG combat system" since there is NO way that GG would be able to write up every possibly combat system that you could classify as "RPG combat" without the engine/company suffering.
I don't think your examples give a compelling reason that Torque isn't suitable. Also, what type of RPG? A JRPG? An MMO? Turn based, pseudo-turn based (like all MMOs on the market save Planetside and WWIIOnline), real time (Oblivion, Mount&Blade)? I don't see why you couldn't make any of those types of games in Torque. And in fact, people have done so. Minions of Mirth? Penny Arcade's game? Two examples of those different styles. Those combat systems are obviously something very game specific, and the rest of it is mostly GUI work. The new dir structure facilitates this easily.
Quote:Making modifications to existing code is risky if you're not familiar with the code (as is true of most people using Torque). If you only had to add new code to make things work the way you wanted then you would be much better off.This is probably true of any engine though. Do you think that the users here would be able to go into the guts of Unreal 3 and just change something without understanding the ramifications? I don't. Making modifications to the code of any software as complex as a game engine is risky.
Furthermore, how do you propose to make it so all you have to do is "add new code"? I don't see it necessarily being much easier for people, since they'd still have to hook it up into the engine, which brings us back to the current state of things where you're basically hacking your way through to get what you want anyway.
Quote:In fact, making game engine agnostic starter kits is one of the beautiful features that the Zen Framework provides. Being able to pick and choose game engine components is another great feature.Erm, engine agnostic? I think this is probably a pipe dream. Especially if you're talking about modern graphics too. You might be able to do this in a limited fashion by providing a bunch of hooks in your kit code itself, but you're still going to have to write a lot of code to get it to work with a given engine, IMO. The systems are usually just too tightly integrated to do this in such a fashion that doesn't mean you're just writing the kit over again for several specific engines.
Quote:Again, I don't think anyone here is afraid of writing code, but some of this seems like a huge waste of time to me.I can't say I agree with that. There are a lot of people that seem to want something that is more of a WYSIWYG type game maker than an engine.
Quote:With Torque you can switch physics engines and create an RPG, FPS, RTS game, but wouldn't it be great if you could do it without having to write so much code?I don't really think so. Physics are something that really need to be done on a per game basis IMO, since you can implement these physics libs myriad different ways. And really, it's not actually very much code. Once you have the places you need to put your lib functions stubbed out, using one lib versus another would be fairly trivial really. Especially in the case of physics, I don't see it being done for you as a benefit, but really just a disadvantage. What if you want a special type of character controller that your canned physics plugins don't support? You have to write code. You might even have to write a lot MORE code than if you'd merely implemented it yourself in the first place. It always comes back to that.
EDIT: Pat is spot on with this ->
Quote:On the topic of flexibility, I think all engines are, at some level, inflexible. Every game I have worked on has had either myself, or other programmers tasked with doing stuff the engine wasn't designed to do initially; weather that engine is Gamebryo, Torque, Unreal or Leadwerks. That's the essence of game development. We are always going to be taking the engine, and hacking on it. It's the same on the art side. Give an engine, any engine, and a computer, any computer, to an artist, and they'll make the game run at 5fps. The challenge in game development isn't how many features can you pack in, it's how many can you take advantage of/shortcut and still run at 60fps.
#46
I had a lot longer post, but since it wouldn't fit in a single post I'll keep it brief... probably better that way anyway.
I definitely will keep in mind the things that you're saying won't work because I believe a lot of what you're saying is correct.
But... I think you're looking for ways that this won't work while I'm looking for ways that it will work.
What I am trying to do is make it so that you at least have the choices to begin with... more choices than what are available today.
Another thing I'm trying to do is make it so that no matter what choices you make, you have a significant amount of game specific code (i.e. starter kits) that you can pull into your game and either use verbatim, or modify and/or extend.
Take a look at other successful open source projects... Apache, Linux, Eclipse, etc... they're huge, complex beasts.... probably no one person could write these applications nor would it be viable for a commercial company to create something like these products and turn around and sell them for a profit. They're too expensive to create and maintain, so they divide the work among many individuals and companies and it works.
Zen Framework is a whole lot smaller than any of these other projects... Eclipse is over 3 million lines of code and I don't expect Zen Framework to even reach 250k lines of code.
People like you and Pat and a quite a few others here... well, probably you wouldn't benefit from such a project... You don't need any starter kits and you're familiar enough with Torque to just dive right in and start slinging code around. Zen Framework would only get in your way and you would hate using it if you ever even started to try.
Not everyone has this luxury... you know, the people you were talking about that would be skittish about diving in to the Unreal game engine (or any game engine for that matter) and changing code? You know the people that buy content packs and starter kits and dig through the resources and documentation all the time to see if someone else has written something that will be useful for them? You know the people that bought Torque or some other game engine two or more years ago and they still haven't finished a game yet?
I think that pretty much describes about 90% of the licensees of every game engine that sells for less than $500.
Well, those people are the people that would be most interested in Zen Framework.... this is for them. The other 10% can ignore this... :P
06/26/2008 (7:19 pm)
@RossI had a lot longer post, but since it wouldn't fit in a single post I'll keep it brief... probably better that way anyway.
I definitely will keep in mind the things that you're saying won't work because I believe a lot of what you're saying is correct.
But... I think you're looking for ways that this won't work while I'm looking for ways that it will work.
What I am trying to do is make it so that you at least have the choices to begin with... more choices than what are available today.
Another thing I'm trying to do is make it so that no matter what choices you make, you have a significant amount of game specific code (i.e. starter kits) that you can pull into your game and either use verbatim, or modify and/or extend.
Take a look at other successful open source projects... Apache, Linux, Eclipse, etc... they're huge, complex beasts.... probably no one person could write these applications nor would it be viable for a commercial company to create something like these products and turn around and sell them for a profit. They're too expensive to create and maintain, so they divide the work among many individuals and companies and it works.
Zen Framework is a whole lot smaller than any of these other projects... Eclipse is over 3 million lines of code and I don't expect Zen Framework to even reach 250k lines of code.
People like you and Pat and a quite a few others here... well, probably you wouldn't benefit from such a project... You don't need any starter kits and you're familiar enough with Torque to just dive right in and start slinging code around. Zen Framework would only get in your way and you would hate using it if you ever even started to try.
Not everyone has this luxury... you know, the people you were talking about that would be skittish about diving in to the Unreal game engine (or any game engine for that matter) and changing code? You know the people that buy content packs and starter kits and dig through the resources and documentation all the time to see if someone else has written something that will be useful for them? You know the people that bought Torque or some other game engine two or more years ago and they still haven't finished a game yet?
I think that pretty much describes about 90% of the licensees of every game engine that sells for less than $500.
Well, those people are the people that would be most interested in Zen Framework.... this is for them. The other 10% can ignore this... :P
#47
I think with a lot of work on the tools, and some work cleaning up the interface for various things, as well as some increasingly complex examples of doing stuff, people that are struggling now could be doing what they want.
I do think having a library of little game-specific snippets is a good idea, but I seriously doubt that any such thing will ever be engine agnostic, and would probably be less useful if they were, since the user would still have to know enough about both the snippets and the target engine to integrate them.
06/26/2008 (7:47 pm)
Quote:People like you and Pat and a quite a few others here... well, probably you wouldn't benefit from such a project... You don't need any starter kits and you're familiar enough with Torque to just dive right in and start slinging code around. Zen Framework would only get in your way and you would hate using it if you ever even started to try.Probably true, and I recognize that.
Quote:Not everyone has this luxury... you know, the people you were talking about that would be skittish about diving in to the Unreal game engine (or any game engine for that matter) and changing code? You know the people that buy content packs and starter kits and dig through the resources and documentation all the time to see if someone else has written something that will be useful for them? You know the people that bought Torque or some other game engine two or more years ago and they still haven't finished a game yet?The thing is, I honestly don't think that much separates people that haven't done much and are frustrated and struggling from people that "get it" and have done cool things with the engine. It all boils down to a lack of knowledge in general and in particular about "How do I do XYZ?" Although, to some degree there is also the ability to decompose something like "How do I make an inventory system?" into smaller, more manageable problems. Many people don't have that skill down well.
I think with a lot of work on the tools, and some work cleaning up the interface for various things, as well as some increasingly complex examples of doing stuff, people that are struggling now could be doing what they want.
I do think having a library of little game-specific snippets is a good idea, but I seriously doubt that any such thing will ever be engine agnostic, and would probably be less useful if they were, since the user would still have to know enough about both the snippets and the target engine to integrate them.
#48
The smaller pieces of code probably won't be worthwhile other than as pieces that are included in examples like you said.
Tools are definitely another key factor... but that's another discussion altogether and I don't have the energy to start it right now.
This has been a nice discussion... we'll have to do it again sometime... :-P
06/26/2008 (8:15 pm)
I think I have a way for the integration to be nearly as simple drag and drop, but I suppose we'll find out, right? :DThe smaller pieces of code probably won't be worthwhile other than as pieces that are included in examples like you said.
Tools are definitely another key factor... but that's another discussion altogether and I don't have the energy to start it right now.
This has been a nice discussion... we'll have to do it again sometime... :-P
#49
06/26/2008 (8:38 pm)
I'd love for you to prove me wrong about the drag and drop-ness of the kits.
#50
TGE has been around for awhile, though it has natively lower graphics potential, according to GG it can be manipulated into what you want...TGE(A) also has this feature because you can have the source-code.
LE2 though has stated the Headers can be used to program things quickly, and the fact it comes with things SM3 and SM4 OpenGL is very interesting, but it's just your typical next-gen engine.
Also Unreal3 being 1000s of dollars has been test-proven over and over again to bring the pedal to the medal, so not many people can compete with it, so end of discussion there.
All I can say is if the guys at LE2 want more interest, they just need to keep fixing and refixing 'til it's just as good as anything else.
06/27/2008 (5:32 am)
LE2 is a very new program, but it seems to have the same pricing as TGE, but the CEO of LE2 himself has ran into issues with the engine, and so it seems the engine is very unstable right now.TGE has been around for awhile, though it has natively lower graphics potential, according to GG it can be manipulated into what you want...TGE(A) also has this feature because you can have the source-code.
LE2 though has stated the Headers can be used to program things quickly, and the fact it comes with things SM3 and SM4 OpenGL is very interesting, but it's just your typical next-gen engine.
Also Unreal3 being 1000s of dollars has been test-proven over and over again to bring the pedal to the medal, so not many people can compete with it, so end of discussion there.
All I can say is if the guys at LE2 want more interest, they just need to keep fixing and refixing 'til it's just as good as anything else.
Torque Owner Mika Heinonen
Torque has a feature list, Leadwerks Engine has a feature list, other engines have their feature lists too.
What I don't understand why people want engines to support things which they are not meant to support, there's enough engines out there which support most things that you want, and probably none which supports everything you want. I mean it's good to give improvement suggestions, but to ask to support obsolete things or things which make no sense or are worse than the existing things is not needed.
If there was one engine for all needs, I wouldn't have bought 7 engines (of which I use Leadwerks only :P).