Half-Life 2 XB360 won't be using tiling to achieve A.A.
- Thread starter Brimstone
- Start date
SSAA (in traditional sense) pretty much sucks ass. You have no control over sample positions, and being stuck with ordered grid really doesn't help aliasing nearly as much as it should, especially relative to the amount of work you waste on it.Shifty Geezer said:
And with your hypothetical scenario with infinite CPU cycles I'd happilly use it to do edge AA instead, get both better AA and far less shader load.
I don't know why you'd need more than 4x AA in any X360 game. Sure, you could use it, but the benefit would not be worth it. And I severely doubt that super sampling gets around tiling when multi sampling does not.Acert93 said:
My current crackpot idea is:
* Render Z-only pass with 4x MSAA and write out to memory without resolving.
* Manually resolve to largest Z sample per pixel.
* Set resolved depth buffer as current depth buffer.
* Render color to no MSAA back buffer, reading in the 4 Z samples and computing pixel coverage based on depth comparison.
That might run acceptably fast. Might not. It seems pretty well suited to Xenos from my armchair programmer viewpoint. The coverage/depth comparison would definitely be the trickiest part.
Also, it seems like you might be able to do something clever with the size of the eDRAM. That is, it can store 10 bytes/pixel at 720p. That's like 3 16-bit RT's. Maybe some sort of coverage or frame buffer distortion data could be stored in the extra 16 bits.
DuckThor Evil
Legend
Simon F said:Just don't look at the nutritional information section on the label ... the fat content is scary
I've started getting chunkier AFTER i stopped eating Nutella! It obviously has some secret ingredients that make u slim. And cure cancer. And helps world peace. In fact, i'm sure Israel and everyone else would be so much happier if they had a jar of Nutella with them at all times.
Oh and .... HL2 no tiling on 360 = bad. And stuff. AA.
Just to stay on topic.
DuckThor Evil
Legend
Simon F said:Just don't look at the nutritional information section on the label ... the fat content is scary
Well Humans should take about 20-30% of their calories from fat, so as long as you keep those figures in mind you're okay, and besides it's so GOOD!
I'd imagine it depends on the cost of the dynamic list of geometry you are building every frame or so vs a static, permanently stored list of geometry.Shifty Geezer said:If we talk theoretically for a moment, let's say you have a finite GPU and unlimited CPU cycles to spare (but you're not writing a software rasterizer
Dynamic geometry is expensive if it needs to be written to slow memory first, by the CPU, only to be read from the same slow memory again, by the GPU. It would be nicer if the GPU could source data from a cache or something similar ...
Also there may be overheads in establishing, accessing and modifying dynamic vertex buffers at the API level. Systems with very light-weight APIs or outright to-the-metal coding will be the most tolerant to dynamic geometry.
===========
I like Nutoka. Nutoka is a cheap Nutella knockoff c/o ALDI. I used the name for lots of female RPG characters.
zeckensack said:
Isn't this supposed to be possible on the 360 by locking parts of the cache (or just the other way around using memexport,writing to the cache?). Although you would have to lock quite a big chunk of the already very small cache (166kB/Thread) to do this i guess.
The same is also possible on the PS3 iirc (RSX reading back from SPE LS).
I'm with Faf on this one: I doubt the guys at Valve are doing SSAA. It's more likely they are rendering to a non MS render target and then using some kind of post processing blur to "soften up" the hard edges. Which makes a lot of sense in their situation, given a game with an engine designed and written for a completely different architecture. I could guess it would have cost too much to retrofit tiling into their existing architecture.Acert93 said:
Also Source is a strictly single pass engine and that's how it has been used by the artists on HL2, and making this decision was a good move for the architecture they designed the engine for. With this architecture they could increase the poly count. This idea doesnt match too well with the R500 where it looks like a good idea to go for a multipass approach where you accumulate several lighting passes and take full advantage of full speed additive blending to a HDR render target (fp10). In this scenario, you can't sustain the same poly count, even more when you count tiling in: lot's of work has to move from vertex to fragment, which is not a big deal since they share the same resources in a USA.
Said that, it all comes down to the design choices you make for your engine: Valve decision to not use tiling is a good one in their situation, it doesn't necessarilly mean it's a good one in every other situation. Which means EDRAM is not a liability in itself, although tiling imposes some heavy limitations to the engine architecture and needs quite some work to be implemented and maintained. It also opens up several interesting possibilities.
In my opinion you can (have to) design an engine for the 360 architecture to take full advantage of EDRAM; and have MSAA2X at 720p, hdr and various post processing effects, with good visual quality and complex environment, with soft shadows casted on every object and being casted by every object, at a reasonable framerate.
Fran/Fable2
I've never liked Nutella and I started hating it when I had a girlfriend in Alba (where they make Nutella). Having to smell it every weekend everywhere i moved in the town was unbearablenAo said:that's why I stopped to eat nutella several years ago..
(but it's SOOO gooood
Fran/Fable2
Platon said:
Not to go too far off topic but has any dev come out and said they are working on an engine geared specifically for 360 yet or are the peices to the puzzle (devkits) still not complete enough (recent tiling update) to unlock all of the features in 360 to make it worth while?
Last edited by a moderator:
TheChefO said:
As far as I know, no. But I can imagine, or rather be certain that some of the in house devs at least, make their own engines. Bungie for sure are making their own engine, which hopefully will exploit the xbox360 hardware as much as possible. Big Blue Box, I guess are others that make their own engine, and as does Rare, I have even heard that the different dev teams inside Rare even make own engines, which sounds rather, hmmm... stupid and waste of resources. Atleast the teams above, and hopefully more, will try and exploit as much as possible the xbox360...
Platon said:
I think Rare has typically made multiple engines.
I'd imagine Goldeneye and Perfect Dark were one, with the rest of their games based off the Banjo-Kazooie engine. (with diddy kong racing being a significantly altered version of that engine)
On the last gen, I'd imagine Conker was a heavily evolved version of Starfox Adventure's engine. Grabbed by the Ghoulies and Kameo may have been their own engines, and Perfect Dark Zero was most likely it's own engine. At the very least though, it does make some sense for them to seperate their platformers and shooters into different engines.
Vysez said:I can do both. I'm cool just like that.
Well, I can explain it simply, given that the papers and presentations linked in this post go into the gritty details already.
MB is obtained in Real-Time by rendering the frame you want to see motion blurred first and then an offset buffer, or velocity buffer, in second. Offset buffer which is calculated on a per vertex basis (according to the movement direction) and then stored in screenspace (RGB, like a Normal Map, if you will). And finally you apply a blur on the pixels of your original frame based on the vectorial (movement) information stored in the offset buffer.
And as they say a picture worth a thousand words, so here's some pictures to illustrate that:
You render the frame you want to se motion blurred, in this case a tunnel:
You calculate the velocity information and then buffer it, store it into screenspace RGB information, this gives you something like this (without the pointing arrows, of course
And finally you apply your blur effect (akin to the ones you have in Photoshop, Matrix Convultion and the like) to the frame. the amount of blur applied per pixel, relatively to the other pixels of the frame, is determined by your velocity buffer:
Pictures shamelessly stolen from an Ati presentation and uploaded to xs.to.
I hope that this explanation was of any use to you, or to anyone else.
And here's the promised paper and presentations:
An academic paper on a RT implementation.
http://www.dtc.umn.edu/~ashesh/our_papers/motion-blur.pdf
A sample article from the excellent ShaderX book series, from an implementation from Ati guys:
http://www.ati.com/developer/ShaderX2_MotionBlurUsingGeometryAndShadingDistortion.pdf
An Ati presentation that sum up the technique in more simplistic terms:
http://www.ati.com/developer/gdc/GDC2005_BringingHollywoodToRealtime.pdf
You have other sources on the subject in the references section of these papers.
Thanks Vysez for taking the time to go out of your way on this subject and explaining this technique in detail to us non-programer types out here. :smile:
Great post!
