Have some nice info

Discuss the development of software, tools, libraries and anything else that helps make ps2dev happen.

Moderators: cheriff, Herben

Post Reply
PS2guy
Posts: 6
Joined: Sat Jul 12, 2008 5:08 am

Have some nice info

Post by PS2guy »

EDIT:I fixed up the bump map info as well as gave additional ones

EDIT: And now video proof of PON's lag differences!

I have joined merely to give information, not realy a dev, but I know them all alot and know what they should be doing after comparing math and others. Don't laugh about the below, just think of what it means. It's not realy a complaint on the fact ps2's last gen is technically the same as the first, just an agreement those games give fanboys what they want. I my self am not truly one, but it is tiring to play games that in reality are different from the true peaks. People forget also ps2 stalls and rockets usage on the big polys seen in the resent games too, basically everyone's dream has come true. PS2 is DreamCast to them, though in reality ps2 is basically the GC itself in total math ops (CPU+GS), RAM, VRAM, and the fact GC has only 1 unit filled and other numbers. On with what I came to tell, it's about ps2 running two particularlly supposed can't do effects. This should put ps2 to the GC level it truely is (and remember SW:RS2 = 50%).

EDIT:1+3=4MB, near 7-10Gflops GPU+CPU, 13-15M with around same applyance per poly nearly, 4:1 and 6:1 reduciton ratios (talking of with palletizing).

In Path of Neo, if you play levels at detail 10, then afterwards turn it to 1 and restart, you'll see no change in lag pattern or amount. Even in areas like "taking the floor" without normal mapping at 10, you will see no difference in it's annoyance and pattern. Lastly Havock games on ps2 have the same issue....with lower physics and bare raster graphics without many polys (SC:DA).

HitMan:BloodMoney also slows the same amount when bump mapping is not introduced in areas.

We of course know this is due to not being a PC with non-game processes, requiring lots of RAM. It's also becuase what VU1 realy is, a micro coded universal visual programming unit. It is basically as we know the GL and has no designed for issue side max math usage. The GS yes was designed only for rastering the true GL's effects and things (VU1 of course).

Comparing to a 3rd party hardwired programmer of course, VU1 to him is only for T&L and doing all of this (not even talking of normal mapping, just plain things) out of design like would be VU0. He may also feal that graphics compremise physics, however this is to say VU1 does any of this. In reality it's as free as a PC graphics card. On top of that, there is seriel T&L which boosts it to at least 13-15M t/sec peaked (in terms of way the equation is done, applyance to all polys) and does T&L in coherence to the task of each VU. On that note many people use VU1 only because to them it's as if there is only VU1 alone or parallel, but this only gets 8-10M/sec peaked tops. It also could be true all VU0 underuse with normal game conditions where all from not using it halfly for geometry.

EDIT2: Micro code does not redundantly repeat intermadiate calculations and data as resourced by...

http://www.bringyou.to/games/PS2.htm#PS2ARCH

Because of the fact micro code only does calculations in one repitition, while hardware in situations has to repeat, the effects are littler in math. In basic context, bump mapping is none other then to add pointer math by two methods, neighbor reliant gradient look up for each axis, or reading normals from colors values; these pointers are compared with the light's general point and span to gain their shade quality, and the visible image is carried out in accordance to the shading’s segment makeup in the raster image.

The image of the light's direction or angle in normal or height mapping will not change until the next shading or light map segment. Regular maps and shadings, even blocky, can poke through even when the effect used is indeed told to be normal mapping

http://i96.photobucket.com/albums/l199/ ... 1222578348

http://i96.photobucket.com/albums/l199/ ... 1222578400

http://i96.photobucket.com/albums/l199/ ... 1222578454

http://i96.photobucket.com/albums/l199/ ... 1222578543.

This is because phong is not truly the certain per-pixel shading equation done to equal the result, it is merely to interpolate the normals rather colors, merely it uses the pixel shader for normalization per fragment.

http://www.whisqu.se/per/docs/graphics8.htm (see real phong)

Looking at many tutorials helps show that this per-pixel shading is more in the lines of an equation of the XYZ of verious factors

http://playstation2-linux.com/download/ ... apping.pdf

