Furthermore, if it weren't real time, what web application would set up a scene, let users move lights and stuff around, and then tie up their computer to slowly render a result. The motivation for this is not to be a 3d modeler within the browser. The motivation is to embed interactive 3d graphics in websites. For instance, in TFA they explain that they demoed an application where a viewer of the venice wikipedia page could "visit" a cathedral in venice and look around the scene. The point is definitely NOT to allow users to change lighting or material properties, it is to allow rich 3D content to be delivered via a web page which requires real time. That is why they say they are using a real time renderer. Or did you miss that?
Ok, Rockoon. Let's lay it out. I write ray tracers as part of my job. I am studying this stuff very in depth. I understand what a ray tracer is, how to design one, how to write one. I also know how to use rasterization techniques like imperfect shadow maps. I know the methods behind SSAO, SSDO, etc. My original question was not meant to be an argument, it was meant to be a discussion topic. You clearly did not read the announcement. The announcement said that this is a "REAL TIME" ray tracer. Now I am pretty sure, given the current state of the art, that real time ray tracers don't give you the same quality as rasterization methods. And by quality here I mean it in a subjective sense, since a rasterizer generates a gross approximation. The quality is only how good that approximation looks to a viewer.
They will in the future, but they don't now. So there are two questions. (1) If you care about real time, why not implement a rasterization method for now and worry about ray tracing in a few years when it is better (now I'm not saying that you should do this, I'm asking for good and not asshole reasons for doing it)? (2) If you don't care about real time, why not render it on a server and send the result? A user most definitely COULD change scene properties and still have it rendered on a server. In fact, some game companies are working on systems to do just that--everything rendered remotely and only the results are sent across the network.
The real question, though, is not what the difference is between ray tracing and rasterization. That is pitifully obvious to anyone even slightly versed in the field (you seem to know enough to be dangerous yourself). The question is why do I want a real time ray tracer in my browser over a rasterizer. The reason I'm asking this is not that I hate ray tracers. The reason I'm asking this is not because I don't understand them. The reason is that given the current state of the art it appears that ray tracers don't render the quality at real time speeds that rasterizers do, but this might be wrong. So I asked the question in order to find out if there are papers out there for GPU ray tracing algorithms that produced high quality results (since I haven't seen any). I was hoping that people who knew would helpfully post some papers so I could read them. You unhelpfully decided to bash me when you don't even know who I am or what I study and you clearly misinterpreted my questions.
So you could helpfully post some academic papers detailing real time ray tracers that perform well and do more than can be done in a rasterization based solution, or go home.
First, I impose the real time requirement because the announcement says that it is a real time ray tracer, which means they are claiming real time. If what you say is true, and it is only getting 1fps then it isn't even really interactive time (which is slower than real time). Second, why would you want an embedded ray tracer that wasn't real time? Wouldn't it be better to simply render the images offline somewhere else and then serve the rendered images? What advantage do you get from rendering on the fly if you can't actually interact with the scene in a meaningful way in real time?
Do you have the paper title and/or do you know what journal or conference it was published in?
Also, the big thing that makes me somewhat skeptical about realtime ray tracing is that it doesn't lend itself to good GPU algorithms since it is inherently divergent. Anyway, thanks for the good info.
I definitely agree that ray tracing allows us to model light transport physics in ways that will never be available in rasterization.
Of course there are other methods, like light fields...
I read that, actually, thanks. Still doesn't tell me what its quality is compared to good rasterization techniques. The next post after yours is much more helpful, however.
This has a really misleading title. I think it should read, "Typical Windows User Needs to Patch Every Five Days." The article clearly states that people are NOT doing this. FTA: "Few consumers devote the time and attention necessary to stay atop the patching job." That means the typical user is not patching every five days.
I understand that ray tracers are better than rasterizers in terms of simply modeling real light transport, but I don't think that realtime ray tracers even come close (I could be very wrong, and if so I'd like paper refs because I'm studying this area at the moment). Some error in the rasterizer is ok as long as it looks good, it doesn't have to be physically plausible. As soon as you start adding ray traced inter-reflection, refraction, global illumination and such you are well outside the realm of a realtime ray tracer (I believe, I'm willing to bet I'm wrong, and I believe that one day we will have realtime ray tracers, I just don't think we're there yet). I don't see how this RT Fact can incorporate interesting effects and still be realtime. If this is the case, it seems we might as well just use a rasterizer.
Yes, Rasterization vs. Ray Tracing presents a trade-off between speed and quality. Obviously truly ray traced scenes with nicely modeled materials and light sources will produce better images than rasterization. In this case, however, we are not talking strictly about ray tracing vs. rasterization. We are talking about real time ray tracing vs. rasterization. Real time, meaning that we are assuming a lower bound of, say, 15 fps (this is pretty poor, but just to pick one). At that speed (or faster) rasterization beats real time ray tracers in terms of quality, especially when it comes to renderers that can't be tuned for a specific app (i.e. a browser based viewer that needs to be able to render a general, user created scene vs. a game that knows what its scenes will look like and can tune things so that the features used are fast in deference to other features).
On top of that you can do some tricks with the rasterization to fake lots of ray traced effects like caustics, global illumination, glossy-glossy reflections, etc.
Maybe, the thought, just to give a potential answer to my question above, is that the 3D window in the browser will be resolution limited enough (say 400x400 pixels) that ray tracing will begin to make more sense. But in this sort of case the differences between rasterization with some of the tricks built in and ray tracing will probably not be noticable.
Anyway, I still want the question answered. As far as I know (and I'm a graphics researcher--though a relatively new one, so I'm still learning) real time ray tracing is really not nearly as good as rasterization in terms of quality for a real time frame rate on reasonably fast consumer hardware. If I'm wrong, please post links to academic papers detailing the high quality fast ray tracers, because I'd like to add them to my "to read" queue.
That may or may not be true. On the one hand the GPU doesn't have an OS so there isn't any protection of memory from any program which seems like exploitation might be pretty trivial, but GPU code doesn't have access to the disk drives or to CPU memory, so it would be hard to craft an exploit that did anything other than crash the machine. IMO.
Why would they choose real time ray tracing over rasterization methods? Rasterization is still much faster and you can achieve all kinds of ray tracing like effects if you want to.
In the article they said they demoed a version of the wikipedia page for Venice and a user could walk around a scene of one of Venice's cathedrals in browser. That is pretty cool, but I agree it will go through the same thing that flash and midi music went through when they got added to the browser: there will be overuse everywhere for 5-10 years until web designers finally take back control from their clients and get back to designing good looking useful interfaces that only use 3D scenes when it really makes sense.
"a large part of the classical music is religious."
Are you sure about that? Most classical music doesn't even have words, so it can't really be considered overtly religious (maybe the intentions of the creator were to worship God through the creation of the piece, but if that were the definition of religious than lots of buildings, architecture, TPS reports and all sorts of things would suddenly become "religious").
Plus, many great classical composers were not really religious at all.
Reread that sentence. He didn't say anything about "morals," he said "mores" which is an entirely different word. Not saying you don't have an argument, but I think you are mis-targeting a bit.
We need parents be more responsible about raising their kids so they don't get into fistfights every time they gather. The problem got so bad at a local mall that they now won't let kids loiter outside the building, they have to wait until their ride comes (apparently if they are loitering around outside they get in more fights).
Why can't they just put a high res image in the background? That's what most people probably change it to anyway.Nobody wants an ugly purple and orange gradient.
"We know why children labor -- because the rich aren't willing to pay enough for a man to feed his family under his own pay. So what are the alternatives?"
Or because dad's dead and mom's debilitated. Most countries have the teenagers help out in the fields even if they don't get work in the factories. In fact, most western countries did that not so long ago. I agree with the OP above that this is less black and white than we make it out to be. A 15 year old works in a factory because it helps feed his family and that is the least heinous way for him/her to do it. If the family were already sufficiently fed, it wouldn't be happening. The problem, then, shouldn't be stated as "these countries have child labor and we should hand down our western view that this isn't okay" and more stated as "these countries are so poor that even their children have to go to work, how can we help them to become prosperous enough that this isn't required?" Simply not allowing that to happen is not the solution. What needs to happen is overall economic improvement of the country FIRSTLY, then work to lessen teenage labor since it is no longer necessary SECONDLY.
It is easy for us, as westerners in developed countries, to say, "Hey we don't need child labor and we think it is kind of icky so we are going to force you not to have it." It is a lot more difficult to say "we recognize child labor is a huge problem and that the underlying problem is poverty, so instead of trying to force our laws down your throat we will try to help you out of poverty while being sensitive to where you are economically and culturally so that we can gradually negate the need for these injustices."
Note that I am not saying that child labor is okay or that it is the way for a nation to grow up more quickly. What I am saying is that we need to treat the cause not the symptoms. Simply requiring countries not to have child labor is akin to lancing spots of a person with chicken pox. Sure we remove the pox from their skin, but they are left with chunks of their skin taken out and they still have the chicken pox. The only sustainable solution, then, is to treat the disease, and as it goes away we can treat the symptoms as well.
where profit_I_can_get_away_with is related to demand/supply
You always have to cover your operating_cost, however. Gas stations have thin margins so there does come a point where raising wages requires a raise in cost.
I mean, just do a quick mental experiment. Let's say you raise someone's wage to more than the net profit of the entire shop. Obviously you would have to raise prices.
Also, you are only citing gas price difference between New Jersey and Pennsylvania as "evidence" for your argument. First: gas stations don't make that much money on gas. They make money on the stuff inside of the gas station. The gas is merely a way to attract customers to come and pay for candy and soda, etc. To make the argument you are making you need to compare average profit margins, so check out the average markup across all items at the gas stations in each state and report back to us.
Second: you haven't shown whether Pennsylvania gas stations pay their attendants more or less. If they pay more, then it would actually support the people arguing against you, because higher prices and higher wages would be related.
Third: even if the wages were the same between the two states it may be more expensive, in terms of taxes, for a company to have an employee in Pennsylvania which would eat up its operating budget and require it to pay its employees less than it otherwise would.
Bottom line: your comparison of gas prices is a red herring and does not get even close to proving your point. A lot more in depth analysis of operating budgets and profit margins is needed to make the argument that gas stations can raise wages without raising prices--something that I think is probably a pretty dubious claim.
"I'm still amazing [sic] that people don't cover the num-pad when in shops. There are CCTV cameras everywhere."
You know, I hadn't thought of that until you just said it. Now I'm not sure whether to thank you, for pointing it out and making me more security conscious, or hate you for making me more paranoid. That totally blew my mind. (By the way, this is not sarcasm, I really hadn't thought of that).
When I moved to London I was told to only use ATMs inside of banks, or get to know the look of an outdoor ATM very well so that you can tell if something has changed about it. I knew a lot of people who got scammed by the skimmers, but I never did. I used the same ATM unless it was one inside a bank, and I always covered my hand completely to enter my pin and even made a few false gestures to look like I was pressing other buttons.
That's true, but if you are using a credit card there is no pin. Or if you, as I often do, run your debit card as credit then the gas pumps rarely ask for a pin. In these cases a camera isn't needed. Of course, this all goes to your point: I probably should be making sure that I enter my pin (by using my debit card) and then cover my hand to protect it. I think the camera is just a bonus. If they get your pin, then they can empty your bank account. If they don't, they can still flash a fake card with your card's information and use it as a credit card (except for online purchases which would require that 3-digit printed number from the back of the card).
Slashdot Mirror
Furthermore, if it weren't real time, what web application would set up a scene, let users move lights and stuff around, and then tie up their computer to slowly render a result. The motivation for this is not to be a 3d modeler within the browser. The motivation is to embed interactive 3d graphics in websites. For instance, in TFA they explain that they demoed an application where a viewer of the venice wikipedia page could "visit" a cathedral in venice and look around the scene. The point is definitely NOT to allow users to change lighting or material properties, it is to allow rich 3D content to be delivered via a web page which requires real time. That is why they say they are using a real time renderer. Or did you miss that?
Ok, Rockoon. Let's lay it out. I write ray tracers as part of my job. I am studying this stuff very in depth. I understand what a ray tracer is, how to design one, how to write one. I also know how to use rasterization techniques like imperfect shadow maps. I know the methods behind SSAO, SSDO, etc. My original question was not meant to be an argument, it was meant to be a discussion topic. You clearly did not read the announcement. The announcement said that this is a "REAL TIME" ray tracer. Now I am pretty sure, given the current state of the art, that real time ray tracers don't give you the same quality as rasterization methods. And by quality here I mean it in a subjective sense, since a rasterizer generates a gross approximation. The quality is only how good that approximation looks to a viewer.
They will in the future, but they don't now. So there are two questions. (1) If you care about real time, why not implement a rasterization method for now and worry about ray tracing in a few years when it is better (now I'm not saying that you should do this, I'm asking for good and not asshole reasons for doing it)? (2) If you don't care about real time, why not render it on a server and send the result? A user most definitely COULD change scene properties and still have it rendered on a server. In fact, some game companies are working on systems to do just that--everything rendered remotely and only the results are sent across the network.
The real question, though, is not what the difference is between ray tracing and rasterization. That is pitifully obvious to anyone even slightly versed in the field (you seem to know enough to be dangerous yourself). The question is why do I want a real time ray tracer in my browser over a rasterizer. The reason I'm asking this is not that I hate ray tracers. The reason I'm asking this is not because I don't understand them. The reason is that given the current state of the art it appears that ray tracers don't render the quality at real time speeds that rasterizers do, but this might be wrong. So I asked the question in order to find out if there are papers out there for GPU ray tracing algorithms that produced high quality results (since I haven't seen any). I was hoping that people who knew would helpfully post some papers so I could read them. You unhelpfully decided to bash me when you don't even know who I am or what I study and you clearly misinterpreted my questions.
So you could helpfully post some academic papers detailing real time ray tracers that perform well and do more than can be done in a rasterization based solution, or go home.
First, I impose the real time requirement because the announcement says that it is a real time ray tracer, which means they are claiming real time. If what you say is true, and it is only getting 1fps then it isn't even really interactive time (which is slower than real time). Second, why would you want an embedded ray tracer that wasn't real time? Wouldn't it be better to simply render the images offline somewhere else and then serve the rendered images? What advantage do you get from rendering on the fly if you can't actually interact with the scene in a meaningful way in real time?
Do you have the paper title and/or do you know what journal or conference it was published in?
Also, the big thing that makes me somewhat skeptical about realtime ray tracing is that it doesn't lend itself to good GPU algorithms since it is inherently divergent. Anyway, thanks for the good info.
I definitely agree that ray tracing allows us to model light transport physics in ways that will never be available in rasterization.
Of course there are other methods, like light fields...
I read that, actually, thanks. Still doesn't tell me what its quality is compared to good rasterization techniques. The next post after yours is much more helpful, however.
This has a really misleading title. I think it should read, "Typical Windows User Needs to Patch Every Five Days." The article clearly states that people are NOT doing this. FTA: "Few consumers devote the time and attention necessary to stay atop the patching job." That means the typical user is not patching every five days.
I understand that ray tracers are better than rasterizers in terms of simply modeling real light transport, but I don't think that realtime ray tracers even come close (I could be very wrong, and if so I'd like paper refs because I'm studying this area at the moment). Some error in the rasterizer is ok as long as it looks good, it doesn't have to be physically plausible. As soon as you start adding ray traced inter-reflection, refraction, global illumination and such you are well outside the realm of a realtime ray tracer (I believe, I'm willing to bet I'm wrong, and I believe that one day we will have realtime ray tracers, I just don't think we're there yet). I don't see how this RT Fact can incorporate interesting effects and still be realtime. If this is the case, it seems we might as well just use a rasterizer.
Yes, Rasterization vs. Ray Tracing presents a trade-off between speed and quality. Obviously truly ray traced scenes with nicely modeled materials and light sources will produce better images than rasterization. In this case, however, we are not talking strictly about ray tracing vs. rasterization. We are talking about real time ray tracing vs. rasterization. Real time, meaning that we are assuming a lower bound of, say, 15 fps (this is pretty poor, but just to pick one). At that speed (or faster) rasterization beats real time ray tracers in terms of quality, especially when it comes to renderers that can't be tuned for a specific app (i.e. a browser based viewer that needs to be able to render a general, user created scene vs. a game that knows what its scenes will look like and can tune things so that the features used are fast in deference to other features).
On top of that you can do some tricks with the rasterization to fake lots of ray traced effects like caustics, global illumination, glossy-glossy reflections, etc.
Maybe, the thought, just to give a potential answer to my question above, is that the 3D window in the browser will be resolution limited enough (say 400x400 pixels) that ray tracing will begin to make more sense. But in this sort of case the differences between rasterization with some of the tricks built in and ray tracing will probably not be noticable.
Anyway, I still want the question answered. As far as I know (and I'm a graphics researcher--though a relatively new one, so I'm still learning) real time ray tracing is really not nearly as good as rasterization in terms of quality for a real time frame rate on reasonably fast consumer hardware. If I'm wrong, please post links to academic papers detailing the high quality fast ray tracers, because I'd like to add them to my "to read" queue.
That may or may not be true. On the one hand the GPU doesn't have an OS so there isn't any protection of memory from any program which seems like exploitation might be pretty trivial, but GPU code doesn't have access to the disk drives or to CPU memory, so it would be hard to craft an exploit that did anything other than crash the machine. IMO.
RT Fact is a GPU ray tracer, I think.
Why would they choose real time ray tracing over rasterization methods? Rasterization is still much faster and you can achieve all kinds of ray tracing like effects if you want to.
In the article they said they demoed a version of the wikipedia page for Venice and a user could walk around a scene of one of Venice's cathedrals in browser. That is pretty cool, but I agree it will go through the same thing that flash and midi music went through when they got added to the browser: there will be overuse everywhere for 5-10 years until web designers finally take back control from their clients and get back to designing good looking useful interfaces that only use 3D scenes when it really makes sense.
"a large part of the classical music is religious."
Are you sure about that? Most classical music doesn't even have words, so it can't really be considered overtly religious (maybe the intentions of the creator were to worship God through the creation of the piece, but if that were the definition of religious than lots of buildings, architecture, TPS reports and all sorts of things would suddenly become "religious").
Plus, many great classical composers were not really religious at all.
Reread that sentence. He didn't say anything about "morals," he said "mores" which is an entirely different word. Not saying you don't have an argument, but I think you are mis-targeting a bit.
We need parents be more responsible about raising their kids so they don't get into fistfights every time they gather. The problem got so bad at a local mall that they now won't let kids loiter outside the building, they have to wait until their ride comes (apparently if they are loitering around outside they get in more fights).
They should use Barry Manilow. Nobody would care if the youth of Britain hated his music.
I'd say go to interfacelift.com and pick one. People can change it later, but at least it will look nice out of the box.
Why can't they just put a high res image in the background? That's what most people probably change it to anyway.Nobody wants an ugly purple and orange gradient.
Hahaha how cute. This college student knows even less than the high school student he is making fun of and so resorts to mudslinging. And smug as we
"We know why children labor -- because the rich aren't willing to pay enough for a man to feed his family under his own pay. So what are the alternatives?"
Or because dad's dead and mom's debilitated. Most countries have the teenagers help out in the fields even if they don't get work in the factories. In fact, most western countries did that not so long ago. I agree with the OP above that this is less black and white than we make it out to be. A 15 year old works in a factory because it helps feed his family and that is the least heinous way for him/her to do it. If the family were already sufficiently fed, it wouldn't be happening. The problem, then, shouldn't be stated as "these countries have child labor and we should hand down our western view that this isn't okay" and more stated as "these countries are so poor that even their children have to go to work, how can we help them to become prosperous enough that this isn't required?" Simply not allowing that to happen is not the solution. What needs to happen is overall economic improvement of the country FIRSTLY, then work to lessen teenage labor since it is no longer necessary SECONDLY.
It is easy for us, as westerners in developed countries, to say, "Hey we don't need child labor and we think it is kind of icky so we are going to force you not to have it." It is a lot more difficult to say "we recognize child labor is a huge problem and that the underlying problem is poverty, so instead of trying to force our laws down your throat we will try to help you out of poverty while being sensitive to where you are economically and culturally so that we can gradually negate the need for these injustices."
Note that I am not saying that child labor is okay or that it is the way for a nation to grow up more quickly. What I am saying is that we need to treat the cause not the symptoms. Simply requiring countries not to have child labor is akin to lancing spots of a person with chicken pox. Sure we remove the pox from their skin, but they are left with chunks of their skin taken out and they still have the chicken pox. The only sustainable solution, then, is to treat the disease, and as it goes away we can treat the symptoms as well.
Sorry but, Price != demand/supply, it is related to demand/supply but it would more accurately be characterized by something like
Price = operating_cost + profit_I_can_get_away_with
where profit_I_can_get_away_with is related to demand/supply
You always have to cover your operating_cost, however. Gas stations have thin margins so there does come a point where raising wages requires a raise in cost.
I mean, just do a quick mental experiment. Let's say you raise someone's wage to more than the net profit of the entire shop. Obviously you would have to raise prices.
Also, you are only citing gas price difference between New Jersey and Pennsylvania as "evidence" for your argument. First: gas stations don't make that much money on gas. They make money on the stuff inside of the gas station. The gas is merely a way to attract customers to come and pay for candy and soda, etc. To make the argument you are making you need to compare average profit margins, so check out the average markup across all items at the gas stations in each state and report back to us.
Second: you haven't shown whether Pennsylvania gas stations pay their attendants more or less. If they pay more, then it would actually support the people arguing against you, because higher prices and higher wages would be related.
Third: even if the wages were the same between the two states it may be more expensive, in terms of taxes, for a company to have an employee in Pennsylvania which would eat up its operating budget and require it to pay its employees less than it otherwise would.
Bottom line: your comparison of gas prices is a red herring and does not get even close to proving your point. A lot more in depth analysis of operating budgets and profit margins is needed to make the argument that gas stations can raise wages without raising prices--something that I think is probably a pretty dubious claim.
"I'm still amazing [sic] that people don't cover the num-pad when in shops. There are CCTV cameras everywhere."
You know, I hadn't thought of that until you just said it. Now I'm not sure whether to thank you, for pointing it out and making me more security conscious, or hate you for making me more paranoid. That totally blew my mind. (By the way, this is not sarcasm, I really hadn't thought of that).
When I moved to London I was told to only use ATMs inside of banks, or get to know the look of an outdoor ATM very well so that you can tell if something has changed about it. I knew a lot of people who got scammed by the skimmers, but I never did. I used the same ATM unless it was one inside a bank, and I always covered my hand completely to enter my pin and even made a few false gestures to look like I was pressing other buttons.
That's true, but if you are using a credit card there is no pin. Or if you, as I often do, run your debit card as credit then the gas pumps rarely ask for a pin. In these cases a camera isn't needed. Of course, this all goes to your point: I probably should be making sure that I enter my pin (by using my debit card) and then cover my hand to protect it. I think the camera is just a bonus. If they get your pin, then they can empty your bank account. If they don't, they can still flash a fake card with your card's information and use it as a credit card (except for online purchases which would require that 3-digit printed number from the back of the card).
First flash is blamed for most application crashes on the Mac. Now PDFs are the number one vector for malicious code in Q4 '09. Hard month for Adobe?
Would that mean that the problem would be just as prevalent with eInk?