|
View previous topic :: View next topic
|
| Author |
Message |
sean
Joined: 01 Feb 2005
Posts: 1392
Location: Kirkland WA
|
| |
 Posted: Sat Sep 06, 2008 12:28 am Post subject: |
 |
|
| ryg wrote: | we're pulling all the little bumps and discontinuities and high-frequency phenomena out of the mesh (to save on triangles) and put them into the normal map. That much is obvious. More importantly, normal maps don't directly influence the pixel's color; they influence the lighting model, which typically generates weights that are then used to combine other textures with each other. Now, you normally want the visual appearance of materials to roughly stay the same as you move away from them; that's where specular materials using mipmapped normal maps fail so miserably, because the transition to a lower frequency texture is very visible since the lighting model amplifies the effect.
Which brings me to my actual point: the "right" way to mipmap a normal map depends on what lighting/reflection model it's being used with. If a material is mostly diffuse, normal mipmapping works quite well - the bumps just smooth themselves out, and from a distance the surface just looks flat (paper is a good example). Specular materials are trickier: |
Unfortunately, mipmaps ALSO don't work for diffuse/specular/etc if they're correlated with other terms (e.g. the normals). I.e. if you have red stuff sloping to the left and green stuff sloping to the right in alternating bands, it's wrong to average those to yellow plus some kind of cone or other. I demonstrated this in a gdmag article with a trivial example which also illustrated the problem with doing anything non-linear to a texture in a pixel shader: just multiply a checkerboard texture by itself (equivialently, multiply a checkerboard diffuse texture by some correlated other thing which produces another checkerboard). The average of 1^2 + 0^2 is different from 0.5^2. (Although I don't think I gamma corrected that image, so it's actually wrong in other ways.)
What you "really" want is a BRDF that varies spatially. Unfortunately, a BRDF is a 4D function, so a textured one is a 6D function, which is representationally infeasible. I remember Chris Hecker was grumbling about this infeasibility while talking to me Jon Blow in 1999 or so, before the first GD Hardcore conference, where McCool (I think) presented a two-texture BRDF approximation (aniostropic BRDF, but uniform over the whole model, i.e. missing those extra 2D) that Jon (I think) had implemented the hardware demo of.
So yeah, if you can come up with a good closed form flexible representation of the most common BRDF modes without requiring a ton of parameters, hooray. |
|
| Back to top |
|
 |
