PDA

View Full Version : Adaptive Shadow Maps



Nakoruru
07-29-2002, 11:05 AM
Has anyone seen an implementation of and/or a tutorial for Adaptive Shadow Maps? The paper explaining them is one of the poorest academic papers for explaining what they are actually doing, and that is saying a lot.

Why do I always have to read a graphics paper 3 or 4 times before I even begin to understand how I might implement the algorithm myself? I thought the point of such papers was to inform ^_^

Give me a power point presentation from nVidia anyday over this:
http://www.graphics.cornell.edu/~kb/publications/ASM.pdf

EDIT: In my search for a better explanation, I found a better algorithim. I was on a mental track that may have lead me to this solution. Glad someone got there before me, there were a lot of details I was not prepared to work out.
http://www-sop.inria.fr/reves/publications/data/2002/SD02/PerspectiveShadowMaps.pdf


[This message has been edited by Nakoruru (edited 07-29-2002).]

dorbie
07-30-2002, 02:09 AM
I was going to suggest the same paper :-) It was published in siggraph 2002 (this year). Now all you have to do is figure out how to quickly generate the post projection perspective of the light map and hope it works.

Err... any discussion on this is welcome :-).

okapota
07-30-2002, 03:17 AM
an intresting article. but not a word about the actuall implementaion. and if the worked on a dual 1ghz computer, no wonder their cpu intensive method ran cosiderably fast. i dont know, computing the convex hull and all that geometrix stuff sounds slow.

Nakoruru
07-30-2002, 07:08 AM
I do not think the convex hull stuff is required. Its is just their method of making sure that off screen occluders get considered. In other words, its just visibility determination. I bet a BSP tree could be used, and would be considerably faster, even if its not as exact.

For the most part, the algorithim is completely hardware accelerated. And as for speed, they are graphics researchers, not game programmers (I think), what do you expect ^_^

I bet this method runs at least as fast as stencil shadows. I would love to see a comparison with stencil shadows on that 23 million polygon scene. Although that is not completely fair since stencil shadows cannot handle point clouds.

This reaffirms my opinion that stencil shadows are Doomed.

ejeng
08-04-2002, 11:37 AM
Can anyone tell me how do I store the polygon IDs in the frame buffer? I read the author used polygon ID in the paper.
I tried to assign the IDs instead of the color values but when I read it from the Buffer, the value was changed. Here are partial of my code, Thanks a lot...


float idArray[40000];
int polygonID = 340; // example number

glDisable(GL_LIGHTING);
glBegin(GL_TRIANGLES);
glColor3f(polygonID*0.001,polygonID*0.001,polygonI D*0.001);
glVertex3f( 0.0, 50.0, 0.0);
glVertex3f(-50.0, -50.0, 0.0);
glVertex3f( 50.0, -50.0, 0.0);
glEnd()

glReadBuffer(GL_BACK);
glReadPixels(0, 0, 200, 200, GL_RED, GL_FLOAT, &idArray);

int resultID=(int)(idArray[20000]*1000);

evanGLizr
08-04-2002, 03:51 PM
Originally posted by ejeng:
I tried to assign the IDs instead of the color values but when I read it from the Buffer, the value was changed. Here are partial of my code, Thanks a lot...
[...]

glColor3f(polygonID*0.001,polygonID*0.001,polygonI D*0.001);
[...]


You cannot convert from ID to color just by multiplying by 0.001, you have to retrieve the colorbuffer bitdepth (glGet). Even if you do that, using the colorbuffer is a very problematic way of assigning IDs, as it can cause non-representability errors (your ID is not representable in the colorbuffer) and roundoff errors (if the geometry is clipped the color value may shift to a different ID).

In short, use the stencil buffer to assign IDs.

[This message has been edited by evanGLizr (edited 08-04-2002).]

jwatte
08-04-2002, 06:19 PM
> http://www-sop.inria.fr/reves/publications/data/2002/SD02/PerspectiveShadowMaps.pdf

That's one of the most exciting papers from this year's SigGraph, IMO. I read the pre-print (to get a jump on the people going to San Antonio :-) and it seems fairly robust.