Parallax mapping, similar to bump mapping, also uses an overlain cube map, and can be seen doing the same thing by reducing it’s resolution. In reality phong, like Gouraud, is just another shading type for the raster process, if the eye is indeed telling the truth.

Lastly, it can be taken into account the term "to add detail without existing polygons" has been used for general texture mapping already. Therefore, another rarely used description could be more correct; to correct texturing’s fixed angle of light to the light source’s in real-time. The other implyance leads to thinking that it is only for use of a computer generated look; however, even 2d graphics and artwork usually have surfaces correct to a light source.



EDIT: Height Mapping = 1 plane of data, Normal mapping = 3 planes.

Next height mapping is much lower in math and everything, it's enough to put it as lower costing then 2-3 pass (per light) emboss. Height mapping in otherwords only needs 1 pass (all lights), not only this it doesn't cary true data in every pixel (neghbor reliant for data). Of course it's more in calculation and ops to do then emboss however, but it's appearently still alot less then normal mappings math usage. In reality the supposed flatness is fixable by using a paint program to adjust contrast at no cost.

Lastly on characters, a tutorial can be found for implamenting object space normal mapping on boned animated meshes and means ps2 doesn't need to deal with any tangent space factors if this can work.

http://www.3dkingdoms.com/tutorial.htm

It is probably worth any tiny artistic reworking for any performance boost. It could be applied into height mapping too.

Could Ps2 do height mapping with a nice distance reduction on all things on the new Alone in the Dark? Yes, physics are all seperative to VU0/FPU and one additional unit/pass won't do so much heavy damage. To the most you'd only need additional LOD work (or actually use VU0 too if not!).

Picture this for the last Splinter Cells. PON uses 256x256 shadow maps, SC3 on low res shadowing is 256x256. Same as SC1 on high for projector mode. Also a z-map can be done at half to quarter the res of the shadow map without quality loss. This means DA could had looked much the same. Now that look of the high end versions actually may not cost so much with heights. A problem with some people is thay think looks are what to go by, but this means to go by the un-trained eye. These are the same that don't beleive that GT3 did use less then quarter of ps2, yet by comparing numbers it would be true. GT3's poly amount is enough to be VU1 only, it has a dead environment and really still is just an other car game with wiser friction settings. It also has no damage model. R&C has at 50%.

If anyone here actually still codes for ps2 games, this would be an easy thing to experiment with. Height mapping does not take any time to do, merely compute gradient for a height field and use an extra pass/unit. After this you'll probably wonder why devs out there never did even quick height mapping on everything for alot of ports and games.

Ps2 has been so underminded it probably would not be pathetic to even go back and make remakes of high priority games with an HD or DC on the lable. People would flock and buy them like mad too, even if they mocked the idea at first. This is not to ask if anyone would do this, I would be surprised if this is actually a forum for devs of store games. This to go beyond the box and take those two effects as regular.
Last edited by PS2guy on Tue Dec 23, 2008 5:20 am, edited 4 times in total.
PS2guy
Posts: 6
Joined: Sat Jul 12, 2008 5:08 am

Post by PS2guy »

Ok sorry about this but I just wanted to notify everyone on the edits made to the post, nothing more.
PS2guy
Posts: 6
Joined: Sat Jul 12, 2008 5:08 am

Post by PS2guy »

Heres a video on youtube finally here to prove it.


http://www.youtube.com/watch?v=0-A-NjRwmgs
J.F.
Posts: 2906
Joined: Sun Feb 22, 2004 11:41 am

Post by J.F. »

Okay, that does a good job of showing Normal Mapping, but how about a little something on Height Mapping. You claim that it's a wonder cure, but present absolutely nothing on it. Maybe an overview and an example would be in order. Maybe a page on how Height Mapping is done.
PS2guy
Posts: 6
Joined: Sat Jul 12, 2008 5:08 am

Post by PS2guy »

EDIT: In case of confusion, I mean the first ever form of bump mapping, not the typical high poly manipulation via map.

Well here is a link to a pdf showing some basics on it. This is all about ps2, so ignore the example of a game screen (half life 2 shot, PC or Xbox ver). The below has info near the end about normal and height mapping (noted as just bump mapping I presume).

http://graphics.cs.cmu.edu/nsp/course/1 ... meProg.pdf

