Introduction and the Future of Torque
by Kenneth Hamilton · in Torque 3D Professional · 06/08/2014 (6:08 pm) · 36 replies
Let me start off by introducing myself. My name is Kenneth Hamilton, or you can call me Kenny. I don't really consider myself a developer. I have no published titles or experience in the gaming industry, indie or otherwise. I do consider myself an artist. I have been drawing for well over 30 years and transitioned into the world of 3D a little over a decade ago. I very rarely speak to people, in real life or otherwise. Because of this, I feel that my communication skills may be lacking, but please bare with me. I guess one could call me a self-imposed pariah. I do, however, research and observe things, a lot.
I grew up in the days of 4bit graphics on the Atari 2600 transitioning over to 8bit NES and so on. I got my first PC when I was in high school, almost 25 years ago. Ever since I discovered the possibilities of the computer, I've been fascinated with learning everything I could, including a desire to make games. I have been an avid user and supported of open source software for over a decade. That's what in turn led me to this community when Torque went MIT.
I have noticed a lot of talk lately about the future of Torque. People saying Torque can't compete with what's out there, and needs features, features, features. I've seen that some people are afraid that since Torque is now open source it will fade away because open source projects rarely succeed. I've seen the community fractured in places, and some people leave, while others just remain silent. I've seen a lot in this community in the short time I've been here. Having said that, I am no stranger to these things as I have seen many open source communities go through these same struggles. In way, I guess one could call it growing pains. As I said, I have been around open source software for well over a decade and was there when Blender was initially released as an open source project. And if anyone were to visit blenderartists or some of the other blender forums, they would probably find a lot of similarities to this community with one notable exception... size. Because this community is so much smaller, things that might be par for the course in larger forums automatically sticks out like a sore thumb here and gets noticed more. Case in point, if you go to blenderartists, you will probably find way too many threads started for feature requests, or other threads talking about how blender's UI sucks or this or that. What sets that community apart is that Blender is techinically a success in the open source community.
I don't think Torque MIT has truly had enough time yet to gain traction to be the success that Blender has become. And I think that might be why so many people are wary of its future. But we have to remember, Blender has been at this a lot longer and had to take some big strides to get noticed. And that brings me to my next point. Development. As I said before, I don't consider myself a developer, so take anything I say with a grain of salt, and feel free to correct me if I am wrong in any of my assumptions. I think that in order to get Torque up a level playing field with Blender as an open source project, there are certain things that need to happen. First and foremost, we need to grow the community. The problem is, how to do it? Depending on who you ask you'll get a different answer, and this is mine. Although it is only an opinion, I think what would help grow the Torque community is a closer relationship with Blender. Don't take that the wrong way, I don't mean the Blender Foundation, but rather the Blender community. If Torque can leverage the size of the Blender community and start getting people to adopt Torque as their engine of choice, then the user base could grow exponentially. I think this is why Valve and Epic have started to develop a closer working relationship with the Foundation because they see the huge potential that Blender has for the indie community, and let's face it, isn't that who Torque should be geared towards?
So how could we get that leverage then? I've been thinking about this too. I spend as much time at the blenderartists forums as I do here, I observe a lot of the converstaions that happen in the threads, the BGE threads in particular. I've seen a lot of the same conversations take place in there, as to why people use BGE.
1.) It's built into the editor. I have seen so many people use that as a primary reason, because they don't have to export their assets. I think Torque is already on its way to dealing with the import issue. If Assimp gets fully integrated into Torque for the importing of meshes before caching them out to DSTs it would help tremendously especially since Assimp reads blend files. I don't know how well that would work with animated meshes, but its a start.
2.)Python. Many of the BGE users use it because they can script in python. One user compared it to programmer's crack because it was so addictive. Personally, I am not the biggest fan of python, but to each their own. I do think if we had access to other scripting languages besides TorqueScript it would at the very least tempt more users to try it out. I believe that there was some talk on getting other scripting languages implemented, but I don't know if its still an ongoing thing.
3.)Linux support. Many Blender users are very picky about their operating systems and refuse to use Microsoft prodcuts at all, which completely cancels out DirectX. Once the the Linux and OpenGL ports of Torque is completed, I think that in itself will add to the adoption rate.
These are just a few things that could be done to help integrate some people over to using Torque. But by itself, it isn't nearly enough. I said before that Blender had to take some major strides to be noticed. One thing it did to really set itself apart from other open source projects was when it produced the open film projects. Starting with Elephant's Dream, the Blender Foundation started using Blender in a production environment and developing tools as it went. That was actually a very good decision, not only for publicity, but it allowed the developers to focus on areas that were lacking in the current toolset and target those areas specifically. To apply this to Torque, I think what would work is a community developed game. Although I've never actually played it, I heard that Tribes was a very good game and the backbone of what Torque is known for. If the community could come together and develop something similar, developing the tools as they go, then the end product would be good for marketing but also serve to further engine development. I think spilitting the focus for this project would be what's best however. I know some people would want those tools to be focused on graphics but I don't think that would be best. I think for the initial development it should primarily be focused on usability. I also think if every step of the production was documented, whether through text or visually like a developer's diary so that others can see how things are done. I think it could actually help get more people involved in the development phase if they know how things are working. And example might be just making a basic asset and importing it into the engine and getting it set up. Or using various modular assets in conjunction with each other to flesh out a level. If it's simple enough that a caveman can do it, then people might actually start coming in from other communities to help.
As for the graphics side of things, I do agree that to remain relevant the graphics are going to need to be upgraded at some point. That's just the simple truth of technology. But I think that would work better as a tech demo. Think Samaritan or Infiltrator. Those were realtime demos, but they weren't games. I think if we had just a 3 or 4 minute demo showcasing what Torque was capable of as part of an upgrade that would have mass market appeal. Again though, it would have to be a community driven effort.
All of these things are well and good, but the question remains, where do we start? Honestly, all I can say is what I would do if I were the one in charge. I think it would be ideal if the steering commitee got together as a group and decided on a future roadmap. If the idea of leveraging the Blende community lies within that roadmap, then I would draw a proposal for a Blender integration pipeline and present it to the community. I can't speak for anyone there, but I do think if you were to show that you are sincere in your attempt to bridge the two softwares, you'd be well received. I would think about doing myself except as I said at the beginning of the post, I very rarely talk to people. Not to mention that I think it would be better if it were coming from an "official" representative of Torque.
In closing, I'd just like to add my own personal thoughts on the engine. I whole heartedly believe that Torque as an engine is great. I think that in the right hands, stock Torque could do things that would make people question whether its Torque or not. If we focus more on the usuability right now and try and lighten the perception of a programmer's engine, and focus more on the artists side, with things such as nodal logic we could get a lot more people to use the engine. I think that's why Unity took off the way it did. As I said at the beginning of the post, I don't consider myself a developer so everything written here is just my own personal opinion and is probably very wrong in many instances. I'd also like to apologize for my long-windedness. Please feel free to correct me where I'm wrong.
I grew up in the days of 4bit graphics on the Atari 2600 transitioning over to 8bit NES and so on. I got my first PC when I was in high school, almost 25 years ago. Ever since I discovered the possibilities of the computer, I've been fascinated with learning everything I could, including a desire to make games. I have been an avid user and supported of open source software for over a decade. That's what in turn led me to this community when Torque went MIT.
I have noticed a lot of talk lately about the future of Torque. People saying Torque can't compete with what's out there, and needs features, features, features. I've seen that some people are afraid that since Torque is now open source it will fade away because open source projects rarely succeed. I've seen the community fractured in places, and some people leave, while others just remain silent. I've seen a lot in this community in the short time I've been here. Having said that, I am no stranger to these things as I have seen many open source communities go through these same struggles. In way, I guess one could call it growing pains. As I said, I have been around open source software for well over a decade and was there when Blender was initially released as an open source project. And if anyone were to visit blenderartists or some of the other blender forums, they would probably find a lot of similarities to this community with one notable exception... size. Because this community is so much smaller, things that might be par for the course in larger forums automatically sticks out like a sore thumb here and gets noticed more. Case in point, if you go to blenderartists, you will probably find way too many threads started for feature requests, or other threads talking about how blender's UI sucks or this or that. What sets that community apart is that Blender is techinically a success in the open source community.
I don't think Torque MIT has truly had enough time yet to gain traction to be the success that Blender has become. And I think that might be why so many people are wary of its future. But we have to remember, Blender has been at this a lot longer and had to take some big strides to get noticed. And that brings me to my next point. Development. As I said before, I don't consider myself a developer, so take anything I say with a grain of salt, and feel free to correct me if I am wrong in any of my assumptions. I think that in order to get Torque up a level playing field with Blender as an open source project, there are certain things that need to happen. First and foremost, we need to grow the community. The problem is, how to do it? Depending on who you ask you'll get a different answer, and this is mine. Although it is only an opinion, I think what would help grow the Torque community is a closer relationship with Blender. Don't take that the wrong way, I don't mean the Blender Foundation, but rather the Blender community. If Torque can leverage the size of the Blender community and start getting people to adopt Torque as their engine of choice, then the user base could grow exponentially. I think this is why Valve and Epic have started to develop a closer working relationship with the Foundation because they see the huge potential that Blender has for the indie community, and let's face it, isn't that who Torque should be geared towards?
So how could we get that leverage then? I've been thinking about this too. I spend as much time at the blenderartists forums as I do here, I observe a lot of the converstaions that happen in the threads, the BGE threads in particular. I've seen a lot of the same conversations take place in there, as to why people use BGE.
1.) It's built into the editor. I have seen so many people use that as a primary reason, because they don't have to export their assets. I think Torque is already on its way to dealing with the import issue. If Assimp gets fully integrated into Torque for the importing of meshes before caching them out to DSTs it would help tremendously especially since Assimp reads blend files. I don't know how well that would work with animated meshes, but its a start.
2.)Python. Many of the BGE users use it because they can script in python. One user compared it to programmer's crack because it was so addictive. Personally, I am not the biggest fan of python, but to each their own. I do think if we had access to other scripting languages besides TorqueScript it would at the very least tempt more users to try it out. I believe that there was some talk on getting other scripting languages implemented, but I don't know if its still an ongoing thing.
3.)Linux support. Many Blender users are very picky about their operating systems and refuse to use Microsoft prodcuts at all, which completely cancels out DirectX. Once the the Linux and OpenGL ports of Torque is completed, I think that in itself will add to the adoption rate.
These are just a few things that could be done to help integrate some people over to using Torque. But by itself, it isn't nearly enough. I said before that Blender had to take some major strides to be noticed. One thing it did to really set itself apart from other open source projects was when it produced the open film projects. Starting with Elephant's Dream, the Blender Foundation started using Blender in a production environment and developing tools as it went. That was actually a very good decision, not only for publicity, but it allowed the developers to focus on areas that were lacking in the current toolset and target those areas specifically. To apply this to Torque, I think what would work is a community developed game. Although I've never actually played it, I heard that Tribes was a very good game and the backbone of what Torque is known for. If the community could come together and develop something similar, developing the tools as they go, then the end product would be good for marketing but also serve to further engine development. I think spilitting the focus for this project would be what's best however. I know some people would want those tools to be focused on graphics but I don't think that would be best. I think for the initial development it should primarily be focused on usability. I also think if every step of the production was documented, whether through text or visually like a developer's diary so that others can see how things are done. I think it could actually help get more people involved in the development phase if they know how things are working. And example might be just making a basic asset and importing it into the engine and getting it set up. Or using various modular assets in conjunction with each other to flesh out a level. If it's simple enough that a caveman can do it, then people might actually start coming in from other communities to help.
As for the graphics side of things, I do agree that to remain relevant the graphics are going to need to be upgraded at some point. That's just the simple truth of technology. But I think that would work better as a tech demo. Think Samaritan or Infiltrator. Those were realtime demos, but they weren't games. I think if we had just a 3 or 4 minute demo showcasing what Torque was capable of as part of an upgrade that would have mass market appeal. Again though, it would have to be a community driven effort.
All of these things are well and good, but the question remains, where do we start? Honestly, all I can say is what I would do if I were the one in charge. I think it would be ideal if the steering commitee got together as a group and decided on a future roadmap. If the idea of leveraging the Blende community lies within that roadmap, then I would draw a proposal for a Blender integration pipeline and present it to the community. I can't speak for anyone there, but I do think if you were to show that you are sincere in your attempt to bridge the two softwares, you'd be well received. I would think about doing myself except as I said at the beginning of the post, I very rarely talk to people. Not to mention that I think it would be better if it were coming from an "official" representative of Torque.
In closing, I'd just like to add my own personal thoughts on the engine. I whole heartedly believe that Torque as an engine is great. I think that in the right hands, stock Torque could do things that would make people question whether its Torque or not. If we focus more on the usuability right now and try and lighten the perception of a programmer's engine, and focus more on the artists side, with things such as nodal logic we could get a lot more people to use the engine. I think that's why Unity took off the way it did. As I said at the beginning of the post, I don't consider myself a developer so everything written here is just my own personal opinion and is probably very wrong in many instances. I'd also like to apologize for my long-windedness. Please feel free to correct me where I'm wrong.
#2
I completely agree with you, the only reason I didn't add anything about finished titles was because it felt like putting the cart before the horse.
06/08/2014 (6:26 pm)
@KoryI completely agree with you, the only reason I didn't add anything about finished titles was because it felt like putting the cart before the horse.
#3
People have previously suggested having projects like the open movies... unfortunately there doesn't seem to be the genuine support for that beyond the initial suggestion. It'd be wonderful, but I don't think a community this size can sustain a project like that yet. We'll see...
06/09/2014 (5:02 am)
Kenny, I think 'targeting' the Blender community is an excellent idea. The two projects are similar in a lot of ways, and would really complement each other well. This Assimp work is just the start of that. When 3.6 hits, the committee will be doing some marketing/outreach work and we'll make sure to send some love in that direction.People have previously suggested having projects like the open movies... unfortunately there doesn't seem to be the genuine support for that beyond the initial suggestion. It'd be wonderful, but I don't think a community this size can sustain a project like that yet. We'll see...
#4
I agree that the community's size would be something of a hindrance to any open project. That was part of my thinking in reaching out to the blender community. Getting new users is never an easy thing, but each new user we reach could potentially become another developer. If we can find a project that would interest enough people in the blender community, it could have real benefits.
I think what I would do is to probably approach it like this. We break it down into two overlapping goals. We tell the blender community that we are trying to integrate the engine to work more closely with blender, and the announcement of an open source game project to help facilitate that integration. We could then ask the blender community to get involved by making assets and importing them to help with the game. We could ask them to document any problems they might encounter as kind of a QA on the integration. This way we can stay up to date with any potential bugs and whatnot. The more eyes we have looking at the software the more likely we are to find problems that might have been overlooked. This is also one of the reasons why I mentioned getting the python scripting in torque because a lot of the blender community might be more willing to jump on the project if they were scripting in a language that they were already familiar with. The only thing we would probably need is documentation on the list of functions available for scripting. I believe the documentation already exists for TorqueScript, so the only thing we'd need would be python examples.
I would not expect to get a lot of participation all at once. This would basically just be to start a spark of sorts. If we could get even a few people from the community working on this, I think once the project gets going and there's more to show in the form of screenshots and videos, I think people would be more willing to join. That's the nature of open source, people come, people go, I just think they'd be more likely to stay if we found a way to make their path to integration a little easier. Like you said, right now the Torque community is not at a size that it would be feasible to do an open project like this, but if we can get some outside help, even for just the asset side of things, it would be a good thing.
As I said in my first post, I don't consider myself a developer and have nothing to my name to show, so in all likelyhood a lot of my assumptions are wrong. But as an artist, I do see the great potential that Torque holds and would love to see it become the "de facto" standard of open source engines. Right now, I don't have the hardware to really do much in the way of development or even art assets so I wouldn't be much help towards a project like this, but I could try and work up a design doc, or at least the start of one. If you think it would help just let me know.
06/09/2014 (9:13 am)
@DanielI agree that the community's size would be something of a hindrance to any open project. That was part of my thinking in reaching out to the blender community. Getting new users is never an easy thing, but each new user we reach could potentially become another developer. If we can find a project that would interest enough people in the blender community, it could have real benefits.
I think what I would do is to probably approach it like this. We break it down into two overlapping goals. We tell the blender community that we are trying to integrate the engine to work more closely with blender, and the announcement of an open source game project to help facilitate that integration. We could then ask the blender community to get involved by making assets and importing them to help with the game. We could ask them to document any problems they might encounter as kind of a QA on the integration. This way we can stay up to date with any potential bugs and whatnot. The more eyes we have looking at the software the more likely we are to find problems that might have been overlooked. This is also one of the reasons why I mentioned getting the python scripting in torque because a lot of the blender community might be more willing to jump on the project if they were scripting in a language that they were already familiar with. The only thing we would probably need is documentation on the list of functions available for scripting. I believe the documentation already exists for TorqueScript, so the only thing we'd need would be python examples.
I would not expect to get a lot of participation all at once. This would basically just be to start a spark of sorts. If we could get even a few people from the community working on this, I think once the project gets going and there's more to show in the form of screenshots and videos, I think people would be more willing to join. That's the nature of open source, people come, people go, I just think they'd be more likely to stay if we found a way to make their path to integration a little easier. Like you said, right now the Torque community is not at a size that it would be feasible to do an open project like this, but if we can get some outside help, even for just the asset side of things, it would be a good thing.
As I said in my first post, I don't consider myself a developer and have nothing to my name to show, so in all likelyhood a lot of my assumptions are wrong. But as an artist, I do see the great potential that Torque holds and would love to see it become the "de facto" standard of open source engines. Right now, I don't have the hardware to really do much in the way of development or even art assets so I wouldn't be much help towards a project like this, but I could try and work up a design doc, or at least the start of one. If you think it would help just let me know.
#6
I thought I'd remembered something about a few different implementations for integrating different scripting languages. I can understand why it would be such a hot topic too. In an ideal world it would be nice to have "one language to rule them all". Unfortunately, people are sometimes picky about their scripting language of choice, and understandably so. I don't think it would necessarily be a bad thing to support multiple languages, but once you start, the question is where do you stop? Every time a new language comes out, you'll end up getting feature requests for adding in said language. Personally, I think adding just the most used ones would probably be sufficient. Leave in TorqueScript and add maybe Python, Lua, and possibly Java or C#. Even adding in some sort of visual scripting ability would probably help. I don't know if that's what the component system that's being developed would address, but I do think it would help. Honestly, all I'm doing right now is brainstorming out loud and looking for feedback for ways to expand the Torque community. I really feel that if we can address a few things as far as usability goes, we can grow the user base, which might end up adding more in terms of development later on.
06/09/2014 (5:12 pm)
@LukasI thought I'd remembered something about a few different implementations for integrating different scripting languages. I can understand why it would be such a hot topic too. In an ideal world it would be nice to have "one language to rule them all". Unfortunately, people are sometimes picky about their scripting language of choice, and understandably so. I don't think it would necessarily be a bad thing to support multiple languages, but once you start, the question is where do you stop? Every time a new language comes out, you'll end up getting feature requests for adding in said language. Personally, I think adding just the most used ones would probably be sufficient. Leave in TorqueScript and add maybe Python, Lua, and possibly Java or C#. Even adding in some sort of visual scripting ability would probably help. I don't know if that's what the component system that's being developed would address, but I do think it would help. Honestly, all I'm doing right now is brainstorming out loud and looking for feedback for ways to expand the Torque community. I really feel that if we can address a few things as far as usability goes, we can grow the user base, which might end up adding more in terms of development later on.
#7
06/09/2014 (5:14 pm)
I plan on integrating lua 5.2? (current version, forget :P) into my Torque3D project and eventually giving it back to the community via github. For me it's a matter of finding time and willpower to do it :P
#8
That's great to hear. Time shouldn't be too much of an issue, this is done on a voluntary basis. Slow and steady wins the race after all. Willpower, however, that's a whole different story... lol
06/09/2014 (5:25 pm)
@JeffThat's great to hear. Time shouldn't be too much of an issue, this is done on a voluntary basis. Slow and steady wins the race after all. Willpower, however, that's a whole different story... lol
#9
For anyone interested, there seems to be some conversation starting up over at blenderartists about ditching the BGE and integrating an external engine, which would make it the perfect time for joining communities.
http://blenderartists.org/forum/showthread.php?339550-Uncertain-the-future-is
Here's a relevant post from one of the BGE developers
http://blenderartists.org/forum/showthread.php?297023-Future-of-the-BGE&p=2664290&viewfull=1#post2664290
06/09/2014 (6:46 pm)
@allFor anyone interested, there seems to be some conversation starting up over at blenderartists about ditching the BGE and integrating an external engine, which would make it the perfect time for joining communities.
http://blenderartists.org/forum/showthread.php?339550-Uncertain-the-future-is
Here's a relevant post from one of the BGE developers
http://blenderartists.org/forum/showthread.php?297023-Future-of-the-BGE&p=2664290&viewfull=1#post2664290
#10
06/10/2014 (4:34 pm)
Thanks for those Kenneth - I might see about dropping in on the discussion. Random thought for everyone. Since we all seem to like node-based editors so much, could we write an exporter for Blender's logic editor? Same with its shader node graph? And could we leverage Torque's auto-reload functionality so that we can essentially let you edit these things in Blender while running the engine, and see the changes in realtime?
#11
I think it'd be a great idea to add some of that export functionality. If I remember correctly, I think there was a project called gamekit that used Ogre as its rendering back-end and it imported blender files directly. If I'm not mistaken, I believe the logic bricks were also imported and converted into the engines internal logic system. You'd probably have to check that out to verify.
http://code.google.com/p/gamekit/
As for the shader node graph, I believe there is some work being done on the GSOC for updating the viewport rendering system which should also affect the BGE making shader writing more uniform across the whole of Blender. If that's the case, it might be possible to export at least glsl shaders from Blender and import them for use into Torque. It might not help much on the DirectX side, but it would be a start at least.
As far as the auto-reload functionality, if that could get worked out, I think that would probably make a lot people happy, as it would somewhat the whole "press p to play your game" syndrome that BGE users seem to have. It would also help in speeding up the workflow somewhat.
06/10/2014 (6:06 pm)
@DanielI think it'd be a great idea to add some of that export functionality. If I remember correctly, I think there was a project called gamekit that used Ogre as its rendering back-end and it imported blender files directly. If I'm not mistaken, I believe the logic bricks were also imported and converted into the engines internal logic system. You'd probably have to check that out to verify.
http://code.google.com/p/gamekit/
As for the shader node graph, I believe there is some work being done on the GSOC for updating the viewport rendering system which should also affect the BGE making shader writing more uniform across the whole of Blender. If that's the case, it might be possible to export at least glsl shaders from Blender and import them for use into Torque. It might not help much on the DirectX side, but it would be a start at least.
As far as the auto-reload functionality, if that could get worked out, I think that would probably make a lot people happy, as it would somewhat the whole "press p to play your game" syndrome that BGE users seem to have. It would also help in speeding up the workflow somewhat.
#12
06/10/2014 (7:53 pm)
As for the scripting language, I strongly think Lua should be the language. Python is just too slow, but Lua is fast, easy, reliable, and used in many other engines (Leadwerks Engine for example). Python is fine in the long run, but Lua is much better.
#13
I won't argue with you about Lua being the stronger of the languages. That was one of the reasons I added it to the list of possible candidates. I also agree with what you said about Python. The main reason I added it was to ease the transition for Blender users who are primarily familiar with Python through the BGE. Personally, I don't really see a problem with TorqueScript, but the more options we have the better. If we want to be more inclusive to other communities, it might mean adopting some of their pipeline (if that's the right wording).
06/10/2014 (8:13 pm)
@raaI won't argue with you about Lua being the stronger of the languages. That was one of the reasons I added it to the list of possible candidates. I also agree with what you said about Python. The main reason I added it was to ease the transition for Blender users who are primarily familiar with Python through the BGE. Personally, I don't really see a problem with TorqueScript, but the more options we have the better. If we want to be more inclusive to other communities, it might mean adopting some of their pipeline (if that's the right wording).
#14
All in all, though these are all very valid points that are being brought up. Good to see some initiative is being taken again.
06/11/2014 (9:10 am)
I think if you're going to go the LUA route, to ensure you add that JIT compatibility to it to ensure we've got maximum speed out of the scripting engine.All in all, though these are all very valid points that are being brought up. Good to see some initiative is being taken again.
#15
Thanks for the feedback. I completely agree that whatever course we take, we need to take speed into consideration. It would be kind of backwards to add all of this new functionality if we sacrifice speed to get it.
On a side note, I've been thinking about something else, but I'm not sure how feasible it is, so maybe someone more educated than I am can answer this. UDK has Matinee, Cryengine has TrackView, Source has, I believe, FilmMaker. In short, most, if not all of the big AAA engines have some form of a dedicated cinematics tool for creating cutscenes. I know that we have Verve and GMK that could be put to use, but I'm not sure if either of these tools would be considered complete enough to warrant that level of use. Would it be possible to use Blender's scene and animation systems to create cinematic cutscenes for in-game use?
I'm thinking something like this. We plan out all of the animation for the actors, cameras, lights, whatever, and then just import the whole scene into Torque. the nice thing about doing it this way is that it should be feasible to do special things like baking physics that could then be played back in engine. Of course, I don't think all of Blender's internal animation could be translated to Torque, like the particle system. Particles would be something that would still have to be done in engine. But if we can do most of the heavy lifting in Blender, and then add some empties to dictate particle placement, we could then use Verve or GMK to to fill in the engine specific stuff. I think it might be better than a total rewrite of either package to get it up to par with what else is out there.
One other benefit of doing something like this, is that I believe you'd be able to get a whole different crowd coming into the engine. It wouldn't just be game developers using it at the point, you'd probably have artists using the engine just to create Machinima, especially once the PBR system is in place. I've actually seen quite a few people looking for a way to do realtime rendering of animations, so this might pique their interest as well.
06/11/2014 (11:26 am)
@RobertThanks for the feedback. I completely agree that whatever course we take, we need to take speed into consideration. It would be kind of backwards to add all of this new functionality if we sacrifice speed to get it.
On a side note, I've been thinking about something else, but I'm not sure how feasible it is, so maybe someone more educated than I am can answer this. UDK has Matinee, Cryengine has TrackView, Source has, I believe, FilmMaker. In short, most, if not all of the big AAA engines have some form of a dedicated cinematics tool for creating cutscenes. I know that we have Verve and GMK that could be put to use, but I'm not sure if either of these tools would be considered complete enough to warrant that level of use. Would it be possible to use Blender's scene and animation systems to create cinematic cutscenes for in-game use?
I'm thinking something like this. We plan out all of the animation for the actors, cameras, lights, whatever, and then just import the whole scene into Torque. the nice thing about doing it this way is that it should be feasible to do special things like baking physics that could then be played back in engine. Of course, I don't think all of Blender's internal animation could be translated to Torque, like the particle system. Particles would be something that would still have to be done in engine. But if we can do most of the heavy lifting in Blender, and then add some empties to dictate particle placement, we could then use Verve or GMK to to fill in the engine specific stuff. I think it might be better than a total rewrite of either package to get it up to par with what else is out there.
One other benefit of doing something like this, is that I believe you'd be able to get a whole different crowd coming into the engine. It wouldn't just be game developers using it at the point, you'd probably have artists using the engine just to create Machinima, especially once the PBR system is in place. I've actually seen quite a few people looking for a way to do realtime rendering of animations, so this might pique their interest as well.
#16
This was prompted in part by the discussion around T2D's editors after it went MIT. I'm kind of in favour of using external applications suited to speficif purposes. Blender's suited to 3D modelling and manipulation, so it seems like it'd be a good level editor candidate.
06/11/2014 (9:13 pm)
I have been interested for some time in setting up a full-scene Blender importer, in the interest of making a minimal T3D distribution that doesn't include the massive script templates and editors. I was planning on designing entire levels in Blender and using some sort of Python script to export them to .mis files, replacing different sorts of entities with their appropriate object types and so on.This was prompted in part by the discussion around T2D's editors after it went MIT. I'm kind of in favour of using external applications suited to speficif purposes. Blender's suited to 3D modelling and manipulation, so it seems like it'd be a good level editor candidate.
#17
I'm in complete agreement with you. I think it would be best if we could used applications that are specifically targeted to certain areas of the pipeline. Doing so cuts down on any excess bloat in T3D. This also works out with the limited resources we currently have for T3D by allowing the owners of these targeted applications to keep the software updated and feature rich while we primarily focus on the integration pipeline. I think you're right about Blender being a good candidate as a level editor as well. I've seen threads all over the internet of people using Blender specifically for that purpose targeting various engines. So adding T3D to the mix wouldn't exactly be out of character for the Blender community. Getting some kind of export to .mis script set up would help ease that transition as well. After all, Blender just added the new functionality to explore your levels in the viewport just like you would in any other level editor, we might as well make use of it.
06/11/2014 (9:51 pm)
@DanielI'm in complete agreement with you. I think it would be best if we could used applications that are specifically targeted to certain areas of the pipeline. Doing so cuts down on any excess bloat in T3D. This also works out with the limited resources we currently have for T3D by allowing the owners of these targeted applications to keep the software updated and feature rich while we primarily focus on the integration pipeline. I think you're right about Blender being a good candidate as a level editor as well. I've seen threads all over the internet of people using Blender specifically for that purpose targeting various engines. So adding T3D to the mix wouldn't exactly be out of character for the Blender community. Getting some kind of export to .mis script set up would help ease that transition as well. After all, Blender just added the new functionality to explore your levels in the viewport just like you would in any other level editor, we might as well make use of it.
#18
06/11/2014 (10:41 pm)
Of course, you do lose the ability to play-as-you-edit, which is a shame. Hopefully the integration pipeline could be made smooth enough that you could save your level in Blender and see changes appear instantly in Torque. That's a good ideal.
#19
I think that goes back in to what you were saying with leveraging Torque's auto-reload functionality. The Blender side would probably be just straight level editing, using the walkthrough feature to test dimensions of assets and such, and then if any changes are made, then a script can be sent to Torque to update said changes while the game mechanics stay the same in the engine. If it's truly an instantaneous type of update, that kind of feeds right back into the "press p to play" scenario that I was talking about earlier. As a bonus, if there's a way to integrate Blender's nodal logic system like you mentioned, then the same updates would also apply to the in game mechanics within Torque. Just a thought.
06/11/2014 (10:50 pm)
@DanielI think that goes back in to what you were saying with leveraging Torque's auto-reload functionality. The Blender side would probably be just straight level editing, using the walkthrough feature to test dimensions of assets and such, and then if any changes are made, then a script can be sent to Torque to update said changes while the game mechanics stay the same in the engine. If it's truly an instantaneous type of update, that kind of feeds right back into the "press p to play" scenario that I was talking about earlier. As a bonus, if there's a way to integrate Blender's nodal logic system like you mentioned, then the same updates would also apply to the in game mechanics within Torque. Just a thought.
#20
A lot of talk about the Blender Game Engine. You get a good sense in the comments about an external game engine is needed. I think both communities would benefit from each other.
06/15/2014 (7:14 am)
Here is a good BLOG to read "Blender roadmap - 2.7, 2.8 and beyond"A lot of talk about the Blender Game Engine. You get a good sense in the comments about an external game engine is needed. I think both communities would benefit from each other.
Torque Owner Kory Imaginism
innovative imaginations
Some great point's made! Let me add finished titles..A good amount of finished title and how to tutorials can go along way.
Once some of the other ports get finished up and rolled into the main build then I'm sure some neat things will happen but first things first!