Yeah, blame David. It was to clearify to him and *is* completely irrelevant to everything else, save for that its an avenue I chose to *intentionally* close, so as not to sink to her level, which makes it harder for me to get a copy at all.
Going back to the real issue.. Yeah, in some cases its just headers. The problem is, in the case of .NET, the only reason you can *still* code for ActiveX is a) people seriously disliked .NET and the projected eventual loss of OLE, so they decided to backpeddle and b) they couldn't get rid of OLE completely *now* without breaking 99% of the existing software. Its pretty damn clear from everything from their press releases to their hype of .NET to their actual removal of wizards and libraries needed to "make" ActiveX controls in the newer compilers, etc., that their intent was, and still may be, to depricate the entire OLE system, in favor of their bloody, "Everything is a internet applet!", architecture. A system that is *only* better in that it helps them and other people make remote servers that host stuff you have to pay usage fees on every time your kid wants to draw a bad picture of a tree or something.
They didn't just make it harder to use OLE, they tried to make it impossible, even to the point of removing references to the whole idea from basic documentation. Drives me nuts. Its like trying to find anything one **real** "ray based" raytracing, now that every damn application on the planet uses either DirectX or OpenGL to funnel triangles into a scanline graphics card... You still want photo realism, you go with raytracing, you want real time graphics that, if you try really damn hard and don't mind needing 4 TB of disk storage for the 3D meshes and textures, you can *almost* get the same result. Want to code something that does the former, instead of the later... Forget it, unless you can find a book on it that hasn't been published in 20 years... :(
Quote: Its like trying to find anything one **real** "ray based" raytracing, now that every damn application on the planet uses either DirectX or OpenGL to funnel triangles into a scanline graphics card... You still want photo realism, you go with raytracing, you want real time graphics that, if you try really damn hard and don't mind needing 4 TB of disk storage for the 3D meshes and textures, you can *almost* get the same result. Want to code something that does the former, instead of the later... Forget it, unless you can find a book on it that hasn't been published in 20 years... :(
Where of all places did this come from? What kind of ray-tracing are you looking for? People use ray-tracing all the time for high-quality rendering. Whole classes are still taught about ray-tracing. I don't know why you say that books haven't been published in 20 years. I just googled "ray tracer" and got all kinds of results, varying from educational to implementations.
Maybe you have a very specific application in mind. I'm not sure why it's so evil to use DirectX or OpenGL to "funnel triangles into a scanline graphics card" -- you almost make the phrase sound dirty or something. Why should programs do software rendering when the 3d card can do it?
Because, the card ***doesn't*** do it. The card uses cheats and hacks that are useful for real time games and other things, but which cannot produce the same quality or effects. And I have looked for those same websites. Most, if they truely talk about actual raytracing are either a) closed source, b) restrictive in licenses, c) assume you already know most of the vector math, etc, or d) are not actual raytracing sites, but ones that use OpenGL or DirectX.
There is no hardware based system in existing today, with the possible exception of one in development in Sweden or some place, and **none** on the market that can do raytracing. They all use systems that can quickly funnel data to a scanline based engine, but which cannot perform complex things like global illumination (without pre-building the illumination tables), true reflection (especially of off screen objects that don't "exist" in the image once the scanline system sorts out what is visible), and so one. They don't even really do refraction correctly and until DirectX 10 comes out, they won't do focal blur, which is damn near "standard" in ray path tracing systems.
Its real easy to find info on systems that are hardware dependent, and can't do 20-30% of what a raytracer actually does. Finding useful information on the mechanics of the real thing is damn hard, often never covers the most basic principles needed to start coding one, or are so old that the links to the code/software aren't even working anymore.
Now.. There are some like POV-Ray that are exceptions in that you can look at the code, can find the software, etc., but unless you have some idea "how" the thing works in the first place, its not going to help much to look at it. In the end, the "entry level" stuff isn't available any more to the casual interest people like me that either can't afford and/or can't drive 5,000 miles to some place to learn it from some place that does teach it.
In any case, just try to go on some place like the POV-Ray forums with the claim that hardware is better or that its the same thing. More than a few show up there once in a while saying, "Gosh, why don't you modify POV-Ray to use the video hardware for X, Y and Z?" The answer is inevitably, "It won't work.", "The card can't actually do that.", "Cards don't use enough precision in their calculation to be useful, even if it could work.", and so on. They are not designed to do the same thing. But, since the lay person can't tell the difference and the card makers are intentionally **not** pointing out the difference, 90% of the sites for scanline rendering call themselves raytracing applications and get by with it.
Believe me, this is one thing **I** know way more than you about, because I have been reading the forums for a real raytracer for like 10 years and even if I don't know the math needed to make one from scratch, I do know why they are *not* the same thing and why its going to require a hardware implimentations of raytracing algorythms, instead of scanline, to legitimately claim that hardware is "ever" better for anything but fast, cheap, plastic looking graphics. If you want to know the detailed differences, you can try reading some of the threads on why they differ at news.povray.org.
But, this is dragging the thread in a completely pointless direction, so, lets drop it.
You are tilting at windmills! You managed to answer lots of questions I did not ask and you completely missed the most important one: what is your area of application??
I never said hardware was better for raytracing! I only said that for many purposes it is fine, and there is no point reinventing the wheel making your own renderer.
This whole argument is pointless, stupid even, until you say what you are trying to DO. I have no idea what your context is, which is why I tried asking you what your area of application is.
Quote: In the end, the "entry level" stuff isn't available any more to the casual interest people like me that either can't afford and/or can't drive 5,000 miles to some place to learn it from some place that does teach it.
It sounds to me that what you really want is a free lunch. And we all know what they say about free lunches...
1. Small footprint for the *scene* files.
2. High detail with minimal (or better *no*) premade tectures.
3. Easy to work with script that is a bit more flexible than POV-Rays current implimentation.
4. I don't even want to see "mesh" as an option, since it breaks rule #1.
5. No license restrictions for use as a library and linking into another application.
6. Exclusion/limits on features that cause long render times.
Now, POV-Ray almost fits this. But... while you can do 1 and 2, 3 won't happen until they start work on the major rewrite they plan. Items 4 and 6 are not possible to because the license requires you to make "all" derived copies work "as per the original", so you can't simply turn off stuff that is going to make the scene file bloat or take massive times to render. And 5... I think there are ways you can sort of side step that, as long as you make certain the only way to use the integrated version is *if* the render window is prominant and displays the licensing for it *before* letting you hide the window or otherwise do something that prevents the user from knowing what is being used.
The point is to provide 3D that can be built and adjusted, on the fly, on the server end, the same way that rooms or mobs might be in a mud, while limiting the user end storage requirements and the time to live (i.e. download sizes) for the data needed to produce the image). Now, a library of prebuilts, like huts, medieval architecture, etc. that can be downloaded by the user to speed this up would be nice, but the point is *still* to use only primitives, so that the scene file is build, for example, in the case of a castle wall, with a few hundred script generated copies of a block or one solid surface with strategic cuts taken out (which would take only maybe 20 objects) and some procedural textures, all of which would take... 100k maybe? This is apposed to what either OpenGL or DirectX games might use for the same thing, which could consist of a 2-3MB mesh and a 1MB image file, not including all other parts used to make the castle.
That clearer? Seriously, the only answer to this that would work with cards would still take a long time to do, since it would require using something like marching cubes to "tessilate" the primitives into meshes the card can deal with, then algorithms to generate the procedural textures into a bitmap the card could them use to paint the object. And that is going to in some cases take *more* time that just parsing a text file and using software to produce an image. So, as I said, to me the best solution is to figure out how to make something like POV-Ray, but without some of the license issues that make using it in such a context pointless.
That's not an application, it's a list of requirements. What are you doing -- are you trying to do real-time graphics? Are you trying to do one-off rendering? Photo-realistic rendering?
Quote: This is apposed to what either OpenGL or DirectX games might use for the same thing, which could consist of a 2-3MB mesh and a 1MB image file, not including all other parts used to make the castle.
I don't understand what you're doing. You're talking about a server providing 3d graphics to a client. What does that even mean? Is the server sending some kind of procedural representation that the client then renders? Or is the server sending the actual picture?
I don't see why you think it's impossible to describe the data in a very compact form for OpenGL or DirectX. Since I don't know exactly what you're doing it's hard to tell for sure, but it seems to me that you could do precisely the same thing for OpenGL: you could describe something in terms of primitives, then when you tell the client to render it, it takes those primitives and renders each one in turn, building up the bigger picture.
Anyhow it's really hard to have a meaningful conversation since I have no clue what you're actually planning on doing (but at least I know what your requirements are...)
Still, I'm wondering, since this is going rather far off topic, it might be more appropriate to just drop the topic. (Of course, part of me still wants to know what exactly you're talking about because as stated it makes no sense to me! :P)
Look. There are basic facts about scanline and raytrace that make them non-interchangable. For example, yes, OpenGL has primitives, but it can't handle CSG, where you use one primitive to "cut" another, not without *extra* processing, and in some cases it just can't at all. The conversion from a primitive to what a card can handle requires that it "approximate" the result, this means wasting processing time you would have used anyway to produce a purely mathematical result and instead making a "close to the same" mesh, which then still have to be rendered in on the card. Your doing extra work for no real gain. Even if the card itself supports the primitives, that just means the card has to waste time doing it.
Basically, I could care less about real time. A render of 2-3 seconds wouldn't hurt anything, but more than that... That is why I would want to place limits on how certain things are handled, or, alternatively, use a multi-pass system, so that the first pass gives an approximation of the image, then later passes, if they are allowed to happen, produce the higher quality result. And no, I don't mean having the server send the image. That defeats the whole purpose. I want the "scene" to be something that can be sent in the smallest form possible, so that it doesn't lag a client too much, but also with minimal "storage" requirements on the user end **and** scriptable effects, lik elighting, weather, etc., which BTW, also don't actually work quite the same in a scanline system as they do in a raytraced one.
You want an example. Try doing any of the following using OpenGL and the **same** size description files:
which was also only 247 bytes. What are you talking about when you say compact? 500k, compressed, which would then need to be unpacked to use?
The point is to minimize the footprint of the whole thing to the point where you can produce stuff like this, maybe for places that might normally use static MXP images (like you can find any..), while reducing the storage space needed on the user end to "as little as possible". Even an MXP mud would, right now, using static images, use megabytes of data to store cached images, with no capacity to adjust lighting, etc. in them, and 3D systems that can take up **gigabytes**, just for the data, no matter how *compact* you make that data. I just don't see, with the current state of OpenGL and DirectX card, how you manage that, without *still* wasting the time to "trace" the object anyway and produce the card usable data needed, then end up with an inferior result from it, do to the limitation of the method. If you are going to need to waste time producing the mesh from the data, why not just not bother and do it in software in the first place, but place limits on what can be used. For example, adding in some ambient lighting and removing the global illumination (radiosity) from the pots example makes it look less nice, but it also changes the render time from minutes to seconds, since it doesn't have to pre-calc the lighting. Radiosity - probably not something I would allow in a "first pass", or maybe even in a longer one, and especially not if the image isn't lit using static parameters (i.e., no time of day effects, sun position, etc.)
Some things like that would have to be intergrated into the render system, so that the game server could, as part of the script, tell it specifics about the world, including if it was the moon(s) lighting it, what phase they where in, if it was overcast, etc. Macros in the script wouldn't do it, since that's even more "script" you would need to send, and you would need to change it every time the game had more suns, moons, or whatever for the world.
Look, its a complicated set of requirements. Much of it cards can't handle because either the data needed to be front loaded, or generated on the player end, is large, or the means to produce certain effects are just completely absent. But, existing implimentations don't really help much either, since they lack inbuilt support for some key things to make it work well, and any solution you could use with them would mean generating more data some place, then parsing more stuff before you finally get the image started at all. And the OpenGL/DirectX methods just make some of the problems either much bigger or insurmountable, depending on what "feature" you are trying to do.
Lets just put it this way. From a practical standpoint, to do what I would like, I doubt OpenGL would produce better than 5 frames a minute either, which POV-Ray, if it had object persistence between animation frames and didn't need to reparse (coming in version 2.0 supposedly), could do better than that. Why? Bacause by the time you turn up all the settings in some game like EQ2 to where they match the "expected" results the game was designed to predict and run optimally with, the card is spending some much time trying to cheat its way around the limitations of scanline to get that result that straight mathematical models using ray path algorythms is **actually** faster. And again, I don't need 512MB to store a 247 byte file in memory, never mind gigabytes to store textures and data I am not using. I certainly don't need 1-2GB of system memory to "build" the data from the description file, so that the card has something to do. I would kind of like to avoid that if possible. lol
Without attempting to get into any arguments here, all I can say is that these remind me of the old demo completitions in the early 90s with animations. Future Crew and some other groups put together a lot of great demos.
I don't know terribly much about graphics rendering at all, so I'm a little confused here. I thought all the shortcuts that 3d games had to take were because of the unpredictability of the system. You can't tell if someone is going to continue moving in a straight line, or start attacking, or if they will suddenly change clothes. The only time I've seen someone play around with 3d graphics was a friend of mine who was doing a project for school a few years back, and a 20 minute video he made took roughly a day to render (he said he could take shortcuts and knock the time down a lot from a day). I know that we don't have actual lighting or reflections in games because of the time it would take to render them. Please let me know where I'm lost here.
I'm also kind of curious, since I don't have POVRay. How long do these files take to render? I know the limit is 5 days according to the rules for the contest, but I'm assuming they take only a small fraction of that time.
Wow, POVRay is a Debian package :) time for the rjjaij.pov file (3rd one down that you mentioned), on a sempron 2800+ with 512MB of ram and an Asus EN6200LE:
my favourite one from year 4 was the second place winner... wow does that one take a while. I went out to dinner while it was running, so I wasn't chewing up processor time with anything else at all. POVRay used an average of roughly 99.2% of processing power, and the maximum RAM usage is only 1.1%. I am using this to justify buying a better processor with my tax refund.
Time For Photon: 0 hours 0 minutes 19.0 seconds (19 seconds)
Time For Trace: 2 hours 29 minutes 53.0 seconds (8993 seconds)
Total Time: 2 hours 30 minutes 12.0 seconds (9012 seconds)
Guild Wars fps: 40ish, but nowhere near as pretty as the Persistance of Vision. average 90% of processor power, and pretty much all of my RAM.
Quote: Look. There are basic facts about scanline and raytrace that make them non-interchangable.
Argh! Thank you for stating the obvious. I know the difference quite well and I never said they were interchangeable. This is massively frustrating because I am fishing for something in total darkness, *still* having little idea what exactly you are doing. I take guesses, stabs at things but then you come back telling me how little I know, just because I happened to guess incorrectly about what you were doing, and all the time you fail to tell me what exactly you are trying to do. It is incredibly frustrating.
Quote: What are you talking about when you say compact? 500k, compressed, which would then need to be unpacked to use?
If you noticed, those files are a programming language of sorts. It's a remarkably compact one, but sure, you could probably reproduce it in OpenGL. I don't feel like doing it because it would take a really long time to build a system capable of unpacking all that, but what makes you say you can't use exactly the same file format in OpenGL?
OpenGL is just something that puts stuff on the screen. If you wanted to, you could render your entire scene pixel by pixel. Of course, that would be really slow and defeat the point, but with that in mind, you could in fact re-implement a ray-tracer if you wanted to.
About the game, though, you seemed to suggest later on that you want to store the procedural descriptions on a MUD server, and send them over to the client who will then take care of rendering them. In other words, send an image over, described not in pixels but in procedures.
Well, as I said above, there's no reason you can't do that in OpenGL. You seem to object to needing a whole system to draw the picture, but you need the same thing if you're doing ray-tracing.
What are the technical reasons are for why you think you cannot specify a scene procedurally for OpenGL?
Of course, you would have to go write code to "execute" the procedures and translate them to something OpenGL can deal with (even if it's just points on the screen) but nonetheless it is still possible.
Perhaps what you meant by "impossible" was "I don't want to do it that way", which is a valid problem (I wouldn't really want to either, unless I really had to), but that would be a completely different statement!
Quote: I just don't see, with the current state of OpenGL and DirectX card, how you manage that, without *still* wasting the time to "trace" the object anyway and produce the card usable data needed, then end up with an inferior result from it, do to the limitation of the method
Who says it's going to be inferior? OpenGL can be used, if you'd like, as a tool to just put pixels on the screen. So you can do a lot of your logic in software, and then just put the pixels on the screen.
Quote: If you are going to need to waste time producing the mesh from the data, why not just not bother and do it in software in the first place
Well, that's an interesting question, but as I said above this is not a technical impossibility, it's just a question of having to translate a procedural description into OpenGL.
Quote: Some things like that would have to be intergrated into the render system, so that the game server could, as part of the script, tell it specifics about the world, including if it was the moon(s) lighting it, what phase they where in, if it was overcast, etc
I thought we didn't care about real-time. OK, this isn't second-by-second, but suddenly we need to care about rendering the same thing relatively often as things change. Maybe it's not such a good idea to spend minutes re-rendering the image every time the weather changes...
Quote: I certainly don't need 1-2GB of system memory to "build" the data from the description file, so that the card has something to do.
If you're going to make clear, empirical claims like this, I would like to see some kind of data point. For example, some kind of proof that it would actually require that much.
Have you ever heard of procedural terrain generation for OpenGL? It's quite cheap in terms of memory, and produces nifty results, all in a very compact form. And no, you don't need 1-2GB of memory to convert the procedure into triangles.
What I'm really having trouble with is that the topic of discussion has not been made clear. I'm not sure what exactly we're talking about. You said that it's a technical impossibility to use OpenGL, but that's not true, and you've alluded to as much yourself. You were saying that there is no software available to do what you want, but it looks like POVray does just that (and a lot more, it seems). As I said above I'm really not sure what we're talking about and it's getting kind of tiring to take stabs in the dark. :-)
OpenGL and the use a technique that relies on two things 1) meshes, because it cannot produce a mathematically accurate model of objects, pre-made objects, because its pretty much impossible to do something as simple as:
difference{sphere <0,0,0>, 2
box <0,0,0> <4,4,4>}
Assuming that code does what I want. lol Don't feel like double checking my numbers. It should clip 1/4 of the sphere away. To do that, which is called CSG, raytracing uses collision detection to determine when the clipping object is struck, colors the point where it contacts that surface, then continues on until it escapes the bounding area. Bounding areas are sort of quick checks, which tell the engine that there are a bunch of objects without some region and it needs to start looking more carefully for the surface, or that it can stop doing so.
2. Some sort of depth tree to determine what to bother rendering at all, based on what is visible.
The problem with the former is that, if you want to clip a complex object or set of objects, you *must* predefine them, since in order to "get" the mesh needed to produce the result you would have to use raytracing to figure out where the edges of the clipped area was in the first place. Instead, games, and even demos, rely on the editing software to make those calculations and export a complete mesh object, which correctly approximates the result. Could you do it with OpenGL alone? Of course, but it takes extra time, and even a lot of editors when they provide OpenGL previews don't bother clipping the objects, they just show the clipped area in a different color, since its easier than spending the 3-4 minutes needed to calculate every instance of clipping in a detailed scene, so it looks right. The ones that don't do that instead clip as you create the object, so that the time spent making the calculations is handled immediately, then only store the mesh that results. This is faster, but only when *designing*, since if you are taking a raw file with only primitives in it, the software has to calculate all the clippings *before* you get the data needed to actually do the OpenGL.
In other words, if you do it that way, you are going to be spending part of your time doing a real raytrace "before" OpenGL ever handles the actual rendering of the final result.
Now, issue #2 is even bigger of and issue. It effects refraction, reflection and lighting. Refraction can deflect a ray towards an object that **isn't** visible. Reflection can actually reflect an object that is 180 degree behind the camera direction. Lighting can all come from a source that is only from behind. OpenGL, which relies on the graphics card, is going to have to either a) live with not correctly reflecting things, not correctly lighting them, and not correctly refracting the light *or* it has to use a second camera to "see" what is supposed to be reflected, then project that onto the surface of the object doing the reflection. This is a real problem when you mix Refraction and Reflection, or where different objects have completely different reflective properties and the more objects that reflect you have, the more time is spent "precalculating" the result. Raytracing simply bounces the light off of each object, until it either runs out of objects or you hit a trace level limit (which is designed to prevent it getting trapped between two mirrors and trying to calculate *forever*.
Oh, and then there are shadows. There are a reason why OpenGL and DirectX use "shadow maps". Why? Because they can't calculate shadows. They only look at things from the perspective of what is *immediately* in front of the viewer and in that direction, so shadows, which are caused by the direction of the "light", can't be calculated, since the scanline system isn't based on the directionality of the light, only the visibility of the objects. Some things they have added some limited hacks for, but they produce inferior results, since they are just that, hacks used to try to approximate what should happen, not physical models. For example, you could have the card, maybe, caculate a shadow map itself, for a single light source. It can't do it for any source "other" than that light, or if it does, it has to do so for each individually. It can't actually calculate them for "every" source at one time and produce an accurate map that is correct for all of the sources. Worse, shadow maps don't interact with objects the way a real shadow would. In EQ shadows literally got cast "through" walls, because the algorythms didn't know to "bend" them to fit the wall and treat that wall as a point to "stop" projecting the shadow. Fixing that is obviously possible, but you still get false shadows, which do not accurately reflect all light sources or how everything in a room interacts.
I suggest you read up on just what scanline actually does and what it can't do. These are just the most obvious examples and they require a lot of "pre-done" work to correct. They can't be calculated on the fly from a description file or script. They must be done *before hand* to get even close to the same results as raytracing. And even then, some, like mixing multiple mirrored reflections and refraction, are virtually impossible, without doing 90% of the work to make them happen "before" the card ever gets its hands on the data.
Oh, and Shaun, the thing consuming all the time there in the second place winner is this "photons { count 1e6 }", when non-adaptive. Earlier methods uses faked caustics to get the light scattering effects through crystals, which can produce things like the rainbow effect from the prism. That could take even more time, or less, depending on the object. Photons are a means of precalculating a mass of data to figure out just how the light *actually* gets effected by a prism. Interestingly, as you an see below, it takes less time to do photons than to do the normal trace, even though part of the time is spent "precalcing" the data, though only using "adaptive" lighting. That might change a lot with more than one lighting source producing the photons too though.
On my system BTW, that image takes:
5 minutes 31 seconds - As is.
1 minute 58 seconds - With "Adaptive" uncommented.
4 minutes 50 seconds - With photons removed.
Quote: because its pretty much impossible to do something as simple as:
difference{sphere <0,0,0>, 2
box <0,0,0> <4,4,4>}
There's no reason you can't do this as part of your own interpreted language rendered in OpenGL.
Classes here at Stanford have students implement their own ray tracers in OpenGL. No problem. Don't know what your issue is, because you haven't yet given actual technical reasons other than that OpenGL doesn't natively and directly support your specification language.
I'll have you note that your spec language isn't exactly inherent to ray tracing, either.
Quote: 2. Some sort of depth tree to determine what to bother rendering at all, based on what is visible.
No. OpenGL natively only does z-coordinate depth checking. If you want a depth tree you write it yourself. It is not always appropriate.
Quote: The problem with the former is that, if you want to clip a complex object or set of objects, you *must* predefine them, since in order to "get" the mesh needed to produce the result you would have to use raytracing to figure out where the edges of the clipped area was in the first place.
No. You can determine the intersection of mathematically defined shapes without using ray tracing.
Quote: Instead, games, and even demos, rely on the editing software to make those calculations and export a complete mesh object, which correctly approximates the result. Could you do it with OpenGL alone? Of course, but it takes extra time,
Yes, which is why it's usually pre-computed. The intersection doesn't change, so it's much more efficient time-wise to compute it once and be done with it.
Quote: Now, issue #2 is even bigger of and issue. It effects refraction, reflection and lighting. [...]
You do realize that there are plenty of OpenGL libraries that do precisely this, right? Of course it's hard, but then again, there's no such thing as a free lunch, and it's also not exactly easy to implement a ray tracer!
Quote: Raytracing simply bounces the light off of each object, until it either runs out of objects or you hit a trace level limit (which is designed to prevent it getting trapped between two mirrors and trying to calculate *forever*.
I like how you use "simply". Of course it sounds so simple to just bounce the light off.
The problem is that you are compounding the theory of ray-tracing with the implementation of a graphics library. Everything you have talked about is perfectly feasible using the OpenGL library. As I have said previously, OpenGL is, fundamentally, a library for putting pixels on the screen.
Quote: Oh, and then there are shadows. [...] Some things they have added some limited hacks for, but they produce inferior results, since they are just that, hacks used to try to approximate what should happen, not physical models.
I think you are confusing different issues. OpenGL is typically used for real-time rendering in which it is too costly to do all these things you want. So approximations are made, but this is not due to limitations of OpenGL but due to limitation on the amount of time allowed for calculation.
I mean, you're comparing apples and oranges: you're comparing a ray-trace render that can take minutes or longer to an engine that uses OpenGL to render at more than 60 fps.
Quote: In EQ shadows literally got cast "through" walls, because the algorythms didn't know to "bend" them to fit the wall and treat that wall as a point to "stop" projecting the shadow. Fixing that is obviously possible, but you still get false shadows, which do not accurately reflect all light sources or how everything in a room interacts.
This isn't a limitation of OpenGL, it's a limitation of the EQ code. If you admit it can be fixed, it boggles the mind why you think it's a limitation of OpenGL.
Besides, the false shadows are again due to approximations. EQ (and all 3d games) has completely different operating requirements from you: they require real-time graphics, you are happy to render less than one frame per minute.
It's a completely inappropriate comparison.
Quote: I suggest you read up on just what scanline actually does and what it can't do. These are just the most obvious examples and they require a lot of "pre-done" work to correct.
I'll pretend that I haven't heard your continued insinuations that I have no idea what I'm talking about despite continually showing why what you state is not a technical limitation of OpenGL but rather how one chooses to use it.
Quote: They can't be calculated on the fly from a description file or script. They must be done *before hand* to get even close to the same results as raytracing. And even then, some, like mixing multiple mirrored reflections and refraction, are virtually impossible, without doing 90% of the work to make them happen "before" the card ever gets its hands on the data.
This is mind-boggling -- you are pretending that somehow ray-tracing works "on the fly" despite taking minutes or hours to render a scene!
This whole line of comparison is simply not appropriate, for all the reasons I have stated above.
It is completely improper to compare accuracy of a real-time rendering system to the accuracy of a system that allows itself minutes to render a single scene.
5 minutes 31 seconds - As is.
1 minute 58 seconds - With "Adaptive" uncommented.
4 minutes 50 seconds - With photons removed.
Now, I will admit that I don't have the greatest computer out there... far from it. But what hardware are you running that this is only taking 7% of the time that it took me to run? I definatly need some upgrades here.
David.. If you simplify the requirements for OpenGL to the point where all it does is "put pixels on the screen", then of course none of this is an issue. All your doing then is puting the final result on the screen using OpenGL. OpenGL is supposed to support graphics card functions that do real 3D effects though. There are technical limitations that prevent graphics cards from doing anything except approximating raytracing. And z coordinate depth blah blah blah, doesn't solve the problem. Its still only able to handle what is **visible**, not things that are "in the scene", but not "in front of the camera". That there are some hacks in OpenGL to provide mapped images that mimic reflections doesn't change the fact that the hardware can't do them correctly "period". Your missing the damn point with shadows too. That they fixed the wall issue isn't relevant, since they still can't change the fact that shadow maps are not accurate representations of the way shadows form, no matter how they are produced, walls or not. Close, maybe, but that's not good enough and it takes more memory to hold them than just figuring out if a pixel "is" in shadow through raytracing.
Oh, and one clear problem.. Raytracing with most applications is 32-bit or even 64-bit on ones that support that. While the bandwidth for the cards is 32-bit or 64-bit, etc., that is **only** the bandwidth for transfering data to the card itself. The actually internals, from what I understand, are still basically 16-bit math, which means that the precision that they calculate with is significantly worse than the software. Some people tried to suggest changing POV-Ray to take advantage of some newer cards inbuild math libraries, to speed things up, but that can't work, since the precision of the values changes between the hardware and the software. I.e. POV-Ray using 32-bit or 64-bit values, while the cards use 16-bit.
And that brings up another issue. I don't care what hacks you use or what you do to try to get around the hardware limitations, you are still stuck with less accurate results, because the hardware for 3D can't do the math with sufficient precision to produce the same result. It is comparing Apples and Oranges, but I am saying they are not even remotely interchangable. You are the one insisting they are and that its somehow trivial to fake what I want in OpenGL, compared to doing real raytracing.
As to mapping an objects parameters. Yeah, there are a number of things, like marching cubes, which can "map" the surface. None of them are as accurate as a pure math approach using ray paths. You end up calculating things you will "never" see, just so you can feed the card complete objects that it then hacks down to what you "can" see anyway. And, as I have tried to point out, if part of the object isn't "visible" then it won't correctly reflect, cast shadows, even if you have hardware that will calc them for you, and in some cases the algorythms used to determine visibility will even fail to show the visible part of the object. There are serious limitations to how it works and all the "solutions" for things like refraction, reflection, etc. are hacks. They are not mathematically accurate, they can't deal with complex situations with multiple cases of light bending or reflection, etc. They simply can't reproduce the same results. Hell, even high end applications like Maya, while they use some cheats for speed, and do use OpenGL previews, **still** usually do their final rendering pass using a raytrace algorythm. Others use other methods that approximate, since they are more interested in speed than realism. If 3D cards where so great, wouldn't you thing they would be using those exclusively?
Some things from the POV-Ray FAQ that are pertinent:
"3DNow uses single precision numbers while POV-Ray needs (yes, it needs) double precision numbers. Single precision is not enough (this has been tested in practice)."
This is true of pretty much anything, including OpenGL, when using the hardware's math system.
"3D-cards are not designed for raytracing. They read polygon meshes and then scanline-render them. Scanline rendering has very little, if anything, to do with raytracing. 3D-cards can't calculate typical features of raytracing as reflections etc. The algorithms used in 3D-cards have nothing to do with raytracing.
This means that you can't use a 3D-card to speed up raytracing (even if you wanted to do so). Raytracing makes lots of float number calculations, and this is very FPU-consuming. You will get much more speed with a very fast FPU than a 3D-card.
What raytracing does is actually this: Calculate 1 pixel color and (optionally) put it on the screen. You will get little benefit from a fast videocard since only individual pixels are drawn on screen."
While some of this is less true now, its still mostly true, since you still have to do a lot of footwork before hand to mimic the same results, or your are limited to like, one reflective surface, which can't reflect what is reflected in another nearby surface, etc.
You sacrifice realism and detail for speed. *period* If you don't need the speed, why the heck sacrifice the detail, just so you can use a card?
But, I don't know the full technical details, other than ones I already mentioned. You want a better explanation for why its not possible to interchange this stuff, talk to the POV-Ray developers. As for myself, its not any less trivial to impliment a decent scanline based system that **must** have a high end card to work right, than writing the purely math based raytracing system. And, the non-software based ones are only extendable when the cards improve, which is pretty damn meaningless in some cases, since why the hell would I want to include something like focal blur, if it forced everyone using my program to have Vista? (Its a DirectX 10 only feature on new cards.) I can do that fine in POV-Ray, and its unlikely to be horribly difficult to manage in any other software based system.
I don't know, maybe some hybred system would work faster and thus a bit better. But pure graphics card systems... No thanks. And frankly, I have had bad experience with OpenGL on my systems. Its also card hardware dependent and often the cards do not correctly support some OpenGL features, even though they say they do, causing OpenGL to use them when they are broken, or just don't support the features at all. You are still chasing the limitations of the hardware, not the algorythms, and it seems like card makers sometimes don't give a @#$$@# if OpenGL works right with them, as long as DirectX does. Not a good way to make something that you want available to the widest possible set of users, unless all you use it for is to draw the pixels and none of the 3D calculations.
---
And Shaun.
My specs:
AMD 64 3200+ -> 2Ghz (running in 32-bit mode, since 64-bit windows is.. nearly useless.)
2 GB memory
And well. Those are the only ones relevant to running POV-Ray, and the memory is pretty meaningless anyway, since it only becomes an issue with scenes that are ***way*** larger than those in the contest.
hrm... didn't think that the difference between our two chips would be that great. Ah well, as I said, more of an excuse for me to upgrade.
Out of curiousity, do you have a more recent link than the acm.org website? Most of the links I tried to follow were down, and the only working ones I could find were from several years ago. The interactive ray tracing project from utah.edu was interesting, but I'd like to see it on a modern processor, rather than an SGI Origin.
The one that caught my eye was at the end of the page:
Quote: Q: What are shadow buffers?
A: Shadow buffers (or shadow maps) contain Z-buffered data for the
scene as seen by the light, especially useful in RTRT with static
scenes flythroughs.
Implementation details and techniques are found in:
- "The shadow depth map revisited" by Andrew Woo,
in Graphics Gems III (though beware, this method has flaws - see the
next reference)
- Real-Time Rendering by E.Haines & T.Moeller
http://www.realtimerendering.com
- NVIDIA Developer's web site: "Shadow Mapping in OpenGL",
The first link has a lot of referances to OpenGL, and the second one is down. There's a lot of information here, and I understand very little of it. I was hoping that these two links could explain a bit more to me.
This is slightly off-topic (as is much of this discussion), but I wanted to let David Haley know that I am having trouble replying to emails from him. I am getting a message that my "from" email address (my address) is being "rejected by the server".
I am not sure which server this is, but suspect that somehow I have ended up on a spam blacklist. Naturally I don't send spam, but with forged mail headers, it is possible that spam looks like it has come from me, and thus my email address has been blacklisted.
That's really weird -- every rejected email is supposed to be reported to me, and I haven't seen anything from you at all in that list. I'll go double-check the list and try to figure out what is going on. When's the last time you sent an email? (It would help me have a more focused search.)
In the meantime, you can use the email I have on the forum: that one will probably work. One hopes... :)
Oh, ok. That would be why I hadn't seen it. It'll probably show up in tonight's logs.
I'll try looking for the rejected mail. It's probably around here somewhere, I'm just not sure where SpamAssassin puts these things. When I find it I'll be able to tell why it decided to reject it. And then I'll try figuring out how to put you on the server-side whitelist (you're already on mine).
Hey... you're already on the server-side whitelist, with your firstname@lastname.com.au address. It doesn't make sense that it would block your email. I'm confused...
This morning I enabled Spam Assassin at my web host provider (FutureQuest), in an attempt to cut down incoming spam, which currently swamps my inbox.
It appears that enabling this, stopped *outgoing* mail from me. This is kind of weird. I have turned it off, and now successfully sent an email to you.
That is indeed very strange and most probably not the expected behavior!
I got your email, this time. And in the spam report, no sign at all of your previous email, so I'm guessing it truly didn't make it past your server. How odd...
As for the contents of the email: in brief, very exciting. :-) Lots of things to think about, though. More via email later.
Quote: Out of curiousity, do you have a more recent link than the acm.org website?
Nope, sorry. I just did a google to find the page in the first place. Yes, more modern cards do support better hacks for some of this. The absolute latest ones can get **very** close to photorealism, if you a) want water or some other things to "generally" reflect/refract some stuff and b) your drivers work. The problem is, while DirectX rarely fails on any of this, OpenGL support on cards is far more spotty. Just as an example, a *basic* game called Globulation II I tried to run worked fine on the *prior* cards I had, which was 2-3 years older. Then they patched in some different code in a later version and it stopped working right at all. It now does work again with my new card, but... With OpenGL your constantly fighting to not just make sure you are using features that work on the widest set of cards, the most top of the line features are seldom if every correctly supported by OpenGL for the newest card, and even when it does, there is no way of knowing, until it fails, if the **Card** correctly supports that feature using OpenGL. We are basically dealing with cards that have two interface systems, one geared towards OpenGL, which too many of them still don't give a frack about, and DirectX, which MS is constantly pushing for new features for, like the new focal blur, then insisting OpenGL can't support, since its a DirectX 'only' feature.
This means that the only "reliable" OpenGL is either a) what works on your system, or b) what is 1-2 years behind the curve with respect to the latest hardware, so that it should work on "most" systems. This hardly helps someone trying to do things that *only* the latest and best cards can do correctly, if at all, and its another good reason to use a hybred or pure raytrace solution instead, if you want reliable results that everyone can see, never mind the hardware they have.
Oh, and the truly sad thing is, one of the problems stems from the fact that OpenGL is supposed to do at least some of the math itself, if the card doesn't support a feature. The problem is, the card may support it, will tell OpenGL it does, only... Its not actually supported in its OpenGL interfaces correctly, only in the DirectX implimentation. It all becomes quite annoying to even read about, never mind considering the pain coding for it might become when you have to start guessing what will actually work on which hardware and thus what the "minimum" card your program will need is.
I'll make one last comment on this whole graphics thing. You should not call OpenGL techniques "hacks". That is not only offensive to the immense amount of work that goes into the whole system, but more importantly completely ignoring the fact that two entirely different problems are being solved by photorealism ray-tracing and real-time graphics.
David, a lot of the stuff done in 3D are "hacks", even with things like global illumination (incorrectly labelled radiosity in POV-Ray). If you prefer, I can call them "Monte Carlo methods". Its still means, "We can't do this in a way that is physically identical to the real world, so we took a short cut. That you think "hack" means something negative says more about your perception of the term than what is in fact being used. In any case, its "less than optimal". This doesn't mean it doesn't work or that its not, in some cases, like G.I., the only currently workable solution.
And I am not ignoring the fact that the two do different things. I want accuracy for size of the data file. I don't mind if some cases even produce photo realism. I could care less about speed (mostly), because thats not meaningful if, for every small scene sent over the internet, I still have to waste time converting into something the "faster" method needs to do anything, while actually losing realism in the process. Faster is only faster if the data is *already* on the machine. If you have to build that data, along with all the secondary data to go with it, like textures (no images allowed, only procedural textures, again to save bandwidth), then you are not gaining anything (unless you consider the processing done to create the data and the disk space needed to store it for if you need it again "gaining").
Its not Second Life I am trying to build here, its something equivalent to still images that MXP can do *but* without the bandwidth issues of a 1MB image or the limitations of that being a pre-rendered image that can't change based on lighting. I mean, if you plan to show an image of a puzzle, you have two choices. Tell them they can't see it clearly, or *show* that they can't and they need more torch light, as just one example. Someone goes to a well at night, they don't see the lettering, as they would in the day (or the reverse, maybe it glows at night). If you want to *show* something, not just describe it..
And as I said, perhaps a hybred system would cover the issues I am trying to solve better than a pure one or the other.
But by all means, lets drop it. We are just going in circles here, when its basically just an argument over preferences and the possible issues both pose.
I think that the confusion for the "hacks" was David thinking that you were referring to OpenGL as a whole as a hackjob, when you meant that specific funtions are an inferrior shortcut any renderer.
And I think I finally get what you're trying to do. Feel free to correct me if I'm wrong. You're trying to create an addon to a client that would allow a user of a mud to view the room as a picture instead of (or in addition to) the description a mud would send out. This sounds like a pretty good idea, as long as rooms can be saved to the disk somehow. On slower computers rendering of the easiest images could take a few minutes, and a lot of people get tired of waiting. A lot of that could be taken care of with a decent amount of shorthand made by whoever is designing the client or script. Common items like a fire or a door could be shortened to an ID tag, with a placement near it. Like 371=2x20y7z0,0 for the id number, placement in a coordinate plane, and the direction it faces. Terrain types and the like could be taken care of in a similar manner, leaving only unique items for a room that would take up much space at all. Then the script just parses it all out into the longer format and chugs through the image rendering.
If the string is encrypted and the client takes care of everything in a proprietary binary file, you shouldn't even have to worry about people looking at the mxp string to "cheat" their way through seeing something they shouldn't. I'm picturing something like this for the room code for a cave with light coming from the entrance behind you (L10) a torch in a sconce on the wall(371) and a table with a sword on it (107 and 8761 respectively):
Basically, yes. But I would only save the "objects", so that something might include thing like:
using { "water\"
include "well.mob" as center_well}
sun_position { lat 50.045 time 14:43}
The first would pull in the script for a generic well, which you could then alter using:
object {center_well rotate <30,0,0>}
and other things, maybe even accessing sub-parts, so you could make the top use a tile pattern, instead of wood, etc.
Since the point is to allow certain specific things, like lighting, to be dynamic, you need to be able to re-do the image as needed. Some things, like adding rain or snow, could be done with OpenGL, after the main image exists, since the effect would be overlayed onto the image, not animated. However, some tweaks to the surfaces (specifically their reflection, etc.) might be used to make everything look "wet".
Its not full animation, you can't rotate it to look at it from some other angle, etc. But you *will* notice, if you set it to allow it, that the light angles and shadows change over time as the sun moves, or similar stuff. Mind you, the system could handle some of that using a database to store the objects using an ID, and even replace the objects on the user end with shorthand IDs too. The server end would see, "center_well", but the client would end up seeing, something like this (assuming you used a DB to store the objects, instead of a file in a directory):
The only difference with using the directory based system is the first section, which would specify a directory and the file name. The result above is pretty obscure, would be more so compressed and could be made more compact than even that, with something like hexidecimal values for the numerics. And, its still expandable back to the original if needed.
Stuff like how sun position and others work would be entirely client/server dependent, so even if you decoded the script, you wouldn't be able to immediately figure out how it worked. And.. I don't necessarilly care if they did anyway personally. If someone was that worried, they could always use an encrypted system on the database and some added security in a client that supported the feature.
Now, wasn't thinking much in terms of terrain. There are some versions that could be produced using algorythms and a feature called "height fields", but if someone "had" to use them, they could use a bitmap to produce the height field too, it just means you send extra time downloading a file that contains the image the field is made from. This however is a bit of a problem, since it means you can't send it over the connection without extra lag (a good image would need to be at least 640x480 and a fair amount of color depth (monocrome only being practical if you have the same "depth", i.e. bits, but no color, which some uncompressed formats do, but at the expense of the file being like 10-20 times bigger).
Quote: Some things, like adding rain or snow, could be done with OpenGL, after the main image exists, since the effect would be overlayed onto the image, not animated.
OpenGL is not the most appropriate tool for adding pixels to an already rastered image. It's overkill and not what OpenGL is supposed to do. And besides, any technique will not be aware of the 3d contents of the scene, and so is likely to produce less than optimal results.
Seems to me that if you want rain or snow, you should just do it in your render.
Of course, since you seem really set on (at least quasi-)photo-realistic ray-tracing, you will have the problem of a slower and slower render...
Quote: Basically, yes. But I would only save the "objects", so that something might include thing like:
using { "water\"
include "well.mob" as center_well}
sun_position { lat 50.045 time 14:43}
The first would pull in the script for a generic well, which you could then alter using:
object {center_well rotate <30,0,0>}.
ummm... that's exactly what I said earlier. Since you didn't notice, in the example I showed, it had sunlight coming through the opening, and the direction each item is facing. The time is also a weird idea for the client to deal with in regards to celestial bodies, since it would be easier for the server to just figure that out in order to deal better with different worlds. Some might have two or three suns or moons travelling at different speeds. Ambiant city light at different times would also be better server side. Those are things that can just be looked up in an array or hash table quite quickly.
Quote: Since the point is to allow certain specific things, like lighting, to be dynamic, you need to be able to re-do the image as needed. Some things, like adding rain or snow, could be done with OpenGL, after the main image exists, since the effect would be overlayed onto the image, not animated. However, some tweaks to the surfaces (specifically their reflection, etc.) might be used to make everything look "wet".
Its not full animation, you can't rotate it to look at it from some other angle, etc. But you *will* notice, if you set it to allow it, that the light angles and shadows change over time as the sun moves, or similar stuff.
Adding rain or snow into the image after with OpenGL instead of just having the rederer do that would require one of those suboptimal hack jobs you were mentioning earlier.
Also once you start doing things like rotating an item, or moving the light source, you might as well just rerender the whole image, since that will change shadows and reflections on any decently populated room, and on slow computers, it can just re-request an update when it's done rendering (or after a 30 second delay if there is no change). Better updating would also allow for things like a ring of mushrooms appearing at midnight for an hour, or a door that disappears if the light is too bright to be dealt with easier. And with the compressed code, it wouldn't require much bandwidth at all.
And for everything after that point (since I'm not going to copy and paste the rest of the post, you are just repeating everything that I had said, aside from me forgetting to explain the "cave4" bit as being a full room with a height bitmap and a few standard terrain features that is stored by the client. Reusability is a key factor in making a program smaller and more efficient.
Also, beware of obscurement in anything you do... it's a double edged sword. Not only will you be protecting your data from people who want to crack it better, but you will make it much harder to read for when you or someone else has to go fix something.
Aside from tossing this into a script to pass the data over to yet another program, I'm still confused how this would be done in almost any client other than MUSHclient. It would be far simpler to just make your own client and have all of this embedded into it, especially if someone decides to move rooms before an image is fully rendered, and the client will have to figure out what to do with that unfinished process. The main advantage I can see about using a proprietary client instead of a mud client is that it would be easier to deal with adding unique items or doing updates, since it could download new patches at connection, or backgrounded throughout the runtime.
Quote: Adding rain or snow into the image after with OpenGL instead of just having the rederer do that would require one of those suboptimal hack jobs you were mentioning earlier.
PUtting aside the whole "can't make pretty pictures with OpenGL" and "can't procedurally specify for OpenGL" issues, it's worse than that. If all you're trying to do is add a simple overlay of snowflakes, or rain-drop lines, it would be silly to use OpenGL for that (you would get much better results using, say, the ImageMagick library). But if you want the weather to actually look right -- e.g., having fog in the scene due to the rain or snow -- you will need the original 3d data (in particular the depths) to even have a hope of having the render look right.
See. The issue still becomes speed vs. realism then. Fog.. Is simple and can be done in the trace. Rain and snow, could too, but the methods really are little more than overlays, not true 3D. There is no light interactions, etc. At most, you *might* have 3D positioned "splashes" in the scene, but the rain doesn't do anything but just sit over the image and its not effectively different than making the far rain more transparent than the close, so it "seems" like the drops are bigger close up. Snow.. Is a tad different, but only in that its not going to fall in a linear path all the time or as fast and you need distinct flakes, not what basically amounts to streaks on the screen. Rain in a 3D card isn't rendered, its just slapped on as a layer effect, which is easy enough to manage and has been done since the days of the PSOne and simple isometric games (with fairly realistic effect).
As for having the client handle things like sun positions, etc. You could have more than one sun position, effects to alter how "bright" they are, etc. But its the render engine that needs to deal with it. The server end is figuring out certain details, but the more information you have to add, such as what "angle" the sun needs to be at, etc., the more stuff you have to send through the pipe. Its useful to avoid having to feed too much extra stuff through, if you don't have to.
Actually in several games rain and snow are treated with a particle engine. I'm not sure how exactly you are using the term "render", but the rain/snow particles are not slapped on at the end, rather, the particles are actually rendered based on their positions as specified by the particle engine.
Of course, other games -- ones that don't necessarily need rain that looks like it's in the scene, especially 2d isometric games -- choose to simply overlay rain as streaks drawn on top of the picture, usually with alpha blending of some kind. So you are right for some cases but your statement cannot be generalized to all rain rendering.
And actually, if you look at some really fancy rendering of rain in 3d art, it is also rendered using a particle engine of sorts, and not slapped on either; that kind of rain looks best because it actually glints with light and good stuff like that. It also varies in density on the screen depending on how "deep" you can see down a particular line; if you run into a tree you will have less rain, but if a line of sight goes on for a while there will be more rain visible. And again, the rain has depth, so this effect looks more or less realistic.
Quote: the more stuff you have to send through the pipe. Its useful to avoid having to feed too much extra stuff through, if you don't have to.
I think you're worrying a bit too much about the data rate here. Specifying the sun's x, y and z angles only takes a few bytes. As long as the order of magnitude stays within the kilobytes instead of the tens, hundreds of kilobytes or megabytes, there is no problem.
how exactly is "L10=-100x0y20z#FFFFFF" a lot of data through a pipe? It takes care of the intensity "L10", position, "-100x0y20z" and the colour "#FFFFFF" in just a few bytes. Even before compression, that's less than the client saying "You have faint light coming from the mouth of the cave." This also takes care of the fact that you are not always facing in the same direction in each room, nor will the sunlight be visible from the same angle. In the cave example, the light is coming from the mouth of the cave regardless of the position of the sun in the sky.
If you look at World of Warcraft, it does an incredible job of rendering believable graphics in realtime. Take a look at this example:
This has been sampled down to save space, the original is better quality.
Notice the realistic-looking road, with trees that throw shadows. Interestingly the two characters on the screen do not throw sideways shadows (players and mobs have a small circular shadow under them at all times).
The light in the foreground (yellow flame) evidently uses a particle generator, because it flickers and moves all the time.
This is drawn in real time, about 40 to 60 frames per second, and you can change the point of view (camera) instantly by dragging with the mouse.
Many zones have an "atmosphere" which I think is just a coloured overlay (eg. yellow in a desert, green in a swamp).
They also have rain that, from memory, seems to splash as it hits the ground.
I get the strong impression it is a compromise between speed and photo realism - it really has a slight cartoony feel, but the important thing from the enjoyment point of view is that it is fast. Who wants really sluggish, but highly realistic, frames?
WoW graphics are pretty good, yes, but Oblivion is even better -- IMHO. :-)
Other good examples of very impressive (real-time) renders can be found at www.Ogre3d.org.
What it comes down to is that OpenGL can draw some very impressive scenes. Of course, things like light refraction/reflection are slower, but that's no fault of OpenGL per se, really, but the very nature of the computations needed to get that stuff right. (It's no secret why it takes ray-tracers so long to render scenes.)
I think atmospheres (like a yellow swamp feel) are typically rendered with some kind of overlay that is more opaque as distance from the camera grows. It's kind of like fog, although proper fog has some more complicated stuff behind it.
Note the slight shadow under the player, the light on the wall flickers and illuminates the wall, and you can see daylight coming in the door in the middle (with the guard walking past).
Also, the player's staff has a blue glow that shimmers and moves.
The yellow light on the top-left corner throws a yellow glow that brightens the scene near it, if you are close to it.
Probably the rendering is not mathematically exact, but it "feels right".
WoW graphics are pretty good, yes, but Oblivion is even better ...
Yes, however with a couple of disclaimers.
First, I found that the exact PC and graphics card that rendered WoW fine, was very sluggish under Oblivion, and thus required an update. So, the better graphics came at a cost. If you didn't get the upgraded graphics card, it looked worse, because you had to degrade the drawing configuration.
Second, I find that the more photo-realistic the rendering is, the more you expect, and the more you notice things like sharp borders between (say) objects like players, and scenery, which should really be rendered with anti-aliasing to look perfect.
I also find that with very realistic rendering, you notice other things, like the face which looks like a photo with a moving mouth.
However, if the overall approach is a "cartoon feel", then you expect mouths and eyes to move in a "cartoon way", so they look better - if you see what I mean.
Oh, you're entirely right; Oblivion requires a significantly more powerful computer to look right on. The computer I'm using now was built more or less specifically with Oblivion in mind. (Well, ok, not really; I also wanted it to be very fast for compiling and the like, and just fast in general.)
You're also right that the better something looks -- or rather the more it tries to be realistic --, the more demanding the viewer is. Oblivion suffers from this when it comes to dialog with NPCs, which is probably why you mentioned faces and moving mouths.
I think the big thing is that having a cartoon look and feel (or, really, any kind of stylized look and feel) puts the viewer into a different frame of mind, one more willing to accept slight problems (with respect to strict physical realism) because one is not looking for perfection to begin with.
Exactly. It is like watching an old black-and-white movie. After the initial shock of not seeing colour, your mind adapts, and you get involved in the plot (if it has one). In fact, the monochrome look can have an atmosphere of its own, and some recent movies have been shot in monochrome (eg. Schindler's List).
However if Hollywood tries to "improve" an old black-and-white movie by "colourizing" it, for me at least, the effect is usually worse. Now, since colour is present, I expect it to be good colour - often it isn't. Also, you notice problems in the process where faces are slightly gray. And you expect colour to be used "properly", eg. for dramatic effect.
It is the same with attempts to do photorealistic rendering - if it looks like we are trying to render "real" scenes, and "real" people, then we are raising the bar of expectation. We also expect smooth action. At present, as far as I can see, we don't really have that.
Some of the modern rendered films look very good, and the people in them are starting to look real and not plastic, but they are rendered offline by very fast processors.
It includes a OpenGL patch for an unofficial version that, at least partly, supports using OpenGL to render POV-Ray scenes. However, its not going to produce "quite" the same quality. Its also "incomplete", without proper texture support for solid rendering (the final scene result), etc. Basically, you get (wireframe), full render + wireframe, or full render. No actual OpenGl rendering.
Note, it has a statement on the CSG issue, which imho is the "biggest" problem with using non-raytrace. Specifically, he states:
"CSG is by its very nature almost trivially easy for a raytracer to do, and consequently, almost impossible to get a mesh equivalent."
This is the crux of the problem. If you want to limit the amount of junk you send down the pipe, you need to use primitive, but if you use them, then you are stuck doing lots of extra work either a) using software tracing or b) using various methods to attempt to approximate the effect of the CSG, so that you get the same result in a mesh. The time you gain by not rendering is lost again in generating the mesh itself. And a detailed scene might have 50+ objects you need to CSG to produce the final result.
Another interesting animal:
http://www.slimeland.com/raytrace/
Written in JavaScript.
Hard to find a link, but some people have taken data from things like WoW and rendered them in POV-Ray, with much improved results. In fact, finding a link is driving me nuts. lol
Anyway, think this is about exhausted as a topic. Short of coding a system and then fiddling with just what you "need" to make it all work, its hard to predict if it will work, or what limitations end up getting in the way (especially with bandwidth if someone is not using broadband).
I do hope that one day this sort of stuff will become possible using a card though:
That "OpenGL rendering" is the thing that's been keeping me perpetually confused by this thread. Do you mean by that using programmable shaders on the GPU? I am only aware of the dichotomy between "software" and "hardware" rendering, but not "POVRay" and "OpenGL" rendering.
