Reduced os memory footprint

[Stonemonkey]

More memory will not help out for the jagged shadows. Shadows are not textures stored in memory, they are calculated in real-time. So you'd rather need more cpu/gpu cycles than memory.

I'll try to stop the smart-ass-ness now

Actually, the type of shadows that result in jaggy/aliased shadows are textures, well depth maps really but still use texture memory and can be either realtime for dynamic objects or pre rendered for static objects.

EDIT: I'll try to stop the smart-ass-ness now

 

[Sureboss]

I'm 100% certain that the demo is graphically weaker than GT5P. There's no smoke at all, barely any dirt, the trees are just blank, there's no grass at all (all I see is a coat of green), etc. The demo was simply made to the simplest level graphically so that it would be small in size (explains the 200mb size).

You see, for me, the grass is pretty good. I have noticed there are quite a lot of people getting different experiences of graphics (I had one weird glitch earlier, my rearview mirror was just fuzzy, like a TV with no signal), to me, this is just down to the fact at how much effort has been placed in to this demo. The demo has been created for a purpose (GTAcademy TT), and it shows that the QA for this has been a bit more lax than it would be for a full title release/final demo release.

 

[snicker3s]

Actually, the type of shadows that result in jaggy/aliased shadows are textures, well depth maps really but still use texture memory and can be either realtime for dynamic objects or pre rendered for static objects.

EDIT: I'll try to stop the smart-ass-ness now

Already had a bit of a discussion about this earlier in the thread with someone else.

You are right, there would be more memory needed for better shadows (enlarging + making values in this depth/shadow map more precise).

My point is that memory is probably not the bottleneck here, but the processing power needed to produce and apply this larger map to the scene every frame. So the extra memory released by OS would not be any help.

 

[Stonemonkey]

Already had a bit of a discussion about this earlier in the thread with someone else.

You are right, there would be more memory needed for better shadows (enlarging + making values in this depth/shadow map more precise).

My point is that memory is probably not the bottleneck here, but the processing power needed to produce and apply this larger map to the scene every frame. So the extra memory released by OS would not be any help.

Other than available memory for larger maps it could come down to one or two things, pixel fill rate but it's only really a comparison with the target and possibly a write, no texture loookups or shading or anything like that and there's probably not that much geometry being drawn into the maps either. The other thing might be texture lookup when applying the shadowmap but since you need to look up the map for each screen pixel filled regardless of the shadowmap resolution that will only depend on how the textures are cached as to whether it actually makes any difference to read time or not.
There won't be any extra load on the CPU or the geometry unit though.

 

[Strittan]

Sorry for being slow. but does this come with an update, is it there automaticly, or do you need to get new hardware?

 

[snicker3s]

There won't be any extra load on the CPU or the geometry unit though.

Allright I really want to believe you here.

Just tell me were I go wrong (I'll even number my train of thoughts for your convenience )

1)Creating shadow map is basically doing a simplified render of the scene from the lightpoints viewpoint, z-buffer of this render is your shadow map.
2)Only shadow-casting objects need to be rendered, so basically this is the bodywork of the car + buildings and trees...
3)impossible to pre-calculate all possible shadow maps and store them in memory since the cars bodywork does a complete 360 degrees during 1 lap + the combinations with trackside objects would be very very numerous.
4)Reducing the jaggies in the shadows means rendering higher resolution shadow map
5)Seeing the size of those jaggies, doubling the resolution would probably not be enough. You need to go way higher res for smooth shadows
6)rendering things in much higher resolution must mean some kind of cpu/gpu load increase. (Dont know ps3 Hardware enough to know where this calculation would take place)

 

[TBR 427]

Could livetrack be enabled with a gain this small (comparatively, though I can't remember any console game with it)?

You know, the system where the track rubbers in and grips up and stuff, then the rubber gets washed away when it's wet, gets covered in sand and loses grip if it's in...dubai or something, etc.

 

[Stonemonkey]

Allright I really want to believe you here.

Just tell me were I go wrong (I'll even number my train of thoughts for your convenience )

1)Creating shadow map is basically doing a simplified render of the scene from the lightpoints viewpoint, z-buffer of this render is your shadow map.
2)Only shadow-casting objects need to be rendered, so basically this is the bodywork of the car + buildings and trees...
3)impossible to pre-calculate all possible shadow maps and store them in memory since the cars bodywork does a complete 360 degrees during 1 lap + the combinations with trackside objects would be very very numerous.
4)Reducing the jaggies in the shadows means rendering higher resolution shadow map
5)Seeing the size of those jaggies, doubling the resolution would probably not be enough. You need to go way higher res for smooth shadows
6)rendering things in much higher resolution must mean some kind of cpu/gpu load increase. (Dont know ps3 Hardware enough to know where this calculation would take place)

1. Yes.
2. Yes, and the geometry detail of things such as buildings can be reduced a great deal. I don't think the car shadow on the ground is done with shadowmapping, but for shadows inside cockpit only the roof/pillars/steering wheel+hands/bits on dashboard need to be done as well as the simplified trackside objects.
3. The shadows from static trackside objects seem to be some sort of pre calced/baked maps, as far as I can see the only dynamic shadow mapping is done on the interior of the cockpit.
4&5. Yes but there are other things that can be done too like improving the filtering when applying the maps and there's probably a lot of other techniques possible..
6. When you change the resolution of the shadowmap there is no change to the data that is required to fill it, the only difference is in the number of pixels a triangle covers, extra work for the gpu rasteriser, not the cpu.

 

[NUD3]

Rumor says PS4 GPU will have same architechture as dreamcast which reduces GPU load quite well. Essentially GPU has to only calculate things that you see on screen. No doupt there will be shared internal memory like 360 has now.
There has not been any CPU rumors yet but it wont be a cell, that is for sure(cell program was shut down by toshiba and ibm) Cell is just a bad choice for CPU for a gaming system to use. Cell will likely continue to have a nice market in physics and chemistry modelling etc.

you are right about the GPU rumors, the word is that Sony secured console exclusive rights to use the IMGTech Power VR Serie 5 on the next PSP and a high end variation of the Power VR Serie 6 on the PS4, this last onde is supposed to be 3 to 5 times more powerfull than a nVidia or ATi equivalent in 2010/11

but you are wrong about the Cell, IBM only canceled the planned version with 32 SPUs in favor of the development of their brand new POWER7, which is being said to be Sony's choice for the PS4 CPU

and looking at the Power7 specs, its like a Cell CPU, but way more powerfull and easier to deal with "programing wise" as you get 8 main cores running at 4GHz, each one capable of dealing with 4 threads at the same time, and with 32MB of L3 cache implemented in eDram

IBM said that Cell BB programing and development will continue, but "in other forms".. I get that as being "as long as Toshiba wants, as they "owns" the rights of the Cell Technology right now