Support NeoGAF

[hitgirl]

Playing through Metal Gear Solid and Vagrant Story and for a second I thought my Ps1 was being buggy. But then I remember that PS1 polys jitter/warp like crazy. What is the technical explanation behind this. Example -

https://www.youtube.com/watch?v=hX_5XeB-VHQ

 

[Shadow Hog]

Lack of proper perspective correction and sub-pixel vertex placement, I believe? You'd have to ask somebody else for a more specific breakdown as to what that entails, but it's why polygons and textures alike warp around in specific scenarios.

 

[cloudyy]

No Z-buffering.

 

[vagabondarts]

Isn't it the textures not the polygons themselves?
I don't know the technical answer but I know the aberration you are talking about

 

[DrFunk]

No Z-buffering.

there we go

 

[hitgirl]

No Z-buffering.

Oh, yea. That would explain it.

 

[MedIC86]

nvm

 

[10k]

No Z-buffering.

yup.

 

[alr1ght]

I remember having this on my HTPC with movies and was reading about it. Had something to do with Telecine and Three two pull down Im not sure if this the same, but could be.

That has nothing to do with it. That's just how 24fps content is displayed on 60Hz monitors.

 

[MedIC86]

That has nothing to do with it. That's just how 24fps content is displayed on 60Hz monitors.

Ah yes you are right kinda logical since its all rendered.

 

[ArjanN]

 

[angular graphics]

No Z-buffer. PC ports that had perspective correction were a godsend!

 

[hitgirl]

Did Saturn have this too?

 

[TheYanger]

Ok, I'm no tech guy so I'm looking for a legitimate answer not trying to be snarky, but I thought the Z buffer was what controlled the system knowing what to draw? IE: the flickering when things are displaying objects from underneath each other would be accountable to no Z buffer, but the actual warping textures should be unrelated shouldn't it?

 

[Mindman]

Did Saturn have this too?

Yes. Ugly stuff. But not as ugly as the dithering in PSX games.

 

[Clear]

Generally its the lack of Z-buffer, meaning that everything is drawn using the "painters algorithm" that stipulates you have to draw every poly from back-to-front within the scene.

What this means in practice is every view has a distinct sequential draw-order that shifts according to the perspective its viewed from. You could automate this, but the most efficient method was to store (typically 8, using an octant principle) independent sort-lists per object, plus a global scene order that is calculated algorithmically.

Key issue is that using the painters algorithm, not every shape will work from every angle causing flickering as the code does its best to do things in the right order.

Additionally the lack of perspective-correct texturing in hardware meant that you had to use tesselation in order to prevent things become a blurry mess. i.e you would subdivide one poly into multiple smaller ones and adjust the UV (texture coord) values accordingly to spread the image out correctly. This process is lossy due to precision issues and again could cause jittering as the new UV's failed to match up perfectly.

 

[TheYanger]

Generally its the lack of Z-buffer, meaning that everything is drawn using the "painters algorithm" that stipulates you have to draw every poly from back-to-front within the scene.

What this means in practice is every view has a distinct sequential draw-order that shifts according to the perspective its viewed from. You could automate this, but the most efficient method was to store (typically 8, using an octant principle) independent sort-lists per object, plus a global scene order that is calculated algorithmically.

Key issue is that using the painters algorithm, not every shape will work from every angle causing flickering as the code does its best to do things in the right order.

Additionally the lack of perspective-correct texturing in hardware meant that you had to use tesselation in order to prevent things become a blurry mess. i.e you would subdivide one poly into multiple smaller ones and adjust the UV (texture coord) values accordingly to spread the image out correctly. This process is lossy due to precision issues and again could cause jittering as the new UV's failed to match up perfectly.

Ok THIS makes a lot of sense to me, thanks

 

[efyu_lemonardo]

What this means in practice is every view has a distinct sequential draw-order that shifts according to the perspective its viewed from. You could automate this, but the most efficient method was to store (typically 8, using an octant principle) independent sort-lists per object, plus a global scene order that is calculated algorithmically.

If I understand correctly, does that mean the PSX wasn't actually rendering a 3D scene, but rather approximating it by interpolating between pre-calculated views?

 

