ray tracing and bump mapping
Moderator: Moderators
-
SwiftSpear
- Classic Community Lead
- Posts: 7287
- Joined: 12 Aug 2005, 09:29
Well raytracing is theoretically nicer then the current raster based approaches to rendering (many effects that is quite hacky with todays techniques becomes easy/elegant with RT), if we had unlimited cpu power everyone would use it.
The problems is that it requires lot of computing power and that power has to come in a more general form then what the current gpus deliver (although they can be used for primary ray hits) so most of the job has to be done on the cpu. With multicore CPUs and dedicated RT cards (there is some fpga prototypes) it might become usable for general realtime graphics though. And as a bonus it scale better with scene complexity then raster based rendering.
The problems is that it requires lot of computing power and that power has to come in a more general form then what the current gpus deliver (although they can be used for primary ray hits) so most of the job has to be done on the cpu. With multicore CPUs and dedicated RT cards (there is some fpga prototypes) it might become usable for general realtime graphics though. And as a bonus it scale better with scene complexity then raster based rendering.
Wikipedia is your friend!
http://en.wikipedia.org/wiki/Raytracing
In short, you calculate for every pixel the direction in which light would come from the world to the eye, and you calculate where this ray (based on direction and start point) hits the world geometry. From this point you can start doing this recursively and implement other cool things and you have a basic raytracer. The major difference with conventional methods used by games, is that this is an image based approach, you calculate for every pixel which geometry should be seen on it, whereas in an object based approach (which is the common realtime method) you calculate for geometry on which pixels it should be seen.
Hmm I guess it's still not really short
http://en.wikipedia.org/wiki/Raytracing
In short, you calculate for every pixel the direction in which light would come from the world to the eye, and you calculate where this ray (based on direction and start point) hits the world geometry. From this point you can start doing this recursively and implement other cool things and you have a basic raytracer. The major difference with conventional methods used by games, is that this is an image based approach, you calculate for every pixel which geometry should be seen on it, whereas in an object based approach (which is the common realtime method) you calculate for geometry on which pixels it should be seen.
Hmm I guess it's still not really short
Probably the best speedup is a better CPU->GPU bandwidth and also a better cpu in general, since that what's doing most of the work here.hmmm, I could have sworn it shared certain functions. The last time I benched it with some buddies better vid cards did help FPS.
Having written both a standard polygon renderer and a failed raytracer both from scratch. I can say quite certaintly that raytracers are not going to happen anytime soon. In my inefficient system I could at least get a reasonable FPS with a couple thousand polygons on the screen. With a raytracer it would take at least 12 seconds for just one frame to render. Now I didn't make either as efficient as I possibly could have, but the polygon one looked 96% as good as the ray tracer so optimizations or not, it wasn't going to happen anytime soon.
Ray tracers do have their advantages, you can get true lighting, translucency and reflections. Currently anytime you see a shadow in a game its a hack, if you see a translucency its another fancy hack and reflections are usually the biggest hacks of all. The last advantage of raytracing is that it does all of those things. If you have one it should in theory calculate shadows, transperancy and reflections all by itself with very little programming effort. It also is relativly simple with little to no exceptions like there are in current rendering models.(units rendered differently than maps which are rendered differently from backgrounds.)
just my 2.5 cents.
Ray tracers do have their advantages, you can get true lighting, translucency and reflections. Currently anytime you see a shadow in a game its a hack, if you see a translucency its another fancy hack and reflections are usually the biggest hacks of all. The last advantage of raytracing is that it does all of those things. If you have one it should in theory calculate shadows, transperancy and reflections all by itself with very little programming effort. It also is relativly simple with little to no exceptions like there are in current rendering models.(units rendered differently than maps which are rendered differently from backgrounds.)
just my 2.5 cents.
-
monohouse
what about some of those ray-tracing hardware accelerator cards ?
and physics cards ? maybe they could be used ?
http://graphics.cs.uni-sb.de/SaarCOR/
http://graphics.cs.uni-sb.de/RTGames/
and physics cards ? maybe they could be used ?
http://graphics.cs.uni-sb.de/SaarCOR/
http://graphics.cs.uni-sb.de/RTGames/
-
Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
The reason OTA doesn't run well at high load on even modern machines is because it uses only software rendering.monohouse wrote:well, ray tracing is not a realistic/rational thing now, but OTA have lived so long and even the fastest computers to day having trouble to handle it, what im sayin is that for to be played in the future, this might be the one thing that will make it special and long-lasting game, obviously this is not a subject relevant for this point of the development, but near the version 1.5 or so this should be considered as the future thing, to make spring special, by then I believe it will be quite good by itself, and this would probably be the next step, after bump mapping of corse :)
-
Wolf-In-Exile
- Posts: 497
- Joined: 21 Nov 2005, 13:40
-
SwiftSpear
- Classic Community Lead
- Posts: 7287
- Joined: 12 Aug 2005, 09:29
Ray tracing in spring isn't priority to say the least. If some mad developer wants to hack in an ray tracing renderer I'd have no complaints, but there's also no way in hell I'd be able to use it.
Gameplay relevant physics improvements aren't plausible for performance reasons, non gameplay relevant physics improvements are in the same category as ray tracing. It's not going to be on an official development "To Do" list for a long long long long time, but if some mad developer decides they want to do it anyways no one will stop them. (the commies may try, but they will be suppressed)
Gameplay relevant physics improvements aren't plausible for performance reasons, non gameplay relevant physics improvements are in the same category as ray tracing. It's not going to be on an official development "To Do" list for a long long long long time, but if some mad developer decides they want to do it anyways no one will stop them. (the commies may try, but they will be suppressed)
i wonder if bump mapping for the terrain might be an option? I come from a Source Engine background with regards to modding and stuff, and afaik bump mapping doesnt drain too much.
The only hitch is how to include a bump map in the map making process. It might be an idea to tie a bumpmap tile to terrain types in the text file (its been a while since i tried making a map for spring, i can't remember what that file is called).
This would be more difficult, i think, but it would also be great to have bump mapped decals. So, for instance, a crater would look more 3d, rather than a simple black splodge.
The only hitch is how to include a bump map in the map making process. It might be an idea to tie a bumpmap tile to terrain types in the text file (its been a while since i tried making a map for spring, i can't remember what that file is called).
This would be more difficult, i think, but it would also be great to have bump mapped decals. So, for instance, a crater would look more 3d, rather than a simple black splodge.
bumpmaps (or is it normalmaps?) are supported by the new map format 
however this map format is quite experimental
however this map format is quite experimental