Open Call: Join the Torque 3D Steering Committee
by Dave Wyand · 06/06/2013 (9:57 am) · 57 comments
Open Call: Join the Torque 3D Steering Committee
Back on September 20, 2012, we launched the MIT licensed version of Torque 3D on GitHub. During this time we set up a Steering Committee made of GarageGames members to organize the launch logistics.Pre-Launch Steering Committee (SC-0)
- Scott Burns
- David Montgomery-Blake
- Eric Preisz
- David Wyand
First Community-Based Steering Committee
On October 24, 2012, we announced the first community-based Steering Committee based on the submissions we received.1st Steering Committee (SC-1)
- Michael Hall
- Ron Kapaun
- David Wyand
Michael and Ron are both longtime members of the community and were obvious choices to be a part of the Committee. Over the last 8 months this Steering Committee has created the roadmap for three versions of T3D, launched two new releases (v2.0 and v3.0), and created four demos that show off new technology in Torque 3D. A lot of work and even crunch-time occurred during this period. Both Michael and Ron went beyond what was required of them as community volunteers.
At the beginning of June, 2013, Ron decided to step down from the Steering Committee. We will miss his guidance and expertise. I would like to personally thank him for all of the hard work he has put in and wish him well in the future.
Second Steering Committee
This brings us to a new chapter in the life of Torque 3D. Starting today until June 30, 2013, we are again accepting requests to join the T3D Steering Committee. We are hoping to find two new people this time around, bringing the total number of Committee members to four.We’re not only looking for the most active community members, or those that have been with the community the longest. If you’ve been lurking and believe that now is the time you want to get involved, that’s great! We would also like to hear from people outside of our community that feel they can contribute.
For those that are wondering what the Committee’s role and responsibilities are we have a Charter that is available here: github.com/GarageGames/Torque3D/wiki/Steering-Committee-Charter. This is a living document and may change over time as the Committee sees fit.
Torque 3D Steering Committee Charter
1. Vision
We are dedicated to making the best core version of Torque 3D so that others can build upon a reliable foundation.
2. Mission
To build a foundation for a sustainable environment that fosters collaboration and community development of the greatest open source development platform.
3. Goals
- To maintain the best master branch version of Torque 3D. Performance, reliability, maintainability and scalability.
- Act as a representative on behalf of the collective community.
- Actively communicate in a transparent manner.
- Promote Torque 3D as an open source project.
4. Duties and Responsibilities
- Maintain, enhance and support the Torque 3D open source product.
- Operates under ethical and professional standards with individuals, community, and the world.
- Create and revise the product’s roadmap.
- Review and act appropriately on all community submitted action items.
- Encourage growth of the Torque 3D product through community participation.
- To ensure that all contributions are free from intellectual property encumbrances in order to maintain the integrity of the product.
- Act in a professional manner and lead by example.
- Periodically review the charter and composition of the membership and make changes as necessary.
5. Membership
Members of the steering committee must be willing and able to commit time and energy to fulfilling the committee’s mission. At least one (1) one of the committee members must come from GarageGames LLC or its representative, and shall act as chair of the committee. The remainder of the membership may grow as appropriate according to the committee’s duties, but the total committee size shall remain at or below six members.
To be considered as a member of the committee, the prospective member should meet the following criteria:
- Is available for at least 8 to 20 hours a week of work on the Torque 3D open source product such as programming, documentation, administration, etc.
- Have expert knowledge in game engine and tool development, such as documentation, C++ engine programming, operating system platform programming, etc.
- Agree to the Open Source Software Agreement available on the GarageGames web site.
If a member is unable to serve on the committee for any reason, the vacancy may be filled or left empty at the discretion of the committee. If the committee as a whole is unable to perform its duties, an employee of GarageGames LLC or its representative may step in and provide the course of action.
In addition to the steering committee, we desire two other essential members: project manager and secretary. These roles are not decision making positions; rather, they document, format, and deliver information to the community.
6. Meetings
The chair of the committee is responsible for organizing formal meetings, which should be held at least once a month. During these meetings the progress of the previous month shall be reviewed and goals shall be set for at least the next month. More frequent meetings may be held as required.
All meeting minutes shall be published to the community by the secretary, or another committee member if required. These minutes must be published to the GarageGames web site, along with any other location as determined by the committee.
7. Voting
Each member of the committee has one vote. Any decision by the committee that requires a vote must have a two-thirds majority to pass. The chair of the committee has veto power over any vote, if required.
8. Removal
If a committee member commits the following acts, they could be removed from the committee:
- Unable to fulfill their time requirements.
- Removed by a majority vote for no longer aligning with sections 3 and 4 above.
9. Amendments
This charter is a living document and may be amended by the committee as outlined in section 4. Any amendments require the approval of the committee chair.
Join the Torque 3D Steering Committee
Does being a part of the Torque 3D open source Steering Committee interest you? Are you ready to be a leader and organizer in the community? Have you read through the charter and have a feeling of awesomeness swelling inside? If so, then please get in touch by email at davew@garagegames.com and let me know by June 30, 2013. We want to hear from you!- Dave
About the author
Producer at GarageGames LLC
#42
06/17/2013 (4:41 pm)
The problem with the lightmapping (or tone mapping as you call it is that) it is difficult to use and undocumented. I asked multiple people how it actually worked...nobody could tell me. There's no documentation, there are no tutorials. So I gave up. Also, the Purelight workflow takes so much extra time it's basically worthless. If I wanted anything approaching GI (which is a must have in my book for any modern game) I'd have to go through so many hoops to get it in Torque it would vastly extend my iteration time. UDK I just press the button and go have a coffee. 
#43
@Ron: Because for some reason people find separate tools like guile[s] "easier" to do the baking in.. Same reason someone would use purelight. That's not my opinion either, I'm the kick the artist in the butt for being lazy type as well. ;)
@Dashiva: No one, and I mean NO ONE is actually doing anything even approaching realtime GI, it's all a gross approximation at this point. Some look good enough, but no where near accurate. Not yet anyway, not in a released game. I know you didn't say realtime, I'm just making the distinction here. Last I checked UDK was prebaked either way. Others are precalculated. So ingame, modelling program, purelight, whatever, there are many options. As for a "requirement" Honestly, does it really do that much for games for you that it needs to be a requirement??
06/17/2013 (6:52 pm)
@Duion what Ron said.. It's true@Ron: Because for some reason people find separate tools like guile[s] "easier" to do the baking in.. Same reason someone would use purelight. That's not my opinion either, I'm the kick the artist in the butt for being lazy type as well. ;)
@Dashiva: No one, and I mean NO ONE is actually doing anything even approaching realtime GI, it's all a gross approximation at this point. Some look good enough, but no where near accurate. Not yet anyway, not in a released game. I know you didn't say realtime, I'm just making the distinction here. Last I checked UDK was prebaked either way. Others are precalculated. So ingame, modelling program, purelight, whatever, there are many options. As for a "requirement" Honestly, does it really do that much for games for you that it needs to be a requirement??
#44
Honestly though, if your game is HINGING on GI or some other silly ass graphic feature, then either add it to the engine or move on to an engine you want to take the time to understand. GI is a 'nice' idea. It's not a game freakin game breaker. Some of the best games I have played over the years did not have the greatest graphics in the world. They did have the BEST game play systems. I LOVE the original StarCraft and that has straight up crap for graphics. Same goes for Age of Empires II and the list can go on and on.
Simple fact: You DO NOT HAVE millions of dollars to spend on R&D. You are an indie dev. Yes, you can dev in CryEngine, or Unreal... Good luck publishing with it. Most of us can NOT afford a single seat for something like that. (Trust me, I was quoted 250K$ for 1 seat for 1 title for CryEngine 3 just a couple of months ago).
T3D may not be a total answer but, it is MORE than capable if you want to take the time to learn some of it's secrets.
Look, I know this comes off as a little bit harsh. However, in reality, graphics get a game noticed but, game play keeps people playing, and you want people playing... not admiring the JUST the art. The sooner developers understand that, the better.
Last I am going to say on the subject.
Ron
06/17/2013 (7:07 pm)
Ok, last post on this subject... well until it comes up again :-). I agree, a separate tool would be 'nice'. I may dig into it and see what it takes to create a tool to do it natively.Honestly though, if your game is HINGING on GI or some other silly ass graphic feature, then either add it to the engine or move on to an engine you want to take the time to understand. GI is a 'nice' idea. It's not a game freakin game breaker. Some of the best games I have played over the years did not have the greatest graphics in the world. They did have the BEST game play systems. I LOVE the original StarCraft and that has straight up crap for graphics. Same goes for Age of Empires II and the list can go on and on.
Simple fact: You DO NOT HAVE millions of dollars to spend on R&D. You are an indie dev. Yes, you can dev in CryEngine, or Unreal... Good luck publishing with it. Most of us can NOT afford a single seat for something like that. (Trust me, I was quoted 250K$ for 1 seat for 1 title for CryEngine 3 just a couple of months ago).
T3D may not be a total answer but, it is MORE than capable if you want to take the time to learn some of it's secrets.
Look, I know this comes off as a little bit harsh. However, in reality, graphics get a game noticed but, game play keeps people playing, and you want people playing... not admiring the JUST the art. The sooner developers understand that, the better.
Last I am going to say on the subject.
Ron
#45
Even when mapping for old half-life 1 it worked like this. The difference there was the bouncing of light. For your realtime world, you only could have a direct one time bouncing light, so if your light hits a wall it is gone, so the rest is 100% black again. But then you could bake lightmaps where you could set the bouncing higher, the higher the number of bounces the smoother the lighting got, because he calculated the bouncing of the light from the walls, but you could not have that with active lights.
06/18/2013 (2:17 am)
I have no idea of programming, but I think the illumination works something like this: You set the lighting settings very high and then you render the light, so no real time, you just render the lighting how it would look for one moment in that quality, after that you freeze it and save it into a file after that you can keep this settings and for realtime lights, you switch back to simpler lights for the active lights.Even when mapping for old half-life 1 it worked like this. The difference there was the bouncing of light. For your realtime world, you only could have a direct one time bouncing light, so if your light hits a wall it is gone, so the rest is 100% black again. But then you could bake lightmaps where you could set the bouncing higher, the higher the number of bounces the smoother the lighting got, because he calculated the bouncing of the light from the walls, but you could not have that with active lights.
#46
is the answer actually its the thing most ppl have waited on
i mean look at it, it has evrything you would really need to make a great game
when i read stuff like....
I keep looking at Torque every couple of weeks just to see what's going on because I would love to be able to use it for a project.
? why just keep looking
why not actually starting something
look @ Duion who already made some progress with T3D
and he for example knows what stuff t3d is missing but
still that won`t prevent him from working with T3D
(@Duion, excuse me for takin you as example but you do kinda fit :P )
and the subject of baking lightmaps
lets be honest - if your game is ment to be a old school
game or a game with not so special hardware requirements
then lightmaps are usefull
but as soon as you decide to go the dynamic way of things
- thats where baked lightmaps endup useless
note: this is my pov
with all that being said
how about goign back to the subject
and that is simple
Open Call - Join the T3D Steering Commitee
06/18/2013 (4:55 am)
T3D MITis the answer actually its the thing most ppl have waited on
i mean look at it, it has evrything you would really need to make a great game
when i read stuff like....
I keep looking at Torque every couple of weeks just to see what's going on because I would love to be able to use it for a project.
? why just keep looking
why not actually starting something
look @ Duion who already made some progress with T3D
and he for example knows what stuff t3d is missing but
still that won`t prevent him from working with T3D
(@Duion, excuse me for takin you as example but you do kinda fit :P )
and the subject of baking lightmaps
lets be honest - if your game is ment to be a old school
game or a game with not so special hardware requirements
then lightmaps are usefull
but as soon as you decide to go the dynamic way of things
- thats where baked lightmaps endup useless
note: this is my pov
with all that being said
how about goign back to the subject
and that is simple
Open Call - Join the T3D Steering Commitee
#47
So I would not call this an essential feature, but a very nice option.
06/18/2013 (6:59 am)
Yes, maybe today you could switch to full realtime advanced lighting, but this costs a lot of performance, if I just turn off advanced lighting, I have about triple the performance than with.So I would not call this an essential feature, but a very nice option.
#48
http://web.cs.wpi.edu/~emmanuel/courses/cs563/S12/slides/cs563_emmanuel_gi_wk5.pdf
Note that it uses Torque3d as an example of old technology. I would put Torque3d's rendering around 2004's Source Engine (which still has better lighting). I think there's an attitude in the community that is sort of 'our way or the highway' that I run into every time I ask for a relatively modern feature. There's a reason why nobody takes Torque seriously in the game art community. Hopefully you can hire someone on the steering committee to help change this.
06/20/2013 (5:01 pm)
GI is a dealbreaker for me and a lot of other artists. The reason why is that I would much rather look at a scene with GI than one without it. Doesn't matter if it's baked or realtime. This is a good example of why it looks so much better:http://web.cs.wpi.edu/~emmanuel/courses/cs563/S12/slides/cs563_emmanuel_gi_wk5.pdf
Note that it uses Torque3d as an example of old technology. I would put Torque3d's rendering around 2004's Source Engine (which still has better lighting). I think there's an attitude in the community that is sort of 'our way or the highway' that I run into every time I ask for a relatively modern feature. There's a reason why nobody takes Torque seriously in the game art community. Hopefully you can hire someone on the steering committee to help change this.
#49
^^
Dashiva
i know you at least your person as in your background
comin from the wolf et scene
and playin with et-xreal
and so on and on
.... i don`t need to ask why you haven`t been able to accomplish somethin with et-xreal
as we all know how it ended up with the xreal tech part of things
as i was foolin around with xreal before
(why even bring that up? no idea was a must kinda ;) )
now there is no our way or highway thing here
especially when ppl like Ron show
how stuff can still be accomplished
and if you point at my person well
i usually seperate my oppinion
with a - it`s my pov
as in my point of view regarding the stuff
However this discussion is already moving towards nomans land
and yes i hope too that the steering commitee can find someone
to bring the engine to new heights
however
lets lookt at this way
there are for example
mode7games who are working with T3D tech
and there is no sign of them - when it comes to the community
(yaa i know MangoFusion hangs in irc but thats all)
next beamNG
who just recentlly went T3D
are integrating their physics Engine in their T3D fork
and there are plenty more that could be named
that aren`t haven`t
yet contributed to the OpenSrc cause of T3D
However it doesn`t have to stay/be that way
especially considering the fact that even if T3D is actually old
it is pretty yound when it comes to OpenSrc
so ye there is room to fill
who will fill it what will the future bring
who knows
but 1 thing is sure T3D will move on either way
now am done with my novel
06/20/2013 (7:59 pm)
aye time to let teh rat out of teh sack^^
Dashiva
i know you at least your person as in your background
comin from the wolf et scene
and playin with et-xreal
and so on and on
.... i don`t need to ask why you haven`t been able to accomplish somethin with et-xreal
as we all know how it ended up with the xreal tech part of things
as i was foolin around with xreal before
(why even bring that up? no idea was a must kinda ;) )
now there is no our way or highway thing here
especially when ppl like Ron show
how stuff can still be accomplished
and if you point at my person well
i usually seperate my oppinion
with a - it`s my pov
as in my point of view regarding the stuff
However this discussion is already moving towards nomans land
and yes i hope too that the steering commitee can find someone
to bring the engine to new heights
however
lets lookt at this way
there are for example
mode7games who are working with T3D tech
and there is no sign of them - when it comes to the community
(yaa i know MangoFusion hangs in irc but thats all)
next beamNG
who just recentlly went T3D
are integrating their physics Engine in their T3D fork
and there are plenty more that could be named
that aren`t haven`t
yet contributed to the OpenSrc cause of T3D
However it doesn`t have to stay/be that way
especially considering the fact that even if T3D is actually old
it is pretty yound when it comes to OpenSrc
so ye there is room to fill
who will fill it what will the future bring
who knows
but 1 thing is sure T3D will move on either way
now am done with my novel
#50
I believe that screenshot of Torque 3D in that publication was actually from a demo in TGEA not Torque 3D. You can even see TGEA 1.8.1 at the top of window in the screenshot.
06/21/2013 (1:21 am)
@Dashiva I believe that screenshot of Torque 3D in that publication was actually from a demo in TGEA not Torque 3D. You can even see TGEA 1.8.1 at the top of window in the screenshot.
#51
I just wanted to drop by and remind everyone that we don't "hire" people to join the Steering Committee. It isn't a paid job. This is a volunteer position to act as an overseer of the main repository of T3D, among other things. You can read the Committee's charter here.
I also wanted to restate that it is not solely up to the Steering Committee to keep the engine current and bug free. That is on the community as a whole. If there are certain features that are "must haves" there is nothing stopping someone from implementing those features and giving them back to the community. You do not need to be on the Steering Committee to do that.
- Dave
06/21/2013 (7:27 am)
Hey All.I just wanted to drop by and remind everyone that we don't "hire" people to join the Steering Committee. It isn't a paid job. This is a volunteer position to act as an overseer of the main repository of T3D, among other things. You can read the Committee's charter here.
I also wanted to restate that it is not solely up to the Steering Committee to keep the engine current and bug free. That is on the community as a whole. If there are certain features that are "must haves" there is nothing stopping someone from implementing those features and giving them back to the community. You do not need to be on the Steering Committee to do that.
- Dave
#52
06/21/2013 (5:32 pm)
Quote:Note that it uses Torque3d as an example of old technology.Wow, that comparison was terrible. The Crysis shot doesn't even display any actual GI. And the Torque shot doesn't look fake because of the lack of GI :P.
#53
There are more than enough samples and resources in the forums to show you it (T3D not TGEA) is better than that doc eludes to.
My biggest disappointment with anyone is the blind acceptance of negative or outdated information, but keep in mind that (for me) it's just disappointment.
I believe the community here, at no point, want a our way or the highway scenario. Everyone is welcome to interact, ask questions, participate, etc.
06/22/2013 (10:56 pm)
@Dashiva I don't really want to keep this thread pulling into this topic and off the steering committee. So this will be my last post in this area for it. Your comparison, with that document is severely outdated. You should seriously try to look over what T3D can do instead of generalizing it based on a document which was looking at TGEA (different engine). If you need an example, check out any purelight T3D demo, or hell even the south pacific demo, or china town. That should give you a better idea of what's possible, but even those are becoming dated for what the current state is.There are more than enough samples and resources in the forums to show you it (T3D not TGEA) is better than that doc eludes to.
My biggest disappointment with anyone is the blind acceptance of negative or outdated information, but keep in mind that (for me) it's just disappointment.
I believe the community here, at no point, want a our way or the highway scenario. Everyone is welcome to interact, ask questions, participate, etc.
#54
Faking SSAO and bloom and HDR and all of that stuff doesn't amount to having a good GI solver. I can tell you from two solid months of working in Torque that the rendering is extremely deficient. I tried my damndest to make things that, you know, look good. Didn't happen. If you spend hours on your textures and models you want your artistic vision realized, and that's impossible in T3D at the moment. I know of not one serious game artist that uses it. My 'outdated information' is hours spent trying to make stuff that looked good in other engines look decent in Torque.
Also, about Purelight 1) it's 500 bucks and 2) nobody ever could tell me how it worked, or as far as I could tell, had used it themselves. I asked on the forums, I asked on IRC, and *nobody* knew how the hell it worked. I can bake GI lightmaps in Maya and Modo, but nobody knew how tonemaps worked in the engine. So case closed, move on. I just don't have the time any more. So I've said it a million times and I'll say it again: T3D is a programmer's engine. It's not an engine for artists. I keep holding out hope, but I don't think this will ever change.
It is an our way or the highway attitude. I try to suggest reasonable features that almost every other modern game engine has and get told that A) I don't know what I'm talking about (when I most assuredly do) B) get asked "why would you want that anyway?" like I'm asking the impossible. So I am done, TBH. I want so desperately to have a good open source engine to make a decent game on, but I will not find it here.
07/06/2013 (11:38 pm)
It's the same math / theory behind the rendering. I linked to that pdf because it's an actual mathematical description of the problem. Faking SSAO and bloom and HDR and all of that stuff doesn't amount to having a good GI solver. I can tell you from two solid months of working in Torque that the rendering is extremely deficient. I tried my damndest to make things that, you know, look good. Didn't happen. If you spend hours on your textures and models you want your artistic vision realized, and that's impossible in T3D at the moment. I know of not one serious game artist that uses it. My 'outdated information' is hours spent trying to make stuff that looked good in other engines look decent in Torque.
Also, about Purelight 1) it's 500 bucks and 2) nobody ever could tell me how it worked, or as far as I could tell, had used it themselves. I asked on the forums, I asked on IRC, and *nobody* knew how the hell it worked. I can bake GI lightmaps in Maya and Modo, but nobody knew how tonemaps worked in the engine. So case closed, move on. I just don't have the time any more. So I've said it a million times and I'll say it again: T3D is a programmer's engine. It's not an engine for artists. I keep holding out hope, but I don't think this will ever change.
It is an our way or the highway attitude. I try to suggest reasonable features that almost every other modern game engine has and get told that A) I don't know what I'm talking about (when I most assuredly do) B) get asked "why would you want that anyway?" like I'm asking the impossible. So I am done, TBH. I want so desperately to have a good open source engine to make a decent game on, but I will not find it here.
#55
I think the problem is more that it is getting old and we have no opengl and the directX support runs out, not the missing baking lightmaps feature. Baking lightmaps is more for saving performance and having higher quality light than you can have in real time.
07/07/2013 (2:19 am)
There is already a discussion how to bring Torque up to date with a new renderer here: http://www.garagegames.com/community/blog/view/22330/2#commentsI think the problem is more that it is getting old and we have no opengl and the directX support runs out, not the missing baking lightmaps feature. Baking lightmaps is more for saving performance and having higher quality light than you can have in real time.
#56
No, this is NOT a pure 'artist' engine. It's a GAME engine, art is ONLY one small part of a game. Anyway, once again, good luck and I really do hope you find something that works for you.
Ron
07/09/2013 (8:15 pm)
Wow, whatever. If Torque does not meet your needs, then move on to something you are happy with, there are literally dozens of engines out there. It's that simple. No, this is NOT a pure 'artist' engine. It's a GAME engine, art is ONLY one small part of a game. Anyway, once again, good luck and I really do hope you find something that works for you.
Ron
#57
Thanks
Derry
07/14/2013 (8:50 pm)
Is it still possible to join the Steering Committee? I think I might like to join and contribute.Thanks
Derry
Associate Ron Kapaun
3tdstudios.com
I respectfully disagree, since your lighting can be as dynamic as you want and it can effect the lightmap (this is why we have 'include lightmapped' as an option for all light sources). Just saying...
Ron