I have some older shaders running on GLSL 1.2 in which I'm using the shadow2DProj function (which I understand is now deprecated). Is there a way to control how many samples it uses for its filtering, and how spread apart those samples are? Right now, the shadow that I'm seeing is slightly blurred on the edges, but the jaggies are still extremely obvious. Way more than what I'm used to.
CDPropMember Since 07 Mar 2007
Offline Last Active Dec 07 2013 03:59 PM
- Group Members
- Active Posts 591
- Profile Views 3,344
- Submitted Links 0
- Member Title Member
- Age Age Unknown
- Birthday Birthday Unknown
CDProp hasn't added any contacts yet.
Topics I've Started
24 October 2013 - 06:30 PM
13 August 2013 - 12:06 PM
Greetings. I've been reading a lot about radiometry lately, and I was wondering if any of you would be willing to look this over and see if I have this right. A lot of the materials I've been reading have explained things in a way that is a little difficult for me to understand, and so I've tried to reformulate the explanations in terms that are a little easier for me to comprehend. I'd like to know if this is a valid way of thinking about it.
So, radiant energy is simply a matter of the number of photons involved, times their respective frequencies (times Planck's constant). SI Units: Joules.
Radiant flux is a rate. It's the amount of radiant energy per unit of time. SI Units: Joules per Second, a.k.a. Watts. If you have a function that represents the radiant flux coming out of a light source (which may vary, like a variable star), and you integrate it with respect to time, you'll get the total radiant energy emitted over that time.
The next three quantities are densities. A brief aside about densities. Let's think about mass density, which is commonly talked about in multivariable calculus courses, as well as in many freshman calculus-based physics courses. You have a block of some solid substance. Let's say that the substance is heterogeneous in the sense that its density varies, spatially. One might be tempted to ask, "What is the mass of the block at the point (x,y,z)?" However, this question would be nonsensical, because a point has no volume, and therefore can have no mass. One can answer the question, "What is the mass density at this point?" and get a meaningful answer. Then, if you wanted to know the mass of some volume around that point, you could multiply the density time the volume (if the volume is some dV, small enough that the density doesn't change throughout it), or else integrate the density function over the volume that you care about.
So, in terms of radiometry, the three density quantities commonly spoken-of are irradiance, radiant intensity, and radiance.
Irradiance is the power density with respect to area. The SI units are W·m-2. So, if you have some 2-dimensional surface that is receiving light from a light source, the Irradiance would be a 2-dimensional function that maps the two degrees of freedom on that surface (x,y) to the density of radiant flux received at that point on the surface. Exitance is similar to Irradiance, with the same exact units, but describes how much light is leaving a surface (either because the surface emits light, or because it reflects it). As with all densities, it doesn't make sense to ask, "How much power is being emitted from point (x,y) on this surface?" However, you can ask, "What is the power density at this point", and if you want to know how much power is emitted from some area around that point, you have to multiply by some dA (or integrate, if necessary).
Radiant Intensity is power density with respect to solid angle. The SI units are W·sr-1. Unlike irradiance, which gives you a density of power received at a certain point, radiant intensity tells you the power density being emitted in a certain direction. So, a point light (for example) emits light in all directions evenly (typically). If the point light emits a radiant flux of 100W, then its radiant intensity in all directions is about 8 W·sr-1. If it's not an ideal point light, then its radiant intensity might vary in each direction. However, if you integrate the radiant intensity over the entire sphere, then you will get back the original radiant flux of 100W. Again, it doesn't make sense to ask, "How much power is being emitted in this direction?", but you can ask, "What is the power density in this direction?" and if you want to know how much power is being emitted in a small range of directions (solid angle) around that direction, then you can integrate the radiant intensity function over that solid angle.
Radiance is the power density with respect to both area and solid angle. The SI units are . The reason you need radiance is for the following situation. Suppose you have an area light source. The exitance of this light source may vary, spatially. Also, the light source may scatter the light in all directions, but it might not do so evenly, so it varies radially as well (is that the right word here?). So, if you want to know the power density of the light being emitted from point (x,y) on the surface of the area light, specifically in the direction (θ,ϕ), then you need a density function that takes all four variables into account. The end result is a density function that varies along (x,y,θ,ϕ). These four coordinates define a ray starting at (x,y) and pointing in the direction (θ,ϕ). Along this ray, the radiance does not change. So, it's the power (flux) density of not just a point, and not just a direction, but a ray (both a point and a direction). Just as with the other densities, it makes no sense to ask, "What is the power (flux) being emitted along this ray?" It only makes sense to ask, "What is the power density of this ray?" And since a ray has both a location and direction, the density we care about is radiance.
The directional and point lights that we are used to using are physically-impossible lights for which it is sometimes difficult to discuss some of these quantities.
For a point light, it's meaningless to speak of exitance, because a point light has no area. Or perhaps it's more correct to think of the exitance function of a point light as a sort of Dirac delta function, with a value of infinity at the position of the light, and zero everywhere else, but which integrates to a finite non-zero value (whatever the radiant flux is) over R3. In this sense, you could calculate the radiance of some ray emanating from the point light, but I'm thinking it's more useful to just calculate the radiant intensity of the light in the direction that you care about, and be done with it.
For a directional light, it almost seems like an inverse situation. It's awkward to talk about radiant intensity because it would essentially be like a delta function, which is infinite in one direction, and zero everywhere else, but which integrates to some finite non-zero value, the radiant flux. Even the concept of radiant flux seems iffy, though, because how much power does a directional light emit? It's essentially constant over infinite space. It's easier to talk about the exitance of a directional light, though.
In any case, even with these non-realistic lights, it's easy to talk about the irradiance, intensity, and radiance of surfaces that receive light from these sources, which is what we typically care about.
How did I do?
02 August 2013 - 10:14 PM
I wanted to try to keep this as succinct as possible, because I'm definitely sensitive to the fact that no one wants to read paragraphs upon paragraphs of some schmoe's biography. However, I can't decide what else to cut. So, I apologize for the length, but if you are a professional game programmer (especially a graphics or engine programmer), I would be much obliged if you could read this monstrosity and give me whatever advice you can give. I desperately need direction!
I am one of the countless programmers who got their foot in the door without a degree. In 2006, I got a job at a local game developer as a sort of build engineer. By the end of my first project, I had automated most of my job, and so I had the programmers on my team give me some basic programming tasks to work on. I eventually became a full-time programmer. In 2008, the company went bust, and so I lost my job.
It turns out that two and a half years of game programming experience at a defunct (and honestly, crappy) game development studio does not make for a great resume, especially if you don't have a degree. So, I took a low-paying job at a very tiny web development company (think "working-in-some-dude's-basement" tiny). I had to learn a completely new skill set. There, I did both back end (Perl, MySQL) and front-end (HTML, JQuery w/ AJAX, CSS) stuff. Unfortunately, that company also went bust 5 months later.
Shortly after that, in late 2009, I found another job as a graphics programmer for a simulation company. This is my current job, and I've been here for almost 4 years.
So that about brings you current on my job history.
As you can probably tell, at the time that I was hired for my current position, they weren't looking for a graphics programming guru (if they were, they would not have hired someone with so little experience!). They were just looking for a good, smart programmer who could take ownership of the visual side of things. During the interview process, I programmed a very simple DX9 demo involving a pool of water (environment mapped reflections, refractions, fresnel), and an archway that casted a planar shadow. I modeled everything myself in Blender and exported it to a custom (albeit simplistic) file format using a script I wrote in Python. The company uses OpenGL, which I had no experience with, but I guess they decided that I knew enough about graphics to take ownership of their visual side of things.
The problem I am having with this job is that they have decided that their graphics fidelity needs are very modest, and so they've made realistic graphics programming an extremely low priority. Most of the time, they fill my plate with tasks that are only peripherally-related to graphics programming. For instance, they began work on a new level editor, and they needed me to code all of the 3D GUI stuff for it (dropping objects into the scene, picking, moving, rotating them, etc.). It turns out that this is 80% of the programming needed on it, and I quickly became THE owner of the level editor, responsible for the other 20% as well. For the first two years of this job, about 90% of what I did was related to this level editor. I essentially felt like a tools programmer, not a graphics programmer.
Edit: There are many other examples of non-graphics stuff that they've had me work on. but for the sake of brevity, I won't list them!
Meanwhile, I'm trying to get them excited about updating their graphics fidelity. When I first got there, their graphics already looked old (think original Half-Life, but with higher-res textures). I've done a few things over the years to update the graphics (added some normal mapping, gloss mapping, splatting to reduce the tiled look in grass and dirt textures -- all stuff that has been commonplace for more than a decade). When you combine this with the third-party libraries that I've integrated for ocean and sky rendering, the graphics look quite a bit nicer than they once did. But they still look horrendously out-dated.
I thought I had them convinced, at one point, that we really needed to change things. They gave me the go-ahead to re-architect the visual software from the ground-up so that it would be more flexible. The old visual software was so static; it was full of hard-coded behavior and ad-hoc hacks, and adding new stuff to it was very cumbersome. So, I took several months to reformulate things, and we just shipped our first project on the new architecture. Yay! I'm ready to add some new awesome effects.
But now they are loading my plate with more menial tasks that, at this point, I feel like would be better-handled by a junior programmer under my direction. We still have a long way to go on the graphics front. I haven't even been able to sell them on the importance of HDR yet, for example. We're still using simple single-buffer shadow mapping, and so we don't have full-scene shadows. I try to stay abreast of new developments, and I keep reading about things that I really want to do -- tiled light culling for nighttime simulations with lots of headlights and other work lights, image-based reflections to make the rain effects look more realistic, etc. -- that I think have practical value for the company, but I'm having a tough time selling them on it.
I really do understand, to some extent. The items they are having me work on are things that the customers are asking for, and there really isn't anyone else in the company who work in this area. However, I don't know if this is working for me anymore. I need a steep learning curve that I can climb. I feel like I'm on a plateau.
So I know what you're probably thinking. "Why not work on these projects in your own time, and then present them to the company when you have a working demo?"
And the truth is, I do work on side-projects such as this. However, it is extremely slow going because I am also in school. You may remember from the beginning of this tome that I did not have a degree when I started. Well, I started school about two and a half years ago, and I'm now about halfway toward a bachelor's degree in physics.* I am going full time, and the courses aren't easy. In order to maintain a good GPA (currently 3.93), I easily spend 30-40 hours per week on school. This is in addition to work, which often demands 50- or 60-hour weeks during crunch times. Yes, I have some weeks where I spend 90+ hours on work and school (although 70 is far more frequent).
I also have a family, and so I find myself with precious little time for side projects. I feel like I'm in one of those "Pick Two" situations: work, school, side-projects.
I'm really loath to quit school. I am just over halfway through, so why quit now? A degree might not be as important now as it was in the beginning of my career, but I'm not a quitter. Plus, I'm really excited about what I'm learning in my physics and math classes. I'm also currently working on some undergrad research involving crystals and electric field gradients, which I find really interesting and fun.
I am also loath to quit my job. I can't afford it, first of all. I also don't want the gap in my work history. Plus, I really like it where I work. These complaints aside, it's a great place to work, with nice people. They've been kind enough to take a chance on me, back when my graphics programming skills were unproven, and they have been very flexible with scheduling while I go to school. I feel that I owe them some loyalty.
But I also feel that, if I spend a year or two more in this "Graphics Programming Kiddie Pool", it's going to severely stunt my career. People are going to start wondering why I spent 6 years as a graphics programmer and haven't even implemented a good tone mapping operator before.
What should I do?
* Why physics? I would probably learn a lot from a CS degree, but I thought something cross-disciplinary would be more fun. It's not as though graphics is completely without a basics in physics, and most gaming and simulation companies seem to value knowledge in physics. So, why not?
03 July 2013 - 12:59 PM
Hi. My apologies if this discussion has been played out already. This topic seems to come up a lot, but I did a quick search and did not quite find the information I was looking for. I'm interested in knowing what is considered the best practice these days, with respect to deferred rendering and anti-aliasing. These are the options, as I understand them:
Use some post-processed blur like FXAA.
I've tried enabling NVidia's built-in FXAA support, but the results were not nearly acceptable. Maybe there is another technique that can do a better job?
Use a multi-sampled MRT, and then handle your own MSAA resolve.
I've never done this before, and I'm anxious to try it for the sake of learning how, but it is difficult for me to understand how this is much better than super-sampling. If I understand MSAA correctly, the memory requirements are the same as for super-sampling. The only difference is that your shader is called fewer times. However, with deferred shading, this really only seems to help save a few material shader fragments, which don't seem very expensive in the first place. Unless I'm missing something, you still have to do your lighting calculations once per sample, even if all of the samples have the same exact data in them. Are the material shader savings (meager, I'm guessing) really worth all of the hassle?
Use Deferred Lighting instead of Deferred Shading.
You'll still have aliased lighting, though, and it comes at the expense of an extra pass (albeit depth-only, if I understand the technique correctly). Is anybody taking this option these days?
NVidia is touting some TXAA technique on their website, although details seem slim. It seems to combine 2X MSAA with some sort of post-process technique. Judging from their videos, the results look quite acceptable, unlike FXAA. I'm guessing that the 2X MSAA would be handled using your own custom MSAA resolve, as described above, but I don't know what processing happens after that.
These all seem like valid options to try, although none of them seem to be from the proverbial Book. It seems to me, though, that forward rendering is a thing of the past, and I would love to be able to fill my scene with lights. I could try implementing all of these techniques as an experiment, but since they each come with a major time investment and learning curve, I was hoping that someone could help point a lost soul in the right direction.
Bonus questions: Is there a generally agreed-upon way to lay out your G-Buffer? I'd like to use this in conjunction with HDR, and so memory/bandwidth could start to become a problem, I would imagine. Is it still best practice to try to reconstruct position from depth? Are half-float textures typically used? Are any of the material properties packed or compressed in a particular way? Are normals stored as x/y coordinates, with the z-coord calculated in the shader?
I'm using OpenGL, if it matters.
12 January 2013 - 03:51 PM
It seems that glFramebufferTexture and glFramebufferTextureLayer have all of the parameters needed to specify the exact image needed in any kind of texture, including cube map arrays (using the layer-face index). Am I missing something?