Programmers
by Very Interactive Person · in Jobs · 09/20/2002 (8:50 am) · 24 replies
I've been looking out for a good engine programmer for about a year now. Still.. no luck. They come and go, but none of the guys I worked with was able to do what we wanted. Here are some things on our list:
-walking vehicles
-different weapon model in 1st/3rd person (with arms attached)
-bumpmapping
-texture lighting
-radiosity
-....
I think the problem is not much people are actually able of implementing these things. We had no trouble finding game programmers... lots of those people around.
Now here are some toughts to get the stuff anyway. let me know what you guys think:
-I'm willing to trade artwork (textures, sky boxes, websites, GUI,...) for one of the above things. I am talking about quality work here... I would defenetly try to make it worth the effort so its a fair deal.
-OR...I'm not the only one who wants these things. So, if there could be a system like rent a coder where there are some jobs available (like implementing bump mapping), but with the diference that everyone can pay, so creating a funding. Lets say 100 people are willing to pay 15$ for bumpmapping, well that's 1500$ a coder could make out of it. In fact, one could make a living out of that. Unfortunately this is almost not possible without some supervising and good organization. Another thing is people who do not want to pay (even tough its almost free) could just wait till its done, and profit from it anyway.
What do you guys think? I think it could work....
meanwhile... if there are people around who want to trade one of the above mentioned things fro artwork, or want 15-30$ for it, let me know!
-walking vehicles
-different weapon model in 1st/3rd person (with arms attached)
-bumpmapping
-texture lighting
-radiosity
-....
I think the problem is not much people are actually able of implementing these things. We had no trouble finding game programmers... lots of those people around.
Now here are some toughts to get the stuff anyway. let me know what you guys think:
-I'm willing to trade artwork (textures, sky boxes, websites, GUI,...) for one of the above things. I am talking about quality work here... I would defenetly try to make it worth the effort so its a fair deal.
-OR...I'm not the only one who wants these things. So, if there could be a system like rent a coder where there are some jobs available (like implementing bump mapping), but with the diference that everyone can pay, so creating a funding. Lets say 100 people are willing to pay 15$ for bumpmapping, well that's 1500$ a coder could make out of it. In fact, one could make a living out of that. Unfortunately this is almost not possible without some supervising and good organization. Another thing is people who do not want to pay (even tough its almost free) could just wait till its done, and profit from it anyway.
What do you guys think? I think it could work....
meanwhile... if there are people around who want to trade one of the above mentioned things fro artwork, or want 15-30$ for it, let me know!
#2
What I mean is... i'm sure I can find 20 people who want to pay 10$ for bumpmapping. With this money the Torque license is already profitable. If we all put together, some programmers could even live of it. BUT... we all rather keep on working on our own. I really want these things in. I'm a student tough, and even tough I do freelance work between my study, I cannot pay hundreds of dollars for a programmer to do these things. The ones that work for free aren't really able to do it, so, my cry for help here is to put not only our heads together but our resources too (well not completely offcourse, just creating a fund for something... then use that to pay a programmer to do something specific).
Ofourse I still hope to find someone who's willing to give it a shot just on royalties basis... but after a year of searching for the right person, I kind of gave up.
09/20/2002 (9:46 am)
I mean radiosity as implemented in todays games. Torque seems to be one of the only next gen engines that doesn't have it. But as you see.. its the last thing on my list. I don't really need it, it would be an extra. But if we could set up a system where more then 1 person can pay a programmer, i'd defenetly be willing to spend 15-30 $ on it. What I mean is... i'm sure I can find 20 people who want to pay 10$ for bumpmapping. With this money the Torque license is already profitable. If we all put together, some programmers could even live of it. BUT... we all rather keep on working on our own. I really want these things in. I'm a student tough, and even tough I do freelance work between my study, I cannot pay hundreds of dollars for a programmer to do these things. The ones that work for free aren't really able to do it, so, my cry for help here is to put not only our heads together but our resources too (well not completely offcourse, just creating a fund for something... then use that to pay a programmer to do something specific).
Ofourse I still hope to find someone who's willing to give it a shot just on royalties basis... but after a year of searching for the right person, I kind of gave up.
#3
09/20/2002 (9:59 am)
hey ward.... you mentioned bumpmapping..... I think the guys at project shadow implemented bumpmapping into torque, and I think they mentioned that they would be open for nagotiation with GG to add it to the engine... I dont know whatever happened with any of that, but if you contact them and ask real nicely, they might share their stuff, especialy if you could get 20 people who wanted it to and could make it worth their while :)
#4
They can't be the only ones that have this stuff.. .i'm sure there are some more people around. So.. name your price folks... i'm interested in having the discussion and try to raise the money needed.
09/20/2002 (10:11 am)
I don't believe you can count on those guys. I think they are looking for a royalties or some other deal with GG.... something they propably wont get.They can't be the only ones that have this stuff.. .i'm sure there are some more people around. So.. name your price folks... i'm interested in having the discussion and try to raise the money needed.
#5
Thanks for the thread on texture lighting, I didn't know what that was (having never modelled for halflife), but doesn't it strike you as a bit of a botched mechanism? Not sure how compatible it would be with other upgrades either, lightmap calculations would probably go up a fair amount.
Radiosity is seriously difficult to do very well, but I guess a quick implementation would be better than none. And it can give a striking increase in visual quality. Seems the next big thing to try and get right, but a strong solution won't be real-time for a good while yet.
I don't think implementing bump mapping etc. is the hard bit. Upgrading the art pipeline to support it would be very 'interesting' though. As well has having to do it twice (OpenGL / DirectX).
It's not hard to botch stuff into the engine, making it reliable enough for easy usage is far more difficult. Give it some time, i'm sure they're all on everyone elses wish lists as well. I'd love all the features you've mentioned, but it seems a bit strange to worry about such minor details at this point in my games project. By the time you've completed your game, they may well be available anyway!
09/20/2002 (10:29 am)
Can't you get walking 'vehicles' just by swapping the player model? Thats how I did mine. Don't try and mount more than one person to a vehicle though ;) Then again I think you could probably use the standard mount point mechanism for that.Thanks for the thread on texture lighting, I didn't know what that was (having never modelled for halflife), but doesn't it strike you as a bit of a botched mechanism? Not sure how compatible it would be with other upgrades either, lightmap calculations would probably go up a fair amount.
Radiosity is seriously difficult to do very well, but I guess a quick implementation would be better than none. And it can give a striking increase in visual quality. Seems the next big thing to try and get right, but a strong solution won't be real-time for a good while yet.
I don't think implementing bump mapping etc. is the hard bit. Upgrading the art pipeline to support it would be very 'interesting' though. As well has having to do it twice (OpenGL / DirectX).
It's not hard to botch stuff into the engine, making it reliable enough for easy usage is far more difficult. Give it some time, i'm sure they're all on everyone elses wish lists as well. I'd love all the features you've mentioned, but it seems a bit strange to worry about such minor details at this point in my games project. By the time you've completed your game, they may well be available anyway!
#6
Anyways, Radiosity lends itself to 'texture lighting' since in Radiosity any arbitrary patch of your scene can be a light emitter. I'm not sure how I'd implement texture lighting without Radiosity, actually. Anyone know if there are games around with texture lights but _not_ radiosity?
Ward, I'm noticing that except for your request for walking vehicles, these are all eye candy type requests. Is your gameplay code really so well worked out that this is holding up your game?
If not, I'd just wait a bit and see if anyone just adds this stuff. Bumpmapping in particular shouldn't be so tough... I expect someone will submit code for it sooner or later.
09/20/2002 (10:53 am)
Radiosity in games is usually precomputed, for those confused about the computational requirements of the algo. It's not a run-time thing, it's just how some games generate their light maps. Radiosity's view independant properties are particularly well suited to static lightmaps.Anyways, Radiosity lends itself to 'texture lighting' since in Radiosity any arbitrary patch of your scene can be a light emitter. I'm not sure how I'd implement texture lighting without Radiosity, actually. Anyone know if there are games around with texture lights but _not_ radiosity?
Ward, I'm noticing that except for your request for walking vehicles, these are all eye candy type requests. Is your gameplay code really so well worked out that this is holding up your game?
If not, I'd just wait a bit and see if anyone just adds this stuff. Bumpmapping in particular shouldn't be so tough... I expect someone will submit code for it sooner or later.
#7
I can tell you that I was suprised at how complex it got in such a simple environment nevermind progressing interiors to that state and trying to keep the patches under control.
Mark is correct in that the generalisation of Radiosity is really discussing the distribution of energy (in this case photons) from a radiative source onto surfaces which is essentially what a lightmap does. The full radiosity solution does incorporate much more though.
I don't mind giving advice to anyone attempting this but I would suggest that no-one stop game development waiting for someone to do it anytime soon.
- Melv.
09/20/2002 (11:02 am)
I spend an awful lot of time tinkering with different rendering techniques just so that I can learn how they all work. Not such a long time ago I did a simple radiosity test on a test room (internals of a cube) with test diffuse light sources.I can tell you that I was suprised at how complex it got in such a simple environment nevermind progressing interiors to that state and trying to keep the patches under control.
Mark is correct in that the generalisation of Radiosity is really discussing the distribution of energy (in this case photons) from a radiative source onto surfaces which is essentially what a lightmap does. The full radiosity solution does incorporate much more though.
I don't mind giving advice to anyone attempting this but I would suggest that no-one stop game development waiting for someone to do it anytime soon.
- Melv.
#8
- Melv.
09/20/2002 (11:04 am)
Forgot to mention that one of my favorite references (which also discusses Radiosity techniques) is "Advanced Animation and Rendering Techniques - Theory and Practice" by Alan/Mark Watt by Addison-Wesley ISBN: 0-201-54412-1.- Melv.
#9
09/20/2002 (12:35 pm)
Right, you can always prerender radiosity and map it, but that kinda goes against the intent of radiosity. Radiosity was developed to produce photo-realism based on simulating what light really does. If you set a number "x" and you start a line from a light source, point it in any random direction, and let it diffuse, refract, or reflect..that's one. The light then moves on to diffuse, refract or reflect again...that's two. You keep doing that until you reach X. now that was one line. Imagine having to do that 100s, 1000s or even 1000000s of times in order to acurately depict what light is doing, now you can see why it is a computationally explosive technique. Full radiosity takes a long time to render just one frame. The way around it, prerender, and texture, but that gives a pasted look that (in my opinion) isn't much better than Goraud or Phong methods.
#10
When you talk about drawing lines from light sources and reflection/refraction, it makes me think you're confusing radiosity with raytracing.
Radiosity is a view independant method of modelling diffuse lighting. Because it's view independant, you only have to recompute it when you change your geometry or move your lighting. For mostly static interiors and mostly static lighting (what torque has at the moment) this means you only have to compute it once per map.
Ray tracing is a view dependant alogrithm that traces rays either from the viewer or the light source ('reverse' ray tracing) and computes how those rays reflect and refract around the scene. You have to compute this once per frame.
Check out http://www.cg.tuwien.ac.at/research/rendering/rays-radio/
09/20/2002 (1:04 pm)
Jeremy, Radiosity typically only deals with diffuse interactions between patches.When you talk about drawing lines from light sources and reflection/refraction, it makes me think you're confusing radiosity with raytracing.
Radiosity is a view independant method of modelling diffuse lighting. Because it's view independant, you only have to recompute it when you change your geometry or move your lighting. For mostly static interiors and mostly static lighting (what torque has at the moment) this means you only have to compute it once per map.
Ray tracing is a view dependant alogrithm that traces rays either from the viewer or the light source ('reverse' ray tracing) and computes how those rays reflect and refract around the scene. You have to compute this once per frame.
Check out http://www.cg.tuwien.ac.at/research/rendering/rays-radio/
#11
09/20/2002 (2:11 pm)
My bad. I never liked my "Computer Graphics" class in college anyway. My teacher was a retard. Come to think of it "Ray Tracing" IS a better name for it. But he DID teach this method as "Radiosity". That class was stupid cuz he cared more about theory than implementation. I got a C in that class but I taught myself OpenGL and made a 3D tic-tac-toe where user can move the camera place cool looking 3D tokens in the slots, had a nice skybox, and cool animations, along with transparency and glow emmitance while everyone else did things that were graphically ugly and 2D, but they got As cuz they used math. I hated that teacher.
#12
@Gareth:
The problem is the size of a vehicle is bigger then a player. With anything bigger then a player the aligning fo the feet and the ground becomes a visual problem. There should be some code that stops the leg animation when the feet touches the ground (or something like that). I would really like to have it a real vehicle class rather then a hack like replacing the player model. I hope you understand what I mean.
This also seems to be a very popular request.
09/20/2002 (2:41 pm)
You are right, apart from the walking vehicle its mostly eye candy. Besides that there's the different weaponmodel for first and third person issue. Other then that it's eye candy indeed. But that's just why I ask for it now. Its too late in the end of the develoment process to start thinking about bump mapping, radiosity etc... too much artwork would have to be redone. So that's why I bring it under the attention, hoping to find someone willing to spend some time at least on one of these issues (wether it'd be payed or not). Everyone I talk to seems to need at least one thing on my list.. so these seem like quit popular requests.@Gareth:
Quote:
Can't you get walking 'vehicles' just by swapping the player model? Thats how I did mine. Don't try and mount more than one person to a vehicle though ;) Then again I think you could probably use the standard mount point mechanism for that
The problem is the size of a vehicle is bigger then a player. With anything bigger then a player the aligning fo the feet and the ground becomes a visual problem. There should be some code that stops the leg animation when the feet touches the ground (or something like that). I would really like to have it a real vehicle class rather then a hack like replacing the player model. I hope you understand what I mean.
This also seems to be a very popular request.
#13
As for Texture Lighting and Radiosity, those are also on our list of things to do (whose list doesn't include those ;) ) but we will be working on texture lighting before radiosity. It is a more simple procedure then radiosity. I don't know if it will be the next thing on our list or not, but it would be coming up pretty soon. I can keep you informed of our progress.
09/20/2002 (5:02 pm)
Ward, my team is getting pretty close to finishing DOT3 Bumpmapping and getting into our project (www.ta-network.net), we plan on releasing the code snippet to the public, but we could use another project to test out the code snippet, and to see how it interacts with other projects before we release it to the public. We are still probably several weeks off of getting DOT3 Bumpmapping to work completely, due to our coder being tied up with other responsibilities at the moment, but we would be more then willing to share the code snippet when it is ready to be used. I think that would help ensure that our tutorial is easy to use, and confirm that the code is easily portable before we submit it to Garage Games.As for Texture Lighting and Radiosity, those are also on our list of things to do (whose list doesn't include those ;) ) but we will be working on texture lighting before radiosity. It is a more simple procedure then radiosity. I don't know if it will be the next thing on our list or not, but it would be coming up pretty soon. I can keep you informed of our progress.
#14
I actually forgot altogether about that, but it would kind of make sense.
Or if you fancy doing it a different way, figure out a way to load max models from 3dsmax 5 with its new radiosity solutions into Torque for geometry (not just shapes).
There may be some of this coming anyway.
Phil.
09/20/2002 (5:47 pm)
If youre thinking about radiosity solutions, it might be useful for someone to work at plugging paul nettle's radiosity renderer into torque.I actually forgot altogether about that, but it would kind of make sense.
Or if you fancy doing it a different way, figure out a way to load max models from 3dsmax 5 with its new radiosity solutions into Torque for geometry (not just shapes).
There may be some of this coming anyway.
Phil.
#15
I'm wondering, are you implementing it for dts shapes? buildings? Or both?
09/21/2002 (2:17 am)
@Ryan: That sounds great! If you need some folks to test it.. or help debug it, you know who to turn to ;)I'm wondering, are you implementing it for dts shapes? buildings? Or both?
#16
-J
09/21/2002 (4:38 am)
That Paul Nettle code crossed my mind today as well... some radiosity would do Torque interiors much good... -J
#17
On a side note, this "IEspell" tool that was posted about in the GarageGames forums just a little while ago is great. No more copying my posts into Word to spell check them.
09/21/2002 (12:08 pm)
@Ward: we will be implementing DOT3 for both models (.dts shapes) as well as interiors (.dif) and we also want to implement it for the terrain. We are currently focusing on getting it working on .dts and .dif files first, then terrain. We actually would have had the code done by ow, but real life, as well as some other more pressing features that we required for our project have slowed down the progress of DOT3, but it is coming along very nicely.On a side note, this "IEspell" tool that was posted about in the GarageGames forums just a little while ago is great. No more copying my posts into Word to spell check them.
#18
09/21/2002 (1:46 pm)
I would be willing to shell out 10-30 bucks for bumpmapping, texture lighting or a decent physics engine, maybe even more. Mail me at blackplastick@aol.com if you are working on something like this for torque or have something like that already. Thanx.
#19
I'm wondering, what will you use to store the bumpmap info? A second image file? Or will you store it in the alpha channel? I guess both have their pro's and con's.
09/22/2002 (3:02 am)
@Ryan: Great! I'm especially interested in using it on .difs If it doesn't cause too much performance issues I'd use it for models and landscape too...but for now I only planned on using it for buildings. So, its great to hear you're even pulling out support for everything ;)I'm wondering, what will you use to store the bumpmap info? A second image file? Or will you store it in the alpha channel? I guess both have their pro's and con's.
#20
09/22/2002 (11:39 pm)
@Ward: As of now we plan to store it in a second image file, as this makes it the easiest for the texture artist, but like you mentioned, both have their pros and cons, we might play around with both. As for performance, TA is geared towards GF2 and higher cards, but for bump-mapping, we are looking at implementing two methods, one for true DOT3 support, for higher end cards (GF2 and up) and then a lower end solution for those cards that aren't as up to date. 
Torque Owner Jeremy Tilton