[Krejlooc]

If I understand correctly, does that mean the PSX wasn't actually rendering a 3D scene, but rather approximating it by interpolating between pre-calculated views?

No, it means the draw order for object lists had to be provided manually, either through an algorithm or by hand, as opposed to automatically calculating z depth from a z buffer.

 

[AuthenticM]

Did the N64 support z-buffer ? Is that the reason why that console's graphics output was "cleaner" ?

 

[efyu_lemonardo]

No, it means the draw order for object lists had to be provided manually, either through an algorithm or by hand, as opposed to automatically calculating z depth from a z buffer.

If I understand correctly, 8 different draw orders were pre calculated per object. I assume these 8 lists corresponded to 8 different viewing angles. So what would the hardware do to render an object from an angle that wasn't close enough to one of those 8?

Some form of interpolation must have been performed..

 

[Tain]

This is related to why it's impossible to make a general-use stereoscopic rendering solution for PSX emulation, right?

 

[killbox]

most engines also allowed the artist to "push" object forward or back in the sort order to try and stop z fighting.

smaller polys helped the shimmer, but your tri count was very limited.

some engines were better with handling the shimmer....
I think Crash Team Racing had the most solid handle on it.

 

[JPickford]

I think the jittering is more down to the lack of sub-pixel coords so each corner of a triangle effectively snaps to the nearest pixel making models looks sort of wobbly.

All the other stuff is true as well (lack of Z-buffer, perspective correction etc.).

N64 had all that so it was a much more sophisticated renderer. Unfortunately it was also a lot slower than PS1 and had a small texture cache so you got a lot of blurry textures.

 

[Krejlooc]

If I understand correctly, 8 different draw orders were pre calculated per object. I assume these 8 lists corresponded to 8 different viewing angles. So what would the hardware do to render an object from an angle that wasn't close enough to one of those 8?

Some form of interpolation must have been performed..

He's saying you would store 8 object order lists to efficiently switch between them, he's not saying those lists werent generated.

Presumably, if you need a new camera angle, you just recalculate the object order list.

 

[Krejlooc]

This is related to why it's impossible to make a general-use stereoscopic rendering solution for PSX emulation, right?

Right, there is no z buffer to draw depth from.

 

[Sword Familiar]

I think it's charming.

 

[MarkV]

Generally its the lack of Z-buffer, meaning that everything is drawn using the "painters algorithm" that stipulates you have to draw every poly from back-to-front within the scene.

What this means in practice is every view has a distinct sequential draw-order that shifts according to the perspective its viewed from. You could automate this, but the most efficient method was to store (typically 8, using an octant principle) independent sort-lists per object, plus a global scene order that is calculated algorithmically.

Key issue is that using the painters algorithm, not every shape will work from every angle causing flickering as the code does its best to do things in the right order.

Additionally the lack of perspective-correct texturing in hardware meant that you had to use tesselation in order to prevent things become a blurry mess. i.e you would subdivide one poly into multiple smaller ones and adjust the UV (texture coord) values accordingly to spread the image out correctly. This process is lossy due to precision issues and again could cause jittering as the new UV's failed to match up perfectly.

This is a very good explanation for such a little text, do you teach stuff?

 