Not sure how helpfull it is however in terms of an actual tutorial, but it's a good base. There is a statment about it in the first ever normal mapping tut for ps2 by IO interactive. It states how it does not replace normals, but purturbs them. It uses a gradient look up of a height field to compute pointers/deltas which. It also uses as stated, one plane of data rather three. This means that operations are slimed a decent amount overall by the above.

It also uses less in multi-pass, as normal mapping has to have 2-4 passes.

Basically for now, I can also tell that by adjusting the contrast in simple art programs, that height maping can give a deep look also. Anim8or, which I work with also, uses only height maps. However, by looking at many pictures found on it's own site, dependantly on what you look at, you couldn't tell to a point.

If this isn't what you meant, notify me.

I think I know what you mean however, to show in image how height mapping doesn't differ too much in image?
J.F.
Posts: 2906
Joined: Sun Feb 22, 2004 11:41 am

Post by J.F. »

Yeah, that was what I meant (using the gradient of the height-map to perturb the normals). I suppose then a "standard" DOT3 normal bump-map operation is done with the perturbed normals? This is all well beyond home-brew... you're lucky if the PS2 home-brew does hardware 3D at all, much less any form of bump mapping. :D
PS2guy
Posts: 6
Joined: Sat Jul 12, 2008 5:08 am

Post by PS2guy »

Actually, normal mapping does no actual pertubing I think. It actually uses the maps to replaces or adds new ones.

This could be true about the homebrew thing. If I ever wanted to help show this to one who can develop an actual game, i'd need a different forum. However, down the road, this may become possible for home brew. I see many hacks for NES and SNES that are truely ground braking. Some are also things I never sought as possible (such as a TMNT them running perfectly off the DPCM channel).

I'm so annoyed by todays ps2 games looking not even as impressive as first or second gen games that I would like to find one of these and show them the vid.


BTW, heres an exelent pic of what grayscale height maps can do.

http://www.anim8or.com/gallery/gallery14/face-happy.jpg
J.F.
Posts: 2906
Joined: Sun Feb 22, 2004 11:41 am

Post by J.F. »

The main reason you probably won't ever see bump mapping on PS2 home-brew is the lack of memory - just about every game out with source that uses bump-mapping requires far more RAM than the PS2 has. We're talking enhanced Quake 3 engines. Bump mapping would have to be part of someone's original project, and those kinds of projects are usually far below the level of needing bump mapping.
User avatar
jbit
Site Admin
Posts: 293
Joined: Sat May 28, 2005 3:11 am
Location: København, Danmark
Contact:

Post by jbit »

J.F. wrote:The main reason you probably won't ever see bump mapping on PS2 home-brew is the lack of memory - just about every game out with source that uses bump-mapping requires far more RAM than the PS2 has. We're talking enhanced Quake 3 engines. Bump mapping would have to be part of someone's original project, and those kinds of projects are usually far below the level of needing bump mapping.
ps2kit (my homebrew engine) supports normal mapping, although nothing is released using it yet (waiting on an okay from some people). And sparky (the guy who originally did the usable PS2 bump mapping technique) released some SPS2 demo susing it.. It's not that hard if you support texture streaming.
Also it would not surprise me if several of the PS2 demos use the technique ;P
J.F.
Posts: 2906
Joined: Sun Feb 22, 2004 11:41 am

Post by J.F. »

That's pretty cool. Didn't realize there were so many things using it. :)
PS2guy
Posts: 6
Joined: Sat Jul 12, 2008 5:08 am

Post by PS2guy »

J.F., also think of the two StarWars games on GameCube. It made this fully bump mapped xbox looking masterpeice of a game out of nearly the same memory. I think GC only has a bigger CPU cache over ps2.

In terms of cache on the VU1, i'd say that with PON's acheivments, there is no real worry. If grayscale was used with LOD, then that's less calculation and instructions to be fed for the use of bump mapping.
J.F.
Posts: 2906
Joined: Sun Feb 22, 2004 11:41 am

Post by J.F. »

Think someone could release a simple demo of bump-mapping on the PS2 with source? Right now, homebrewers have to try to reinvent the wheel to do bump-mapping, which might be a better explanation of why there's so little PS2 homebrew with it.
Post Reply