Couple that with the trick of rendering the back-facing surface into the depth buffer for shadow mapping, and shadow maps do indeed look attractive.

The major draw-back of shadow maps is either the need for Very Large maps, or accepting that you'll have to fade shadow maps out when you get too far from the camera.

ejeng
08-04-2002, 07:40 PM
evanGLizr:

Thank you for the reply.
After trying hard to make it work, I found that Stencil Buffer is not working in my machine. Is there any other method that I can assign triangle IDs to the frame buffer without hardware acceleration?
Thanks again...

ejeng
08-05-2002, 06:18 AM
evanGLizr:

Sorry! I found that my machine do support Stencil Buffer.
I implemented triangle IDs and it works. Thanks....

evanGLizr
08-05-2002, 06:45 AM
Originally posted by ejeng:
evanGLizr:

Thank you for the reply.
After trying hard to make it work, I found that Stencil Buffer is not working in my machine. Is there any other method that I can assign triangle IDs to the frame buffer without hardware acceleration?
Thanks again...

It's strange that your OpenGL implementation doesn't support stencil, even the Microsoft software implementation has 8bits of stencil :?.
FWIW, in some NVIDIA cards you have to be using 32bpp colorbuffer to be able to get stencil.

Anyway, if you have to use the colorbuffer for polygon IDs, then you have to retrieve the bitdepth with glGetIntegerv(GL_RED_BITS, &dwCompDepth) and then set the color to ((float) ID / ((1 << dwRedDepth) - 1)) using flat shading. The calculation assumes that your color buffer uses fixed point format and that ID cannot be bigger than (1 << dwRedDepth) - 1.

Note that you should add a bias to that color in order to try to avoid roundoff errors in clipped geometry. Chances are that this is not needed because you use flat shading, but you never know if a graphics card implements flat shading as smooth shading with the same color for all the vertices and, hence, performs the color interpolation as normal, being prone to roundoff errors on clipped geometry.

You could also concatenate several color channels in order to have a larger polygon ID range, but note that the bit depth of each color channel may not be the same (if you are in 16bit colordepth 565 mode, for example).

Just remembered: There's a demo at NVIDIA http://developer.nvidia.com/view.asp?IO=Shadow_Mapping_ogl on indexed shadowmaps. Note that this demo stores the polygon ID in the alpha channel and uses smooth shading without adding the color bias per vertex, so it may go wrong depending on the graphics card (roundoff errors in clipped geometry from the light viewpoint).

[This message has been edited by evanGLizr (edited 08-05-2002).]

okapota
08-05-2002, 09:29 AM
i dont think shadow volumes are doomed. actually, if you think their problem is quality and not speed, than i think than coupled with post processing of the shadowed sence the shadows can be made soft, and without jittering the light. but they are indeed slower than shadow maps. but when you need to dynamically update the shadow maps of many lights, and maybe cube maps, you can raise the fill rate to be the
bottle neck, and than you are better done with shadow volumes. i think shadow maps are greate for an out-door scene. look at the SpeedTree demo.

AdrianD
08-05-2002, 10:28 AM
Originally posted by okapota:
(...)but when you need to dynamically update the shadow maps of many lights, and maybe cube maps, you can raise the fill rate to be the
bottle neck, and than you are better done with shadow volumes.(...)


the most limiting factor with stencil shadow volumes is fillrate(with todays hardware - even with a gf3/gf4). if the creation of your shadowmap has fillrate problems then your shadow volumes will consume even more fillrate.
so how are they supposed to be faster than shadowmaps ???

imho, it's definitely faster to generate shadowmaps than shadow volumes(SM:just render flatshaded polys in the depthbuffer: really easy SV:siluette detection, capping problems, render every volume twice), but the big problem with shadowmaps was the shadowmap-resoulition problem. (and ofcourse depth-buffering-alasing problems when the nearplane was to near)

this problems seems to be eliminated with this new method... and this could be the end of shadow volumes.

