I have a loader running. I've looked at many of the demos. I have my dev environment setup on cygwin; cvs updated with no errors. This is too cool!
I've read everything I can get my hands on. I'm starting to get the overview. I think ps2sdk is providing access to all the non-graphics h/w pieces plus the basic DMA control to the graphics h/w. I think the graphics libraries are providing coordinated communication to the graphics h/w but only the primitives and the GS effects. I've been looking for the functions or methods that would provide the kind of effects high end games have like smooth rolling terrain or blended polygons making up facial expressions, or character clothing that moves naturally as the character moves and looks like one countinous piece of cloth instead of a couple hundred triangles with all their edges showing. The closest I found was a sample VU0 micro code for bezier curves. The notation stated it was not for actual use; only an example. And it's not exactly what I was looking for. I get how the EE can set up the geometry vectors and the VU and GS can paint them.
I am wondering if I missed something at a more basic level for blending polygons in the GS or is this the kind of thing that's done with custom VU code?
I would like to create a ground plane in my model space that has various elevations. I need it to look natural and have my characters be able 'travel across the ground' without stepping inside the ground or hovering above it. I would appriciate some keywords to point me in the right direction. Thanks guys,
Missing piece from my game development?
by the looks of what your trying to do i would suggest using ps2 linux. they got a better gfx lib, and a better set of libs. using ps2dev you are much more limited on what you can do. you can probably do just as much as you can do in ps2linux, but you got to code a lot of stuff from ground zero. check out dreamgl for some samples of loading models in.
There are 10 types of people in the world: Those who understand binary, and those who don't...
-
blackdroid
- Posts: 564
- Joined: Sat Jan 17, 2004 10:22 am
- Location: Sweden
- Contact:
I think one thing you are looking for is info on how to do bump mapping on the PS2. That's the more common method of making fewer polygons look smoother. There is a paper on normal mapping on the PS2:
http://ps2dev.org/kb.x?T=1098
http://ps2dev.org/kb.x?T=1098
The base blocks are skeltal models of your character and the inverse kinematics applied to the skeleton. That way you can control where (the position and rotation) the foot joint is placed in 3D - according the elevation info of the terrain....characters be able 'travel across the ground' without stepping inside the ground or hovering above it.
Thanks for all the great pointers.
I was a little confused about face normals and normal mapping. I thought they were the same thing. I like the idea of bump mapping vertical surfaces to make them look more like, bricks, windows, the kinds of things you don't have to worry about walking across. And normal mapping when you have a copy of the object in great detail and using that as a 'bump texture' map to reproduce details not found in the low polygon version is pretty slick.
For terrain that is statically defined, and a high resolution exists, a normal map can give the small variations across a polygon that give a realistic look. But since the EE is going to be calculating the foot's position based on the low polygon count model, once the polygon is rendered with bump or normal mapping, is it possible, or noticable for the ground plane to be obviously different than the polygon elevation? An example might be sidewalks and curbs. If I define a street with polygons flat to the street elevation, and then apply a bump or normal map of the sidewalks on each side, from the center of the street it would look like the curbs and sidewalks were higher than the street elevation by [10 inches] and would including the coloring and expansion gaps of the sidewalk without an excessive polygon count. But if my character tried to walk on the sidewalk, it would look like the feet were buried up to their ankles. This is just an example. I expect I'll have to test out the effects. I'm glad to be able to include these ideas in model design before I do a lot of trial and error.
I expect some of my ground planes will have a dynamic elevation change effect and I won't be able to use bump or normal mapping of any existing detailed object. General textures will be okay, like wood, dirt, or stone. I read an article on adding extra polygons on the fly to enhance LOD (level of detail) to close areas. I think that can be extended to add polygons to deformations to maintain a smooth look to small radius surface transitions. In order to accurately compute the position of my animated objects in relation to the resulting surface I will need to add the extra polygons with EE processing as opposed to having one of the VU units add LOD polygons. I assume the VU's are capable of this. the LOD algorithm generates the extra polygons to the GIF but never tries to store them back in the base model data structure. It just occured to me that I could still offload the LOD algorithm to the VU's for ground plane processing and when it comes to character position I can run the same algorithm in EE but just for the polygons close to the character and use the resulting elevation data to position the character exactly where the display unit will end up painting the ground.
I was a little confused about face normals and normal mapping. I thought they were the same thing. I like the idea of bump mapping vertical surfaces to make them look more like, bricks, windows, the kinds of things you don't have to worry about walking across. And normal mapping when you have a copy of the object in great detail and using that as a 'bump texture' map to reproduce details not found in the low polygon version is pretty slick.
For terrain that is statically defined, and a high resolution exists, a normal map can give the small variations across a polygon that give a realistic look. But since the EE is going to be calculating the foot's position based on the low polygon count model, once the polygon is rendered with bump or normal mapping, is it possible, or noticable for the ground plane to be obviously different than the polygon elevation? An example might be sidewalks and curbs. If I define a street with polygons flat to the street elevation, and then apply a bump or normal map of the sidewalks on each side, from the center of the street it would look like the curbs and sidewalks were higher than the street elevation by [10 inches] and would including the coloring and expansion gaps of the sidewalk without an excessive polygon count. But if my character tried to walk on the sidewalk, it would look like the feet were buried up to their ankles. This is just an example. I expect I'll have to test out the effects. I'm glad to be able to include these ideas in model design before I do a lot of trial and error.
I expect some of my ground planes will have a dynamic elevation change effect and I won't be able to use bump or normal mapping of any existing detailed object. General textures will be okay, like wood, dirt, or stone. I read an article on adding extra polygons on the fly to enhance LOD (level of detail) to close areas. I think that can be extended to add polygons to deformations to maintain a smooth look to small radius surface transitions. In order to accurately compute the position of my animated objects in relation to the resulting surface I will need to add the extra polygons with EE processing as opposed to having one of the VU units add LOD polygons. I assume the VU's are capable of this. the LOD algorithm generates the extra polygons to the GIF but never tries to store them back in the base model data structure. It just occured to me that I could still offload the LOD algorithm to the VU's for ground plane processing and when it comes to character position I can run the same algorithm in EE but just for the polygons close to the character and use the resulting elevation data to position the character exactly where the display unit will end up painting the ground.