ryg
Joined: 31 May 2007
Posts: 276
Location: Kirkland, WA
|
| |
Posted: Sat Sep 06, 2008 1:55 am Post subject: |
|
|
ARGH. I just wrote a rather long reply and got some Internal Server Error when posting it. Hooray. So I'll cut it a bit shorter this time.
| sean wrote: | | Unfortunately, mipmaps ALSO don't work for diffuse/specular/etc if they're correlated with other terms (e.g. the normals). I.e. if you have red stuff sloping to the left and green stuff sloping to the right in alternating bands, it's wrong to average those to yellow plus some kind of cone or other. I demonstrated this in a gdmag article with a trivial example which also illustrated the problem with doing anything non-linear to a texture in a pixel shader: just multiply a checkerboard texture by itself (equivialently, multiply a checkerboard diffuse texture by some correlated other thing which produces another checkerboard). The average of 1^2 + 0^2 is different from 0.5^2. (Although I don't think I gamma corrected that image, so it's actually wrong in other ways.) |
Yeah, anything that doesn't enter linearly into the computed color is really fundamentally wrong - at least from a "properly downsampling a function with discrete jumps but on a continuous domain" point of view. However, that doesn't change the fact that some of these errors are more visible/objectionable than others, and the mipmapped normal maps thing is pretty close to the top of the list for a lot of people.
| sean wrote: | | What you "really" want is a BRDF that varies spatially. Unfortunately, a BRDF is a 4D function, so a textured one is a 6D function, which is representationally infeasible. I remember Chris Hecker was grumbling about this infeasibility while talking to me Jon Blow in 1999 or so, before the first GD Hardcore conference, where McCool (I think) presented a two-texture BRDF approximation (aniostropic BRDF, but uniform over the whole model, i.e. missing those extra 2D) that Jon (I think) had implemented the hardware demo of. |
The surface-varying BRDFs are called BTFs; they're a specialty of the computer graphics group at the University of Bonn (where I studied), so I've had some exposure to the subject.
They have a pretty cool setup that they use to measure BTFs of real materials - 159 small digital cameras fixed to a hemispherical dome and oriented towards the center (where you put the material sample). One measured BTF consists of 25281 (159^2) HDR photos of the sample, one for each viewer position/ight position pair (the camera flash is used as light source; works fine, since they're pretty close to the lens position). One such dataset (after aligning the photos) is a couple of gigabytes, but they've developed compression methods (based on clustered PCA, which seems to be en vogue nowadays) that get such a sample down to a 16MB set of textures that is suitable for real-time rendering on a shader 2.0-level card (with a 50-instruction shader). It definitely looks quite good (though they only use an effective resolution of 256x256 pixels for a 10cm x 10cm material sample, so it's not exactly high-res).
The process obviously won't work for highly specular materials; but for anything else, it's pretty reasonably, if you're willing to build the setup and wait for the >1 hour that the process runs for one material sample. The sponsor for this project was Daimler-Chrysler, who wanted to get photorealistic rendering of car interiors to reduce the number of prototypes they have to build - since one out-of-serious car prototype is damn expensive, the cost of the setup and the required time wasn't that much of a problem.
The project was called RealReflect, publications are at http://tinyurl.com/65rwea if anyone's interested. Fun stuff. (I would've used a url BBCode tag, but for some reason I get server error messages when I do).
| sean wrote: | | So yeah, if you can come up with a good closed form flexible representation of the most common BRDF modes without requiring a ton of parameters, hooray. |
Yeah, that's the main problem, really; measuring and compressing real material samples is nice enough, but it's really a "take it or leave it" kind of deal; apart from trivial color correction, there's really not much editing you can meaningfully do with the datasets. I don't see that working in an artist-centric environment at all.
It would certainly be nice to get a more "generative" model out of it - like a set of different layers the material consists of, all fitted and bound to the parameters of a more or less intuitive BRDF model, plus a compact description of the microgeometry structure. That's the least amount of degrees of freedom you need to describe a wide variety of real-world materials to reasonable accuracy; but it's already a lot of parameters to tweak, many of which are really technical. So you really want to be able to start with some measured material and make variations from there, but that's also problematic, since such a complex structure is bound to be a royal pain to fit measured data to with any reasonably accuracy.
That's kind of the state of the art of research in that area right now - they have something working and are now trying to get to something you can actually work with properly. They're making progress, but I'm pretty certain it's still a long way to go. |
|
| Back to top |
|
|
Won
Joined: 21 Sep 2005
Posts: 506
Location: New York
|
| |
Posted: Sun Oct 26, 2008 1:00 am Post subject: |
|
|
So, to what extent does texture-space lighting help the filter-then-light v. light-then-filter problem? So you still have to deal with mipmapping.
It also occurred to me that you could do the texture space lighting with SVT something like this:
1) Find visible texture pages.
2) For each light,
2a) render shadow buffers, and
2b) compute lighting for visible texture pages that are potentially lit
3) Render Scene.
which has the benefit of not wasting too much time lighting tiles that won't ever get seen. Also, maybe you only bother doing this for the tiles that have potentially large non-linearities (e.g. just specular).
Edit: Oops.
Last edited by Won on Tue Oct 28, 2008 8:28 pm; edited 1 time in total |
|
| Back to top |
|
|
TomF
Joined: 18 Feb 2007
Posts: 107
Location: Seattle
|
| |
Posted: Mon Oct 27, 2008 1:00 am Post subject: |
|
|
| Net etiquette is that you do not post links to patents, or anything about them - it can put some people in a very awkward legal position simply being in the same forum as them. |
|
| Back to top |
|
|
Won
Joined: 21 Sep 2005
Posts: 506
Location: New York
|
| |
Posted: Tue Oct 28, 2008 8:29 pm Post subject: |
|
|
| I was not aware of that. Apologies! |
|
| Back to top |
|
|
skynet
Joined: 01 Sep 2008
Posts: 20
|
| |
Posted: Fri Nov 07, 2008 10:12 pm Post subject: |
|
|
Updating things a bit. I have exercised some experiments with normals. Instead of trying to sythesize the voxel normal from other properties, I do now store a RGBx encoded normal per cube-side. This again exaggerates the memory requirements, but to my surprise it didn't slow down the rendering all too much.
What makes me headaches is how to handle the 'coverage' aspect of things. Up to now I set the coverage of the voxel side(s) to 'full' as soon as a triangle straddles the voxel. A triangle can "touch" up to 3 sides of a voxel, depending on its face normal. When computing the mipmaps, I handled the coverage value almost like a color. That means, if only 1 of 4 voxels has full coverage, the resulting super-voxel would get 1/4 coverage. I needed a long time to understand why it doesn't work this way.
Usually, voxels represent volumetric things. If I voxelized a sphere, the 'inner' part of the sphere would get filled with solid voxels as well. When computing mipmaps for such a voxelsized sphere, the inner part would stay solid (full coverage) for many levels of the mipmap. Even if the border of the sphere would loose coverage, the shape of the sphere would stay intact. Try to imagine that as a filled circle texture and you start computing mipmaps for that texture...
Now, in my case, I do not produce a solid voxelization. Instead, only the surface of the objects (a triangle soup basically) gets voxelized. I cannot do it another way, because I have no information on the inner or outer of the objects I want to voxelize. If I now start to mipmap those voxels, their coverage quickly gets lower and lower. Have you ever tried to compute mipmaps for wire-mesh fence textures? Same bad things happen here.
I tried to leave away the aspect of coverage. It doesn't look too bad. But then it often happens that small features get more and more exaggerated (instead of vanishing) the further you go up in the mipmap chain. |
|
| Back to top |
|
|
Zaphos
Joined: 24 Feb 2007
Posts: 90
|
| |
Posted: Sat Nov 15, 2008 6:02 am Post subject: |
|
|
| skynet wrote: | Updating things a bit. I have exercised some experiments with normals. Instead of trying to sythesize the voxel normal from other properties, I do now store a RGBx encoded normal per cube-side. This again exaggerates the memory requirements, but to my surprise it didn't slow down the rendering all too much.
What makes me headaches is how to handle the 'coverage' aspect of things. Up to now I set the coverage of the voxel side(s) to 'full' as soon as a triangle straddles the voxel. A triangle can "touch" up to 3 sides of a voxel, depending on its face normal. When computing the mipmaps, I handled the coverage value almost like a color. That means, if only 1 of 4 voxels has full coverage, the resulting super-voxel would get 1/4 coverage. I needed a long time to understand why it doesn't work this way.
Usually, voxels represent volumetric things. If I voxelized a sphere, the 'inner' part of the sphere would get filled with solid voxels as well. When computing mipmaps for such a voxelsized sphere, the inner part would stay solid (full coverage) for many levels of the mipmap. Even if the border of the sphere would loose coverage, the shape of the sphere would stay intact. Try to imagine that as a filled circle texture and you start computing mipmaps for that texture...
Now, in my case, I do not produce a solid voxelization. Instead, only the surface of the objects (a triangle soup basically) gets voxelized. I cannot do it another way, because I have no information on the inner or outer of the objects I want to voxelize. If I now start to mipmap those voxels, their coverage quickly gets lower and lower. Have you ever tried to compute mipmaps for wire-mesh fence textures? Same bad things happen here.
I tried to leave away the aspect of coverage. It doesn't look too bad. But then it often happens that small features get more and more exaggerated (instead of vanishing) the further you go up in the mipmap chain. |
That's what I was trying to get at when I said coverage is view dependent ...
If you want solid objects, you could try generating your voxels with a technique like http://www.cs.berkeley.edu/~jrs/meshpapers/NooruddinTurk.pdf
That algorithm would be applied on a per-object basis (assuming you have a world of watertight objects) -- there's also the 'Denis Haumont and Nadine Warzée. Complete polygonal scene voxelization' paper, which presents a way to voxelize complete outdoor scenes in a video game (outcast 2 ...), but it looks like a pretty bad algorithm. Here's a link to it regardless: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.14.6993
You still have similar fundamental problems with solid voxelizations if your objects have thin parts, though, so it's probably not a good solution. |
|
| Back to top |
|
|
sean
Joined: 01 Feb 2005
Posts: 1392
Location: Kirkland WA
|
| |
Posted: Sat Nov 15, 2008 8:27 am Post subject: |
|
|
Regarding coverage being view-dependent:
The "Point-Based Approximate Color Bleeding" paper here basically builds up an octree representation of the lit surfaces in the world to do one bounce of hierarchical radiosity efficiently. They use spherical harmonics to represent not just the lighting, but the coverage of a single octtree node.
Of course, they're not rendering it directly, just using it for lighting, so they can tolerate a lot more imprecision, but hey, they've actually shipped movies made with that system. |
|
| Back to top |
|
|
saintxi
Joined: 04 Mar 2009
Posts: 5
Location: London UK
|
| |
Posted: Sat Mar 07, 2009 9:08 pm Post subject: |
|
|
Great pdf links  While Tri+Normal map is great for in game graphics highres modelling is passing the vert/pixel stage and might be more suited to a voxel solution.
In any case I have been working on adding volumetric sculpting to my 3D editor app, it has the interesting bonuses of being able to apply 3D filters to easily smooth/deform the surface and boolean operations are simple.
I've seen some other 3D apps try out this route now it is computationally viable. I am interested to see if the perfecthash speeds up my own editor, thanks!
_________________
Light of Altair 3D sci-fi colony building game
twitter.com/saintxi |
|
| Back to top |
|
|
XICO2KX
Joined: 10 Feb 2010
Posts: 1
|
| |
Posted: Wed Feb 10, 2010 5:21 pm Post subject: |
|
|
| sylvan wrote: |
Did anyone succeed in finding an URL for this company called Unlimited Detail? It's a very hard-to-google name... |
Try here: 
> www.udt8.com
| Unlimited Detail wrote: | How does it work?
If you have a background in the industry you know the above pictures are impossible. A computer can’t have unlimited power and it can’t process unlimited point cloud data because every time you process a point it must take up some processor time. But I assure you, it's real and it all works.
Unlimited Details method is very different to any 3D method that has been invented so far. The three current systems used in 3D graphics are Ray tracing polygons and point cloud/voxels, they all have strengths and weaknesses. Polygons runs fast but has poor geometry, Ray-trace and voxels have perfect geometry but run very slowly.
Unlimited Detail is a fourth system, which is more like a search algorithm than a 3D engine. It is best explained like this: if you had a word document and you went to the “SEARCH” tool and typed in a word like “MONEY” the search tool quickly searches for every place that word appeared in the document. Google and Yahoo are also search engines that go looking for things very quickly. Unlimited Detail is basically a point cloud search algorithm. We can build enormous worlds with huge numbers of points, then compress them down to be very small.
The Unlimited Detail engine works out which direction the camera is facing and then searches the data to find only the points it needs to put on the screen it doesn’t touch any unneeded points, all it wants is 1024*768 (if that is our resolution) points, one for each pixel of the screen. It has a few tricky things to work out, like: what objects are closest to the camera, what objects cover each other, how big should an object be as it gets further back. But all of this is done by a new sort of method that we call MASS CONNECTED PROCESSING. Mass connected processing is where we have a way of processing masses of data at the same time and then applying the small changes to each part at the end.
The result is a perfect pure bug free 3D engine that gives Unlimited Geometry running super fast, and it's all done in software. |
Sounds like a voxel/octree-index/ray-casting combo sort of rendering engine! 
But check the cool demos in the "Videos" section!  |
|
| Back to top |
|
|
hubris
Joined: 13 Feb 2010
Posts: 1
|
| |
Posted: Sat Feb 13, 2010 6:08 pm Post subject: |
|
|
| XICO2KX wrote: |
Sounds like a voxel/octree-index/ray-casting combo sort of rendering engine!
But check the cool demos in the "Videos" section! |
It's nice but they say it's software rendering and want to do it on the Wii at the end of the video. Hard to believe... |
|
| Back to top |
|
|
casey
Site Admin
Joined: 18 Dec 2004
Posts: 1768
Location: Seattle
|
| |
Posted: Sun Feb 14, 2010 12:18 am Post subject: |
|
|
There's definitely something "unlimited" in their demos, but it's not the detail.
- Casey |
|
| Back to top |
|
|
jai
Joined: 10 Apr 2007
Posts: 247
|
| |
Posted: Thu Feb 18, 2010 8:27 pm Post subject: |
|
|
I know you guys all read RRB, but I thought I'd post this link since it's directly related to this topic:
http://www.tml.tkk.fi/~samuli/ |
|
| Back to top |
|
|
sean
Joined: 01 Feb 2005
Posts: 1392
Location: Kirkland WA
|
| |
Posted: Fri Feb 19, 2010 3:45 am Post subject: |
|
|
Yeah, the contour stuff seems like it probably addresses the problem of the opacity being directional.
I'm not sure it's a very good way to do it, though... the data structure is large enough that there's a sort of implication "hey, the contours let us get away with having slightly fewer levels" (although i don't think they say it outright), but if you did that you'd lose texture detail.
Plus I continue to think that needing to blur instead of interpolate is broken (although as ryg said before technically we don't have a solution to that for polygons that are smaller than a pixel either, although I'm not sure the problems have the same impact in practice). |
|
| Back to top |
|
|
ryg
Joined: 31 May 2007
Posts: 276
Location: Kirkland, WA
|
| |
Posted: Fri Feb 19, 2010 7:36 am Post subject: |
|
|
| sean wrote: | Yeah, the contour stuff seems like it probably addresses the problem of the opacity being directional.
I'm not sure it's a very good way to do it, though... the data structure is large enough that there's a sort of implication "hey, the contours let us get away with having slightly fewer levels" (although i don't think they say it outright), but if you did that you'd lose texture detail. |
Well, you need something like this no matter what you do, otherwise you can't even represent rotated cubes without significant staircasing up close. (Did I say cube? What I meant was, er, crate. On top of a slightly differently rotated pallet, of course!)
I'd really like to see the results on their architectural models for slightly rotated input geometry, actually.
| sean wrote: | | Plus I continue to think that needing to blur instead of interpolate is broken (although as ryg said before technically we don't have a solution to that for polygons that are smaller than a pixel either, although I'm not sure the problems have the same impact in practice). |
Yeah, anything that absolutely requires a screen-space blur pass is just extremely awkward.
What I said wasn't specific to polygons; it's a general problem with any shading that involves specular reflections compared with fine geometric detail, really. And the voxels would probably be completely pathetic there, since they already suck at filtering when there's no annoying high-frequency stuff involved, and specular highlights have this tendency of revealing even tiny cracks and discontinuities on surfaces... |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Usergroups
Log in
Register
