OT
Who would that guy be and what did he do?
Is tesselation possible on the PS3?
- Thread starter Butta
- Start date
Who would that guy be and what did he do?
I'm thinking of Dave Perry and the tech behind Messiah. Is there another guy out there Faf?
I didn't mean it literally about the same tech.
ID going with virtual-texturing is comparable departure from established workflow and pipelines though (and it remains to be seen if it'll have any sort of long standing impact).
But now that I think about it - there's one that is close to this discussion. Naughty Dog in PS2 days both ditched C++ compiler (which was more risky then any tech change IMO) and went with dynamically tesselating most things (though it wasn't a uniform approach, so not quite what Shifty was talking about).
Anyway I suppose I should have said "recent history" rather then "to date", because going back in time to days of one-man teams and no established workflows, tech was pretty much the main differentiator.
ID going with virtual-texturing is comparable departure from established workflow and pipelines though (and it remains to be seen if it'll have any sort of long standing impact).
But now that I think about it - there's one that is close to this discussion. Naughty Dog in PS2 days both ditched C++ compiler (which was more risky then any tech change IMO) and went with dynamically tesselating most things (though it wasn't a uniform approach, so not quite what Shifty was talking about).
Anyway I suppose I should have said "recent history" rather then "to date", because going back in time to days of one-man teams and no established workflows, tech was pretty much the main differentiator.
And on the PS2 Snowblind Studios did megatexturing to some extent also for Champions of Norrath, didn't they?
Fortran as a sort of high-level language in which they described their game-engine, right? I understand they spent a lot of time rewriting everything and switching to C++ for the PS3, so their tech would be shareable with other teams.
Didn't know about the tesselation in Jak & Daxter though, thanks.
Well, main is maybe an exaggeration. But relatively everything was new back then, and the standards of production were lower and much cheaper, so certainly more experimentation was possible. I think these days we mostly remember the outstanding products, and not the copies - that tends to happen.
Not Fortran. They wrote their own Scheme dialect and compiler. It was totally insane.
That's news to me. They had superb texture quality that lacked annoyingly repeating textures, but I just assume that's due to their great artists. The random dungeons were created with assembled tiles, which is what filled up the full dual-layer DVD - each tile had to be rendered pre-lit in different orientations. If they added megatexturing as well as everything else they did, then their reputation isn't anything like as big as it deserves to be!
No, it was actually discussed here on the forums even. Check here:
http://www.igda.org/Forums/showthread.php?threadid=28586
This mentions Baldur's gate, but I found another post that references it being used in Champions as well. The fact that they had random dungeons just means (I think) that they had parts on the megatexture that they could randomly swap around while loading them in?
Don't think I ever saw that.
That thread describes something a bit different from megatexturing - a simpler texture selection optimised to a nicely contained view.
Which is OT. But on topic, BGDA did have dynamic tesselation on the water IIRC.
Old topic, but GT6 is coming out this week and features adaptive tesselation. However, I'm now actually wondering a little if this isn't also de-tesselation. I'm guessing that with the high detail that cars have in that game, you could have 16 car models in memory at max detail, but when rendering them you could have SPU pre-culling and 'pre-detesellation' to make the models simpler for actual rendering, rather than having different LOD models in memory.
Another option however is that it is used for the older car models that are still from the PS2 version, had less polygons, and adaptive tesselation is now used to increase detail on these. For cars, I think a dedicated algorithm that knows what cars generally look like could also really help I think in predicting how to increase the detail level?
EDIT: here's the presentation
Though not much actual info in there.
Another option however is that it is used for the older car models that are still from the PS2 version, had less polygons, and adaptive tesselation is now used to increase detail on these. For cars, I think a dedicated algorithm that knows what cars generally look like could also really help I think in predicting how to increase the detail level?
EDIT: here's the presentation
Though not much actual info in there.
What exactly is stopping the Cell from being a tessellator for the GPU? Too slow communication between it and the RSX?
And for the sake of saying it, BF2/2142 have some sort of tessellation built into the terrain LOD.
And for the sake of saying it, BF2/2142 have some sort of tessellation built into the terrain LOD.
Like every other system out there, nothing in particular.
But even when you have dedicated tessellation hardware in the GPU which allows you to do the tessellation itself at a very low cost, it's not guaranteed that developers will use it all over the place (or at all). It's just difficult to apply well in a widespread way.
Developers usually think it's more worth their time and/or computational resources to use the CELL for other things.
No, nothing is stopping it, that's exactly what GT6 is doing.
The fact it's busy doing all sorts of other things for the GPU.
Nothing stops you from performing various forms of tessellation on cell. The problem is that you can't bypass the vertex portion of the gpu, meaning whatever geometry you finally end up with still has to be rammed through the vertex pipeline of the video hardware, which happens to be fairly limited on that particular hardware. That ultimately limits the potential of tessellation on that platform irregardless of what cell can compute.
Tessellation of cars is a good idea because real cars themselves are designed out of curves originally. Even if you cannot finally push a huge amount of vertex data on the RSX, doing it on the SPUs does mean you can dynamically balance the the verts you are pushing depending on how many cars you have on screen, the size they are being rendered and the environment. It also means less memory, less data to load. Again like terrains and characters, cars could be seen as a different case..
btw its not technically the first GT game to use tessellation , as GT1 and GT2 used it on PS1
(but that was on the road)
btw its not technically the first GT game to use tessellation , as GT1 and GT2 used it on PS1
(but that was on the road)
btw its not technically the first GT game to use tessellation , as GT1 and GT2 used it on PS1
(but that was on the road)
That's new to me. Do you know if it was processed in real time or was it just a part of the production pipeline for ease of LOD generation? I know a bike racing game on the Original Xbox (sorry, forgot the name) did the latter, and it had the clever trick that it only sotored the higher LOD, and derived the subsequent ones by halving the vertecies progressively.
Plenty of games tesselated large surfaces on ps1 to get rid of the artifacts caused by lack or perspective correct texturing.
I'm not sure if any of the games actually changed surface topology as well.
Oh, that much I knew. hahaha. The context made me think you were talking about something more evolved. Still, the Xbox on... I mean... Original Xbox game I mentioned was MotoGP, here is a link about it's tessalaltor for those who had not seen it before:
http://blogs.msdn.com/b/shawnhar/archive/2009/06/03/motogp-curved-surfaces.aspx
How did that worked to correct the perspective of the texturing? Curious.
I didn't correct it, it just amenized the artifacts. They'd commonly subdivide quads into 4 smaller quads once the surface was close enough. There would still be warping at steep angles, but in a smaller scale.
