"Programming the PSP"

[darkblu]

Guys, there ARE clip algorithms that work in object space you know.
That doesn't make the whole process any less dumb though - if I am forced to clip my polys on the CPU for 4 planes out of 6, my clip subroutine pretty much won't change at all if I include the last 2 planes in it too.
It just makes the GPU clip feature redundant - like I said originally.

You would be able to clip the polygons before the T&L then if you do it in Object space... I am not sure of the speed as I have never done clipping in Object space, I should read-up on it a bit...

ok, i admit i had completely dismissed clipping in obj space. whereas i shouldn't have and here's why. speed-wise, given that after that clipping the geometry will actually go through the GPU for transformation and lighting, then what Faf suggests could be quite speedy (clip in obj space by the CPU, then pass result to GPU and forget about it). now, if you just had a VFPU to rely on then things could actually get messy speed-wise as you could end up with more vertices to deal with out of the obj-space clipper than were originally there, so eventually more workload to the FPU (that's why i originally dismissed the scheme - my CPU-only mindset shines through). but with a GPU Faf's way could be very advantageous on the PSP.

 

[Simon F]

Hey, maybe next we'll learn that we can render compressed textures only on every second pixel on screen.

Stop complaining - you just render again using the framebuffer as a texture and sample every second pixel

 

[Panajev2001a]

Guys, there ARE clip algorithms that work in object space you know.
That doesn't make the whole process any less dumb though - if I am forced to clip my polys on the CPU for 4 planes out of 6, my clip subroutine pretty much won't change at all if I include the last 2 planes in it too.
It just makes the GPU clip feature redundant - like I said originally.

You would be able to clip the polygons before the T&L then if you do it in Object space... I am not sure of the speed as I have never done clipping in Object space, I should read-up on it a bit...

ok, i admit i had completely dismissed clipping in obj space. whereas i shouldn't have and here's why. speed-wise, given that after that clipping the geometry will actually go through the GPU for transformation and lighting, then what Faf suggests could be quite speedy (clip in obj space by the CPU, then pass result to GPU and forget about it). now, if you just had a VFPU to rely on then things could actually get messy speed-wise as you could end up with more vertices to deal with out of the obj-space clipper than were originally there, so eventually more workload to the FPU (that's why i originally dismissed the scheme - my CPU-only mindset shines through). but with a GPU Faf's way could be very advantageous on the PSP.

Ok, but this way you would have to clip even vertices that you would cull as they are out of the View Frustum ( sending data from the CPU to the GPU can do automatic culling based on bounding boxes and the display lists

).

If you do culling before sending the display lists to the GPU you are throwing away the feature that they built-in for you.

 

[notAFanB]

so in conclusion, the PSP appears to be hacked together with buzzwords masking it's deficiencies (and overall weirdness), in an pathetic attempt at avoiding critisism for their ineptness at HW design?

Yah, that about wraps it up for PSP. The wretched machine will largely be rejected by developers, and industry leading handheld using PVR-MBXâ„¢ (what else!) will come in the very next day to replace it

hey they stuck with the PS2, they (devs) will stick with this one.

Or... maybe not Seriously, though, from what I've seen of the available videos of the running PSP software, it looks pretty damn fine, and there's nothing that suggest any deal breaking visual issues.

I am going to reserve judgement (not that I could afford one at launch anyway) until I see so titles, but from 'death JR' alone I'm not seeing anything that remotely suggests DC<<PSP<PS2.

My "reliable source" did. He was amazed how the Sony PR engine somehow managed to make all the negatives in the system look like positives....

So, does he confirm there are no user selectable clip planes (only the near clip?) What are those other negatives?

making up non-existent features probably.

 

[Simon F]

so in conclusion, the PSP appears to be hacked together with buzzwords masking it's deficiencies (and overall weirdness), in an pathetic attempt at avoiding critisism for their ineptness at HW design?

Yah, that about wraps it up for PSP. The wretched machine will largely be rejected by developers,

I would never underestimate the power of the dark side.

Or... maybe not Seriously, though, from what I've seen of the available videos of the running PSP software, it looks pretty damn fine,

Really? What did you like? I've only really seen the video of the "island" demo (with a bit of reflection mapping) and "Death Jr(?)" which didn't knock my socks off.

My "reliable source" did. He was amazed how the Sony PR engine somehow managed to make all the negatives in the system look like positives....

So, does he confirm there are no user selectable clip planes (only the near clip?) What are those other negatives?

I'm don't know if there are or aren't. It apparently wasn't that clear. I was going by what I saw in the slides and using some educated guesses.

He did comment on the cracks in tessellation if you need to vary the LOD (Sony apparently said "fill the background with the same colour as the tessellated object"), and he didn't think the post projection guardband space seemed a bit small.

 

[VNZ]

I mean, the emphasized features so far are in the T&L department, quite possibly not hardwired.

Eh? The T&L is obviously fixed.

Probably, but is it confirmed? Not only does it seem silly to waste die-space on skinning, morphing etc -- the fact that Sony claimed the PS2 to have hardware support for bezier surfaces may be an indication that some stuff are indeed driven by the library, not fixed hardware.

 

[notAFanB]

Sony apparently said "fill the background with the same colour as the tessellated object"),

...You have GOT to be kidding me!


doesn't this piss Devs off?????

 

[Panajev2001a]

I mean, the emphasized features so far are in the T&L department, quite possibly not hardwired.

Eh? The T&L is obviously fixed.

Probably, but is it confirmed? Not only does it seem silly to waste die-space on skinning, morphing etc -- the fact that Sony claimed the PS2 to have hardware support for bezier surfaces may be an indication that some stuff are indeed driven by the library, not fixed hardware.

Yes, it is pretty much confirmed.

If the HOS Tessellator was just a VU running micro-code then they could afford to change the algorithm and allow for fractional tessellation and for different LODs for connected patches.

 

[darkblu]

Ok, but this way you would have to clip even vertices that you would cull as they are out of the View Frustum ( sending data from the CPU to the GPU can do automatic culling based on bounding boxes and the display lists

If you do culling before sending the display lists to the GPU you are throwing away the feature that they built-in for you.

not necesserily. you don't have to clip in obj space by the actualy view frustum planes, you could clip by some planes guarding against the too-large-coord condition. that way you'd still take advantage of the built-in clipper logic & at the same time be safe on that dreaded marginal case.

 

[Panajev2001a]

Sony apparently said "fill the background with the same colour as the tessellated object"),

...You have GOT to be kidding me!


doesn't this piss Devs off?????

No, it pisses off modellers .

You have to pay attention to the LOD of the connected patches to avoid cracks: with tools specifically designed for PSP development ( on the PC space with TRUFORM and all, you did not have TRUFORM as the standard on all cards so developers never needed to worry about it much and they did not use it ) some problems should be circumvented in the content creation process.

It is not too difficult to port your PlayStation 2 stuff ( especially with the supposely increased RAM ), but you will need to do some kind of work to port them.

 

[Panajev2001a]

Ok, but this way you would have to clip even vertices that you would cull as they are out of the View Frustum ( sending data from the CPU to the GPU can do automatic culling based on bounding boxes and the display lists

If you do culling before sending the display lists to the GPU you are throwing away the feature that they built-in for you.

not necesserily. you don't have to clip in obj space by the actualy view frustum planes, you could clip by some planes guarding against the too-large-coord condition. that way you'd still take advantage of the built-in clipper logic & at the same time be safe on that dreaded marginal case.

Well, but you are still throwing away the culling work the PSP's Hardware would do for you if you do culling on the VFPU.

If you do not do culling, you need to check all the polygons in the scene ( you still have to separate, and that takes a comparison, the polygons fully or partially inside your custom defined clipping volume and the ones that are fully outside ): if you did culling you could simply check the polygons which have not been entirely rejected. It would be a shorter search.

 

[Fafalada]

he didn't think the post projection guardband space seemed a bit small.

No comment on the tesselation :?
The guardband space is only a problem if the clip is broken in the first place. As I've mentioned in the previous post, the count of polys that require clip with those guardbands(on PS2 guardbands are the same size) is remarkably small (the number I gave includes polygons requiring front plane clip).

Not only does it seem silly to waste die-space on skinning, morphing etc ---

Why do you think I've been saying the clip thing sounds idiotic. If they had a feature starved chip I would at least imagine the die size was a problem, but it clearly wasn't.
As for programmable chip-features, all PR I've seen to date for those did that same thing, but they also all emphasized the programmable nature allowing for any variety of features (as did Sony). If PSP T&L was programmable in the way of VUs I think they would have said something by now.

 

[marconelly!]

hey they stuck with the PS2, they (devs) will stick with this one.

If you read some of the older threads, you'd see that developers who post here actually like working with PS2, (or at least some aspects of it) So, if they're fine with it, who am I to complain?

but from 'death JR' alone I'm not seeing anything that remotely suggests DC<<PSP<PS2.

Noone ever suggested DC<<PSP. I'd be more than happy if it comes close or matches DC games, with perhaps a feature or two above it (particles, maybe)

Really? What did you like? I've only really seen the video of the "island" demo (with a bit of reflection mapping) and "Death Jr(?)" which didn't knock my socks off.

Island demo feature water effects that I've rarely seen even on PS2. To me, that's pretty damn fine for a handheld, when the best I've ever seen by now can't even match PS1 visuals. Death Jr, while obviously quite simple looking game, didn't have any visual issues to speak of, and in fact had some very nice looking effects, and appeared very smooth and fluid overall. It certainly looked better than some of the PS2 launch games Just the thought of seeing what say, Konami can do with the obvious potential for particle effects abuse, makes me intrigued.

 

[darkblu]

Ok, but this way you would have to clip even vertices that you would cull as they are out of the View Frustum ( sending data from the CPU to the GPU can do automatic culling based on bounding boxes and the display lists

If you do culling before sending the display lists to the GPU you are throwing away the feature that they built-in for you.

not necesserily. you don't have to clip in obj space by the actualy view frustum planes, you could clip by some planes guarding against the too-large-coord condition. that way you'd still take advantage of the built-in clipper logic & at the same time be safe on that dreaded marginal case.

Well, but you are still throwing away the culling work the PSP's Hardware would do for you if you do culling on the VFPU.

essentially, it's a-chicken-and-an-egg situation we've got here. :?
but a the end of the day it's a trade-off solution to the deficiencies of that very PSP culling (as it is depicted on those slides)

If you do not do culling, you need to check all the polygons in the scene ( you still have to separate, and that takes a comparison, the polygons fully or partially inside your custom defined clipping volume and the ones that are fully outside ): if you did culling you could simply check the polygons which have not been entirely rejected. It would be a shorter search.

why, your custom clipping could incorporate culling by those same custom planes. ok, let's try to spell things out more thoroughly:

for each object participating in the scene
    cull'n'clip by 4 planes guarding against the extreme-coords consition
    /* that would imply stepping through every goddam vertex, nevertheless perfoming in most of the cases just a dot product and a comparison op, i.e. no lerp op for most of those verts */

get the result from last step and pass it onto the PSP gpu
/* it'd do the much more tight view-frustum cullin'n'clipping, hence carrying the majority of the lerp work */

does that make sense?

 

[Panajev2001a]

why, your custom clipping could incorporate culling by those same custom planes. ok, let's try to spell things out more thoroughly:

for each object participating in the scene
    cull'n'clip by 4 planes guarding against the extreme-coords consition
    /* that would imply stepping through every goddam vertex, nevertheless perfoming in most of the cases just a dot product and a comparison op, i.e. no lerp op for most of those verts */

get the result from last step and pass it onto the PSP gpu
/* it'd do the much more tight view-frustum cullin'n'clipping, hence carrying the majority of the lerp work */

does that make sense?

that would imply stepping through every goddam vertex, nevertheless perfoming in most of the cases just a dot product and a comparison op, i.e. no lerp op for most of those verts

Uhm... I do not know why, but I feel like your hands with blood-proof gloves are getting scarily close to my neck...

I do not mean to piss you off, I know I am repetitive... cannot help it sometimes .

I guess what you say makes sense, lots of it to tell you the truth ( the more I think about it, I was missing the point even though it was quite evident ): so you would use special planes that guard the extreme cases in which a projected polygon could get out of bounds ( 4 planes for up, down, right and left sides of our coordinate system volume [range of possible values] ).

You cull what it is completely outside of those planes and clip what intersects them.

Then you tell the GPU to proceeed with its automatic culling and clipping ( agaionst the regular View Frustum ): I like the culling at the DMA level, if an object's bounding box is outside the visible region then the object does not even get sent to the GPU.

Thank you darkblu .


Edit: if you also used bounding boxes across every model and check those first ( with our custom planes for clip and culling [all the boxes which are completely outside of the solid we are defining are culled and the ones that are fully inside are let be and not even checked for this stage of "early" clipping and culling] ), you would reduce the number of cases you need to watch out for, but I am not saying anything new here.

Edit #2: so, not only you only check a relatively limited amount of vertices ( man, I did not drink this morning... how could I think that you had to check every single vertex in the scene ), but you also only do simple operations ( 1 DOT Product and 1 Comparison ).

 

[Simon F]

If the HOS Tessellator was just a VU running micro-code then they could afford to change the algorithm and allow for fractional tessellation and for different LODs for connected patches.

It wouldn't surprise me if they are just using a DDA algorithm that's outputting strips. That would really only lend itself to fixed tessellation.

 

[Panajev2001a]

If the HOS Tessellator was just a VU running micro-code then they could afford to change the algorithm and allow for fractional tessellation and for different LODs for connected patches.

It wouldn't surprise me if they are just using a DDA algorithm that's outputting strips. That would really only lend itself to fixed tessellation.

You are on the money I think: they have a patent on exactly what you are talking about IIRC.


I will post it later as I gotta run to school now.

Still at least they are able to support both Bezier patches and B-Splines which is better than nothing IMHO.

No, I am not taking glory away from PowerVR and the MBX, each design has its pro's and con's.

 

[Simon F]

Really? What did you like? I've only really seen the video of the "island" demo (with a bit of reflection mapping) and "Death Jr(?)" which didn't knock my socks off.

Island demo feature water effects that I've rarely seen even on PS2. To me, that's pretty damn fine for a handheld, when the best I've ever seen by now can't even match PS1 visuals. .

You ought to get out more

Shame there doesn't seem to be any pictures from the "cutlery" curved surface demo for MBX. It has lots of gratuitous reflection mapping. The Utah teapot demo (for which there are pictures) also has reflection mapping but it's subtle.

 

[darkblu]

that would imply stepping through every goddam vertex, nevertheless perfoming in most of the cases just a dot product and a comparison op, i.e. no lerp op for most of those verts

Uhm... I do not know why, but I feel like your hands with blood-proof gloves are getting scarily close to my neck...

I do not mean to piss you off, I know I am repetitive... cannot help it sometimes .

no, you didn't piss me off (actually something did but that's here at my work). and for the record, i don't use gloves on such occasions.

so you would use special planes that guard the extreme cases in which a projected polygon could get out of bounds ( 4 planes for up, down, right and left sides of our coordinate system volume [range of possible values] ).

You cull what it is completely outside of those planes and clip what intersects them.

Then you tell the GPU to proceeed with its automatic culling and clipping ( agaionst the regular View Frustum ): I like the culling at the DMA level, if an object's bounding box is outside the visible region then the object does not even get sent to the GPU.

Thank you darkblu .

exactly. you're welcome.

Edit: if you also used bounding boxes across every model and check those first ( with our custom planes for clip and culling [all the boxes which are completely outside of the solid we are defining are culled and the ones that are fully inside are let be and not even checked for this stage of "early" clipping and culling] ), you would reduce the number of cases you need to watch out for, but I am not saying anything new here.

Edit #2: so, not only you only check a relatively limited amount of vertices ( man, I did not drink this morning... how could I think that you had to check every single vertex in the scene ), but you also only do simple operations ( 1 DOT Product and 1 Comparison ).

well, yeah, virtually every 3d engine worth its bytes out there has some scene traversal code with early-out conditions based on bounding volumes and what not.

 

[Simon F]

Still at least they are able to support both Bezier patches and B-Splines which is better than nothing IMHO.

No, I am not taking glory away from PowerVR and the MBX, each design has its pro's and con's.

So what do you perceive the cons to be with the curved surface support on MBX?