LaBasX2
08-05-2002, 11:17 AM
Are shadow maps also faster than shadow volumes when using point lights? For one point light you need to render the shadow map 6 times. I can't imagine that this is faster than drawing the volumes but I haven't tested it. Does anyone know more about the performance?

AdrianD
08-05-2002, 11:37 AM
because of that, a new method for doing shadowmaps is introduced in this new siggraph-paper.
that's what we are talking about, right ? http://www.opengl.org/discussion_boards/ubb/wink.gif

okapota
08-06-2002, 01:59 AM
this method sounds pretty cpu intensive. and they didnt explain exactly how it works, how to use this post-perspective space.

LaBasX2
08-06-2002, 02:11 AM
The technique sounds really nice but of course like in nearly every graphics paper they don't have any implementation details.

Does anyone know how exactly the geometry and the light source are moved into post-perspective space? Does that mean that you have to manually multiply the modelview matrix with the projection matrix to bring your geometry in that space?

And when the shadow map is created, how is it projected onto the scene for a point light?

Thanks
LaBasX2

LaBasX2
08-06-2002, 03:15 AM
More information about the calculation of the post perspective matrix can be found here:
http://www-sop.inria.fr/reves/research/psm/

AdrianD
08-06-2002, 03:44 AM
great. looks very good, i think i'll try it out tonight. http://www.opengl.org/discussion_boards/ubb/smile.gif

Nakoruru
08-06-2002, 06:17 AM
In the paper they said that transforming to post perspective space is a linear transformation and can therefore be done in a 4x4 matrix, so it can be hardware accelerated.

Why have two people now said that this sounds CPU extensive? It seems completely hardware accelerated to me.

I see the convex hull aspect of this paper as just them being complete and scientific. They stated that so and so geometry, in a certain area, is all that is capable of casting a shadow. You should take away from that that any visibility determination method which includes all this geometry will give correct results and does not have to be exact or slow.

The reason why shadow volumns are doomed is because shadow maps are very general. Shadow maps will shadow anything that can be rendered to the framebuffer that is opaque. You do not have to write special code to shadow point sprites or deplacement maps or curves. You just draw your geometry and it will be shadowed.

The other big reason is that on next generation hardware you should be able to write pixel shaders that do multiple lights in one pass. How do you write a stencil shadow algorithm that fits that scheme? Any method I can imagine begins to look a LOT like shadow maps (creating textures from stencil buffers), but with a lot of added complexity.

Would I be correct in saying that this method only requires one shadow map be generated per light for all types of lights? Directional, Omni, and Spot would all just require one shadow map per frame right?

Nakoruru
08-06-2002, 06:53 AM
Okapota,

Just in case my point got lost in the length of my previous post. I think that perspective shadow maps see spot lights and omni lights as just point lights using exactly the same math and setup.

Spot light fall off would have to be handled using a texture as a filter while omni lights would have no filter. Since they did not mention having to use cube maps, and its obvious they did not, I am assuming that this method will not require cube mapping.

This method also handles directional lights, which I have never seen done using shadow maps at all.

okapota
08-06-2002, 12:30 PM
maybe, if this is the case, than maybe it is really a good method. ill try it.

fresh
08-06-2002, 01:40 PM
The reason people are saying it's CPU intensive, is because the paper recommends reading back the zbuffer to main memory and searching for the smallest z value. Then re-render the scene with an adjust front clip plane to get maximum precision. They say it "only" takes 10ms, which is a lot for games of course! Still sounds like a good idea (sans the zbuffer reading).

Nakoruru
08-06-2002, 08:29 PM
Ok, the readback and z-buffer optimization does sound rather problematic. The main problem with that is not the CPU expense really, but the loss of syncronization (which happens without WGL_render_texture and WGL_depth_texture for traditional shadow mapping as well).

I guess its not completely hardware accelerated, but I still think it is the best shadow method discovered yet.

LaBasX2
08-07-2002, 12:03 AM
Let's just try it out, so we can prove if perspective shadow maps are better than shadow volumes. I was already starting a small demo yesterday where I tried to render the shadow map using the post-perspective matrix (described here: http://www-sop.inria.fr/reves/research/psm/ ) but it is still looking strange. Did anyone already have more success with building the post perspective matrix?

