HSR vs Tile-Based rendering?

[Simon F]

Since the location of the samples textels depends on the perspective of the polygon in question, z-values or some information about perspective must be involved...

Texture mapping is done by evaluating hyperbolic equations, i.e.

U_pixel = (A * X + B * Y + C) / (P * X + Q * Y + R)
V_pixel = (D * X + E * Y + F) / (P * X + Q * Y + R)

where X and Y are the coordinates of the screen pixel, and the nine constants, A,B..F,P,Q,&R are evaluated during triangle setup from the X,Y and 1/W positions of the vertices and their associated U&V values.

In a sense the "/ (P * X + Q * Y + R)" is typically encoding the perspective depth but it doesn't have to be.

 

[Dave B(TotalVR)]

Tile based rendering IS the superior approach, this will be proven when PowerVR release their high end Series 5 based PC card.


Won't it Kristof/Simon..

 

[JohnH]

And what if you need to sort sort objects by material/state?

That's an optimization technique, too. There's obviously some balance that needs to be struck (if you're not going to be doing an initial z-pass). I would tend to think that state changes will become less important as world polycounts increase, such that, for programs not doing an initial z-pass, the shift will be towards depth sorting instead of state sorting.

Unfortunately thats an invalid assumption, if you talk to almost any ISV "batch overhead" is currently one of the biggest problems faced when trying to implement scenes with high polygon counts. This is due to the fact that it simply isn't possible to just use more triangles to create a more detailed scene, you actualy have to vary the state more often as well. Its basically the difference between generating a forrect of trees vs a single high detial tree, the former is what you want not the later if you're trying to create realism. So, sorting by state is likely to be prefered to sorting by depth for a long time to come...

John.

 

[KimB]

Which is what geometry instancing is for.

 

[Kristof]

Which is what geometry instancing is for.

And that exactly forces you to do sorting by material/state since all this allows you to do is render lots of things with exactly the same properties... hence no depth sorting is being done except maybe within the same geometry instance but even then with transformations and all thats going on in the VS its all a bit of a pain to figure out where what goes anyway...

K-

 

[Simon F]

Which is what geometry instancing is for.

I don't know why we bother.

John H said a forest which requires many different trees which, in turn, would require many different materials.

 

[JohnH]

Which is what geometry instancing is for.

Which makes depth sorting rather difficult!

 

[KimB]

And that exactly forces you to do sorting by material/state since all this allows you to do is render lots of things with exactly the same properties... hence no depth sorting is being done except maybe within the same geometry instance but even then with transformations and all thats going on in the VS its all a bit of a pain to figure out where what goes anyway...

K-

Fine, but you can (and should) do the sorting among the trees. In the given situation, the trees are going to take up most of the fillrate anyway, so there's not going to be much reason to sort the trees with other objects on the screen.

 

[KimB]

Which is what geometry instancing is for.

I don't know why we bother.

John H said a forest which requires many different trees which, in turn, would require many different materials.

You can combine many materials into one. Geometry instancing doesn't mean that every object will be absolutely identical. There is the possibility of having a frequency which could, through texture lookups or branching, result in dramatically different trees using the same source.

Obviously you're not going to be able to sort them by depth as well as you could if you rendered each tree individually, but there are some techniques you could use, such as dividing the trees up in groups of the same number, and sort these groups instead of individual trees.

 

[Dave B(TotalVR)]

oops double post

 

[Dave B(TotalVR)]

"Obviously you're not going to be able to sort them by depth as well as you could if you rendered each tree individually, but there are some techniques you could use, such as dividing the trees up in groups of the same number, and sort these groups instead of individual trees"


The point is Chalnoth that all of these things that 'could' be done to optimise it dont need to be done at all on a TBR. On top of that these trees are going to be occuluding each other, which is going to make it VERY hard for an IMR to reduce overdraw - these trees are going to be made of small polygons yanno.

IMR's hate small polygons, they cant render them as quads properly and they can force them to use their memory busses very inefficiently.

 

[Rodéric]

Obviously you're not going to be able to sort them by depth as well as you could if you rendered each tree individually, but there are some techniques you could use, such as dividing the trees up in groups of the same number, and sort these groups instead of individual trees.

Or simply used Occlusion Culling which gracefully eliminate most of invisible objects/meshs during the visibility test pass, before rendering everything sorted by material, like any modern engine do/will do.

 

[Gubbi]

Obviously you're not going to be able to sort them by depth as well as you could if you rendered each tree individually, but there are some techniques you could use, such as dividing the trees up in groups of the same number, and sort these groups instead of individual trees.

Or simply used Occlusion Culling which gracefully eliminate most of invisible objects/meshs during the visibility test pass, before rendering everything sorted by material, like any modern engine do/will do.

You'll still need to fill the Z-buffer in a sub-optimal order. And while newer cards has higher Z-fillrate than pixel fillrate it still costs bandwidth, - and you just doubled your geometry load.

Cheers
Gubbi

 

[Simon F]

Or simply used Occlusion Culling

Sorry can you define what you mean by that? Do you mean a Z-only pass or something like visibiliy queries (which are a can of worms).

 

[arjan de lumens]

and you just doubled your geometry load.

Cheers
Gubbi

Umm, if you are using Occlusion Culling (I presume in the form of OpenGL-style occlusion queries) properly, you will normally just pass in a bounding box (usually no more than about 6 quads) in the first pass, then if the box wasn't fully occluded THEN you pass in the object you wish to draw (which may be arbitrarily complex). Hardly a doubling of geometry load.

 

[Simon F]

The trouble is, because of latency, ISVs probably have to use occlusion query results from the previous frame to determine the contents of the current frame.

 

[Gubbi]

and you just doubled your geometry load.

Cheers
Gubbi

Umm, if you are using Occlusion Culling (I presume in the form of OpenGL-style occlusion queries) properly, you will normally just pass in a bounding box (usually no more than about 6 quads) in the first pass, then if the box wasn't fully occluded THEN you pass in the object you wish to draw (which may be arbitrarily complex). Hardly a doubling of geometry load.

Right, if you use occlusion queries. But if you do 2-pass rendering with a Z-pass and a test-and-draw pass you do.

If you're using occlusion queries you're still doing rough sorts of the geometry (at the bounding box level) and hence complicating geometry instancing, which is what I thought sparked this little sub-discussion

Cheers
Gubbi

 

[Rodéric]

Or simply used Occlusion Culling

Sorry can you define what you mean by that? Do you mean a Z-only pass or something like visibiliy queries (which are a can of worms).

I'm refering to software algos, in the case of my engine, it's a very primitive software renderer which uses hand made ultra simple meshs, unlikely to have more than 50 vertices, as Occluders.

Hardware queries are not an option with AGP IMO.

If you're using occlusion queries you're still doing rough sorts of the geometry (at the bounding box level) and hence complicating geometry instancing, which is what I thought sparked this little sub-discussion

As I said (but poorly expressed it), it's done during the Frustum/Visibility test, before being added to auto sorted RenderGraph which will be processed in the next step.

1- Visiblity Test, including Occlusion. (View Frustum Culling, Portals Clipping, Sectors Culling, and Space subdivision trees testing.)
2- Rendering of Objects/Meshs which are not invisible.

 

[Simon F]

Hardware queries are not an option with AGP IMO.

The problem, AFAICS, is that the triangle FIFO and rendering paths are very long so, by the time the query has been processed, you probably have processed the 1/2 the scene. <shrug>

 

[Rodéric]

Hardware queries are not an option with AGP IMO.

The problem, AFAICS, is that the triangle FIFO and rendering paths are very long so, by the time the query has been processed, you probably have processed the 1/2 the scene. <shrug>

I have to confess I've not dive(?) too much into the reasons of the delay, so I assumed it was the AGP bus fault ^^
The sure thing is that currently it's not fast enough.