[K' Dash]

Fake 3D, that's why.

 

[efyu_lemonardo]

He's saying you would store 8 object order lists to efficiently switch between them, he's not saying those lists werent generated.

Presumably, if you need a new camera angle, you just recalculate the object order list.

He says the relative depth of all objects per any given viewing angle could be calculated in real time. But that's not the same as calculating the relative depth of all polygons in real time, which is what a true painter's algorithm would require.

 

[SeventhSon]

Fake 3D, that's why.

Every thing is fake 3D.

 

[komplanen]

Every thing is fake 3D.

That's deep.

 

[DieH@rd]

Fake 3D, that's why.

Making videogames = trying to find all the ways to fake everything as fast as possible

 

[WillyFive]

The jitter always bothered me when playing PS1 games, but it didn't bother me much with the Saturn for some reason. Turns out the poor colors of the PS1 visuals did a lot to exacerbate the problem for me.

Did the N64 support z-buffer ? Is that the reason why that console's graphics output was "cleaner" ?

That along with texture filtering and anti-aliasing helped the N64 visuals stand out from the PS1 and Saturn. Solid objects staying solid was great, it's easy to forget how good we have it now.

 

[Krejlooc]

He says the relative depth of all objects per any given viewing angle could be calculated in real time. But that's not the same as calculating the relative depth of all polygons in real time, which is what a true painter's algorithm would require.

You should be able to calculate the depth per poly from depth per object.

 

[AuthenticM]

That along with texture filtering and anti-aliasing helped the N64 visuals stand out from the PS1 and Saturn. Solid objects staying solid was great, it's easy to forget how good we have it now.

Thanks. Though I still prefer the look of PSone games over the N64's. It might have had more jaggies, but it also had more detail, as opposed to the muddy and shitty-looking textures of the N64.

 

[SeventhSon]

That's deep.

lol, yeah

All the video techniques for rendering "3D" are optical illusions; a "3D" image on a 2D surface.

Until we are dealing with projected holograms we can walk around, all 3D will be fake.

 

[LiK]

I learned something new

 

[TheD]

Generally its the lack of Z-buffer, meaning that everything is drawn using the "painters algorithm" that stipulates you have to draw every poly from back-to-front within the scene.

What this means in practice is every view has a distinct sequential draw-order that shifts according to the perspective its viewed from. You could automate this, but the most efficient method was to store (typically 8, using an octant principle) independent sort-lists per object, plus a global scene order that is calculated algorithmically.

Key issue is that using the painters algorithm, not every shape will work from every angle causing flickering as the code does its best to do things in the right order.

Additionally the lack of perspective-correct texturing in hardware meant that you had to use tesselation in order to prevent things become a blurry mess. i.e you would subdivide one poly into multiple smaller ones and adjust the UV (texture coord) values accordingly to spread the image out correctly. This process is lossy due to precision issues and again could cause jittering as the new UV's failed to match up perfectly.

FFS, it has nothing to do with a lack of Z buffering! (or tessellation, which very few, if any games used).

The reason it jitters when an object or the camera moves is due to a lack of subpixel correct rasterization.

 

[jett]

It's too bad this can't be fixed in emulation.

 

[Metal-Geo]

I think it was due to the lack of floating point (precision) calculation. Not due to the lack of a Z-buffer. Because the reason the vertices move about isn't due to depth, but due to lack of precision.


But I'm not PlayStation hardware guru.

 

[mattiewheels]

Kind of related-yet-unrelated, but speaking of weird graphical issues, I always wondered why the graphics in the Dragon Quest games ported to DS were so wavy and warped. The screen was fully rotatable, but I don't think VII on PSX suffered from it, and that had the same rotatable screens. Was it a specific problem with the DS that made it that way? Always looked strange to me.

 

[Ottoni_Bastos]

Lack of Z-buffer!

 

[sniperpon]

I've always heard that it wasn't the polygons "jittering", but the textures due to the lack of what has been coined "perspective correction." Is that correct?

 

[Palpable]

This happened a shit ton in RE.

 

[VARIA]

I actually liked the effect.

 

[clintar]

probably has to do with low precision when keeping the position of points in 3D space, so what would probably need to be at (22.1372942,-1.6243222) becomes something like (22.13,-1.62), so they kinda jump around in 3D space instead instead of going to an more exact spot.

 

[BocoDragon]

This thread makes me feel dumb.

 

[- J - D -]

Swimmy vertices are great indicators of the era, but I'm glad we never have to deal with them again.

Now if we could only deal with aliasing on console games.

 

[jett]

Kind of related-yet-unrelated, but speaking of weird graphical issues, I always wondered why the graphics in the Dragon Quest games ported to DS were so wavy and warped. The screen was fully rotatable, but I don't think VII on PSX suffered from it, and that had the same rotatable screens. Was it a specific problem with the DS that made it that way? Always looked strange to me.

From what I remember, that's what DQ7 looked like on PS1. All a lot of stuff in the environment had this weird distorted look to it, that's how it was modeled.

This carried over to DQ5 on the PS2 too