Thanks
LaBasX2

Nakoruru
08-07-2002, 04:39 AM
Definitely, no sense in arguing over it without any implementations.

davepermen
08-07-2002, 04:40 AM
Originally posted by Nakoruru:
This method also handles directional lights, which I have never seen done using shadow maps at all.

how about rendering the shadowmap with glOrtho? shadowmaps for directional lightsources are EASY..
on the other hand, i have never yet seen a implementation of pointlights in acceptable speed, as you need to render the 6 sides of the cubes..

shadowvolumes will not be doomed, as they help in much other situations as well..

shadowvolumes are the most generic solutions to shadows.. not the fastest. but they are the only generic perpixelaccurate solution for rastericers. the "fastest" method for exact shadows would still be *cough* raytracing.. http://www.opengl.org/discussion_boards/ubb/smile.gif (compared to the rest of the rendering..)

Nakoruru
08-07-2002, 06:14 AM
Our definition of generic may differ, so it may be pointless to argue, but I say that shadow maps are definitely more generic because they work with anything you can render. Shadow volumes require a different code path for each object representation you may want to use, hardly what one ussually considers general. They also fail on alphatested primitives.

Of course one could use glOrtho to make traditional shadow maps for directional lights, but unlike spotlights, the size of the map you would have to create and what needs to be rendered to it is a big question. With traditional shadow maps, you render everything the light shines on, but for a directional light, that is everything! At least with an omni light you can respresent that using a cube map, but for a directional light, you may need to sqeeze the entire scene into your shadow map in some cases. Since PSM only renders what is in the post perspective space cube, it only needs to render one shadow map for any type of light, including omni lights.

I have never seen anyone implement cube-map omni light shadow maps anyway, and with PSM, I see no reason why they ever would need to because in any case PSM would almost certainly be faster because it only requires that you render the scene once per light not six.

Someone needs to make a fair shadowmap/shadowvolume comparison demo, but it won't be me because i currently feel that implementing stencil shadows would be a waste of my time ^_^

PH
08-07-2002, 06:28 AM
Implementing stencil shadow volumes is not, in my opinion, a waste of time. The next generation of hardware is specificly optimized for rendering to depth/stencil. With some hard work, shadow volumes can be fast. In fact, I'm constantly surprised by how fast current hardware is, even if you don't do any optimizations.

Both methods have good and bad points, the solution is not to discard one of them but possibly combine them.

davepermen
08-07-2002, 08:02 AM
Originally posted by Nakoruru:
Shadow volumes require a different code path for each object representation you may want to use, hardly what one ussually considers general. They also fail on alphatested primitives.
yes, the alphatest doesn't work. no, no different codepaths needed, and yes, its all on the gpu here (as soon as i have at least a gf3 http://www.opengl.org/discussion_boards/ubb/wink.gif).

for alphatested primitives, shadowmaps work bether, but for real transparent objects, they have the same problems shadowvolumes have... so not REALLY generic, your approach..



Of course one could use glOrtho to make traditional shadow maps for directional lights, but unlike spotlights, the size of the map you would have to create and what needs to be rendered to it is a big question. With traditional shadow maps, you render everything the light shines on, but for a directional light, that is everything!
its just the whole scene, but thats all the time for global lights.. http://www.opengl.org/discussion_boards/ubb/smile.gif


[/B]At least with an omni light you can respresent that using a cube map, but for a directional light, you may need to sqeeze the entire scene into your shadow map in some cases. Since PSM only renders what is in the post perspective space cube, it only needs to render one shadow map for any type of light, including omni lights.
[/B]
yeah, the psm are much bether for shadowmapping, there is no point in this.. (including point lights i'm comming to this soon http://www.opengl.org/discussion_boards/ubb/wink.gif)

I have never seen anyone implement cube-map omni light shadow maps anyway, and with PSM, I see no reason why they ever would need to because in any case PSM would almost certainly be faster because it only requires that you render the scene once per light not six.

.. what if the lightsource is IN the unit cube? there is NO WAY to get the shadowmap then as you once again need a frustum bigger than 180 degrees. and thats impossible, with or without PSM. and thats why shadowmaps arent generic at all. they work as long as they are eighter some spotlights (directional or omni lights) or, now with PSM with much higher quality, outside of the scene..
there is STILL no way for a simple generic point light shadow map in the scene.


Someone needs to make a fair shadowmap/shadowvolume comparison demo, but it won't be me because i currently feel that implementing stencil shadows would be a waste of my time ^_^
first provide me a solution for a simple point light in the middle of a room with some objects floating around it. with only one rendertodepthtexture. you should use PTM, but that doesn't help you for getting it over 180.. prove me wrong..

Nakoruru
08-07-2002, 10:20 AM
You have a good 'point' Davepermen, I'll have to think about it.

EDIT:

Thinking over ^_^

Okay, I see now that it would require a cube map if the light is in the view frustum. I do not understand why you consider this flaw enough that you cannot consider shadow maps to be generic. Big deal, now I have two cases in my code. My view is that it's one case, with an optimization for lights outside the view frustum.

I really do not want to get into a big contest over which is more general (but don't worry, I will anyway). Sometimes it's just a matter of opinion or marketing. But my opinion is that when I have to write a vertex shader to do shadow volumes for each vertex shader I write, that the code is not general. When I have to come up with a different method to render point sprite shadows and alphatested polygon shadows, stenciled polygon shadows (if I could even use the stencil buffer for something else), and frag-killed polygons, then its not general.

Even if now the idea of using a cube map for each point light is bad, the increases in fill rate and memory will make it worthwhile sooner than we may think.

The simple fact is that shadow maps can shadow anything that you can throw into the framebuffer with Z while shadow volumes can only shadow what you can describe as vertices and edges.

Shadow maps will get better as memory, fill-rate, and precision improve. Stencil shadow volumes are about as good as they are going to get.

I measure generality in code paths. I could write a shadow map renderer with one code path (excluding paths for different extensions), basically, just render the shadow map to a cube map. Hardware will eventually make this fast enough that I would not even have to optimize for cases where a 2D texture will work.

In the worse case, if I implement a stencil shadow volume renderer, I would have one code path for each vertex shader, because I would need them to transform and extrude the silouette edges. I am not sure how one goes about capping the volumes for each case. In the best case I would just transform all my vertexes the same way, but then what is the point of programmability?

So, in my opinion, stencil volume shadows are a temporary solution until precision and memory problems are sorted out in hardware. They are doomed. They are doomed soon enough that I do not see the use of starting a new project that uses them.




[This message has been edited by Nakoruru (edited 08-07-2002).]

LaBasX2
08-07-2002, 01:59 PM
So perspective shadow maps also aren't the ultimative shadow solution as dave found out...well, would probably also have been too nice...

BTW, Nakoruru, there is a demo with source that shows how to use shadow maps for point lights with a cube map; it is at:
http://freefall.freehosting.net/downloads/cubicshadows.html

LaBasX2

Nakoruru
08-07-2002, 06:55 PM
Thanks for the link, although I think I was complaining that I had not seen directional lights implemented or even explained.

EDIT: It says there is no hardware support for cubic depth maps. This surprised me at first, then I realized why (the hardware relies on the texture being projected in a certain way). Thats a bummer, I guess I really will need a next generation card to implement all my plans.

[This message has been edited by Nakoruru (edited 08-07-2002).]

davepermen
08-07-2002, 09:31 PM
Originally posted by Nakoruru:
It says there is no hardware support for cubic depth maps. This surprised me at first, then I realized why (the hardware relies on the texture being projected in a certain way). Thats a bummer, I guess I really will need a next generation card to implement all my plans.

well, next gen hw doesn't have any problems to implement them in hw (if _YOU_ get the math right.. there are some funny problems but you can solve that..)

the major problems are
a) you NEED to render the scene 6 times, and, as long as hw doesn't support "cubic rendering" that is just hell of a slow thing. (while shadowvolumes are only one additional pass in next hw, thought..)
b) the cubemap normally will not be _that_ highres, will it? i mean, rendering 6 highresimages.. for each light? thought
c) i have NO idea yet how to get the csm (cubic shadow map) done in pps (post projection space). but i bet you get at least that.

a and b are problems as long as there is no cubic shadow map support, c can be solved (and solves b partially)

think about that:
512x512x6x4 bytes should be more or less the size of a cubic shadow map to look.. good.. (with pps shadow mapping it should work good). that is 6mb of space for each light. and 6passes extra each light.. shadow volumes are much less memory eating, and much less pass eating, and are always perpixelaccurate.. for today, they are _THE_ solution http://www.opengl.org/discussion_boards/ubb/wink.gif (but when we come to shadowing of others than pointlights (directionals are pointlights as well.. just infinite far away), but move to area lights, shadow maps could be far more helpful..)


and there is still the raytracing approach, wich can get more and more interesting each new hw generation (i'll get a nv30 just for raytracing in hw.. http://www.opengl.org/discussion_boards/ubb/smile.gif)

okapota
08-08-2002, 12:41 AM
maybe it is better to use both methods. one for each light source. i think point lights are very important for a scene and cant be passed. spot light are more of fine tuning things.

Nakoruru
08-09-2002, 12:02 PM
Working some stuff out on paper, trying to determine how drawing a cube shadow map in post perspective space would work (more on that later) and incidentally determined that spotlights that have an angle of greater than 90 degrees can be stretched out further than 180 degrees in post-perspective space if they are inside the view frustom and the view frustum has a FOV greater than 90 degrees.

This can probably be generalized by saying that a spotlight with an angle of N degrees can be over-stretched in post perspective space if the FOV is greater than 180-N.

This means that with perspective shadow mapping, one may have to use cube-maps even for a spotlight if that spotlight is inside the view frustum. Luckily it only happens when one uses wide spotlights with wide fields of view.

As for the broader work of determining if shadow cubemaps can be draw in post-perspective space, I have almost concluded that it's no problem and has the same benefits as non-cube-maps in that it provides more detail where its needed. You just draw the cube-map from the position of the light in post perspective space.

Now if only support for cube-shadow-maps where to appear.

davepermen
08-09-2002, 12:24 PM
shadowcubemap support is yet here, just low precision (this shouldn't be such a problem in pps anyways as well..), and you can even do highprecision of it with some math. the problem is the rendering of the 6 faces. as long as there is no hardware that can render cubemaps, i don't see much future in generic shadowmaps.. even while this pps space shadowmaps solve one of the big problems, the precision, it doesn't solve yet the genericity.. too bad. we have to wait for nv35 or nv40 for this..

jwatte
08-09-2002, 01:25 PM
Davepermen,

Hardware has been able to render cube maps for a long time. It just takes more passes than just one of the faces :-)

Nakoruru
08-09-2002, 02:58 PM
I was thinking the same thing as jwatte.

Do you mean something better than rendering to a pbuffer texture? I mean, you -can- render to a cubemap, you just have to make 6 calls to glPbufferAttribute to change faces.

I guess you mean that you want to be able to send all your geometry once and have it render across all 6 faces.

That would be cool (really freaking cool!), but I do not think having to render one face at a time is a huge bottleneck if you have a good visibility determination method because you would not actually end up sending most of your geometry more than once.

I do admit that some situations would be really bad, and all-at-once-cubic-rendering would solve that.

My first stab at how it would work...

You would need 6 sets of geometry state, one for each cube face. You would want to use the same vertex program, but would need to have 6 different tranformations. When you send geometry, it is transformed by all 6 programs using the different matrixes and then sent to each of the 6 pipelines for clipping. Polygons on the edge of the screen would end up being rasterized on more than one face.

The really cool thing about this is that it could probably be generalized to render any 6 transformations you want to 6 different buffers. You could do something like softshadows, motion blur, depth-of-field in parallel instead of in series, if you had a good way to composite all 6 framebuffers.

Does anyone see this type of massivly parallel hardware existing anytime soon.

vshader
08-11-2002, 01:06 AM
latest cards already have several parallel vertex processors and frag processors so it's not too far off - not sure if the triangle setup is currently as parallel - i suppose it must be....

anyway, as soon as we have a card with 6 vertex units and 6+ fragment units, with a bit of extra state tracking (ie all units need not have same program running) it could maybe write to a cube map at 1/6 normal speed.

would still be faster than current setup 'cos of no context switching between pbuffers.

current dx9 cards (eg R300) can write to up to 4 rendertargets at once, but i think they all share the same rasteriser, so that would need fixing... currently you can write color to one pbuffer, normals to another and depth to another, but all with same geometry.

davepermen
08-11-2002, 02:06 AM
you don't need 6 rastericers. you just need one (as one triangle occurs on one place on the cubemap anyways). it just have to generate the proper scanlines for each square, and the thing is done. it would be cool if cubemap rendering would not need to divide the scene into 6 parts, render 6 frames and copy 6 times. would help much for fast dynamic reflections, shadowmaps, and more.. (you could finally blur the cubemap good in hw as well, for diffuse reflectionmaps)

vshader
08-11-2002, 04:43 AM
i get what you mean - but that would mean doing each face in series...if you want to render 6 different triangles to 6 different targets at the same time you would need 6 rasterizers, yes?

point is the current multi-rendertarget machines use the same rasterizer for each target- you can just adjust what color & maybe depth values are written to each.

the rasterizer is upstream from the fragment processors - so to get all the frag processors operating in parallel you need 6 different rasterizer units.

[This message has been edited by vshader (edited 08-11-2002).]

[This message has been edited by vshader (edited 08-11-2002).]

davepermen
08-11-2002, 10:26 AM
white it could be funny to work with 6 different rastericers its absolutely useless for this problem. we don't want to render to 6 different targets, nor want we to render 6 different triangles. we want one triangle, and it should go on one target. the cubemap.

and about the 4 different targets on dx9. in fact its one big 128bit buffer and you have 4 32bit values in. now in the full floatingpoint pixelshader you can eighter store r,g,b,a in the 128bit buffer, or use one of the compressioninstructions to compress say a full floatvector into one 32bit rgba value (4 unsigned chars then), or two of them into one 32bit "HILO" value (means two shorts), or two of the minto one 32bit float 2d vector, where you use half precision floats (each one 16bits). so you can store in the end 16 different values for your triangle, all 8bit unsigned chars, or 4 floats, or some unsigned shorts, some unsigned chars, some floats, some halffloats, in what ever combination. its just one fat 128bit target. and you can copy out one of the 4 32bit components (or even one of the 8bit, i dunno?) onto a texture, or some of them, or however, for reuse..

hope that chaotic text clarified something about next gen hw..

vshader
08-11-2002, 09:57 PM
hope that chaotic text clarified something about next gen hw..


thanks, it does...means we'd have to wait until 256bit framebuffers before there'd be enough room for 6x24+bit depth values

the scheme you are talking about is easier at the app end, but it means rasterized fragments would also have to carry a cubemap face index as well as current x,y and depth values. not sure wether that is easiest for hardware to implement, or 6 complete pipelines, with the app doing visibility determination for each face...

[This message has been edited by vshader (edited 08-12-2002).]

davepermen
08-12-2002, 03:56 AM
if the gpu supports 6 rastericers, then i want the gpu to rasterice 6 triangles at once. that would mean 6times as fast. but for a cubemap i would have to use one rastericer anyways at the time. it would not help..

and you don't need an aditional face index btw..

it is rendering onto one target. not only for the app but as well for the gpu. what you suggest is the same as we have today, just with a faster hw. that doesn't help, as we can render to a single target faster then as well..

setting up a rastericer to rasterice cubemaps as well should not be _that_ much of a problem. the only real problem is, its slighly different, and todays rastericers are pushed since years till the extreme so they are sort of perfect. and you need this perfection for the todays speed of them.. so it would be (at least the first versions) possibly quite a bit slower.. but generating scanlines for one target or for at max 4 is not a big trouble really.. (i think 4 is the maximum of cubesides one triangle can get drawn..)