Killzone 2 pre-release discussion thread

Status
Not open for further replies.
I think the raytracing aspect is only in regards to physics calculations.
Certainly the rendering engine isn't using raytracing extensively as a raytraced renderer.
Call me ignorant on this Shifty, can you please give me some examples of raytracing based physics calculations in the game? Are you talking about something like shadows or particles?
 
He was talking about raytracing those little holes in the wall. Don't know if that helps though.

This is possible. I'm pretty sure, they do some superduper mega Bump-Mapping for these holes.
http://ixbtlabs.com/articles3/video/vantage2-p6.html
Feature Test 3: Parallax Occlusion Mapping

It's one of the most interesting feature tests, as this technique is already used in games. It draws one quadrangle (to be more exact, two triangles) using Parallax Occlusion Mapping that imitates complex geometry. The test uses resource-intensive operations to trace rays and high-res Z maps. This surface is also shaded using the heavy Strauss algorithm. This test uses a very complex and heavy pixel shader with multiple texture lookups during ray tracing, dynamic branches, and complex Strauss lighting algorithms.
I think they try to avoid flat holes, that we can see in FEAR: When you look at holes on walls, they look deep, but if you look on them from a side, so you see, that they are flat.
So it's some kind of "2D Ray Tracing"?

But you know: It's enough to say, that they are using a little bit Ray Tracing in KZ2, and 95% of all mankind think everythin is ray-traced in KillZone 2.
 
He was talking about raytracing those little holes in the wall. Don't know if that helps though.

This is possible. I'm pretty sure, they do some superduper mega Bump-Mapping for these holes.
http://ixbtlabs.com/articles3/video/vantage2-p6.html

I think they try to avoid flat holes, that we can see in FEAR: When you look at holes on walls, they look deep, but if you look on them from a side, so you see, that they are flat.
So it's some kind of "2D Ray Tracing"?

But you know: It's enough to say, that they are using a little bit Ray Tracing in KZ2, and 95% of all mankind think everythin is ray-traced in KillZone 2.
That's interesting to know, I always tend to think ray tracing is all about light reflections, refractions and shadows. Didn't know it also involves parallax mapping. I wonder if there are any other places where it's present in the game. Thanks for the info.
 
That's interesting to know, I always tend to think ray tracing is all about light reflections, refractions and shadows.
Ray-tracing is about following paths. Traditionally it's associated with tracing paths of light, but it can be used for any path/intersect thing you want. Thus firing a laser-beam, you'd trace the path of the beam to see what object it hits, and then could trace a secondary ray along the direction of reflection if the beam bounces. There's also some confusion between ray-tracing and ray-casting. Ray-tracing can be used for any number of rays, but some people think it should only be used where iterations are >1. If you're only tracing one ray from origin to first object, that's ray-casting. I don't know if there's any official stance anywhere. Because of this confusion, we can't tell how complex the ray tracing is, whether just a simple collision test or an intensive multireflection path tracing.
 
This is possible. I'm pretty sure, they do some superduper mega Bump-Mapping for these holes.
http://ixbtlabs.com/articles3/video/vantage2-p6.html

I think they try to avoid flat holes, that we can see in FEAR: When you look at holes on walls, they look deep, but if you look on them from a side, so you see, that they are flat.
So it's some kind of "2D Ray Tracing"?

But you know: It's enough to say, that they are using a little bit Ray Tracing in KZ2, and 95% of all mankind think everythin is ray-traced in KillZone 2.
Would it still be considered 2D ray-tracing of holes in Killzone 2 when the above translation says "holes are not a flat image of a hole" (assuming the translation holds up)?
 
with 200+ lights in a scene, aint it possible the light-vectors are "raytraced" on the SPUs?
Im pretty sure they wont create 200+ Shadow-Maps =)

The first iteration would be practically free thanks to deferred rendering.
 
with 200+ lights in a scene, aint it possible the light-vectors are "raytraced" on the SPUs?
Im pretty sure they wont create 200+ Shadow-Maps =)

The first iteration would be practically free thanks to deferred rendering.

Only the closer lights cast shadows. Also lights are switched out to simpler lights when they are a certain size, or so it was in the dev walkthrough pdf.
 
Ray-tracing is about following paths. Traditionally it's associated with tracing paths of light, but it can be used for any path/intersect thing you want. Thus firing a laser-beam, you'd trace the path of the beam to see what object it hits, and then could trace a secondary ray along the direction of reflection if the beam bounces. There's also some confusion between ray-tracing and ray-casting. Ray-tracing can be used for any number of rays, but some people think it should only be used where iterations are >1. If you're only tracing one ray from origin to first object, that's ray-casting. I don't know if there's any official stance anywhere. Because of this confusion, we can't tell how complex the ray tracing is, whether just a simple collision test or an intensive multireflection path tracing.
Cool, I see now. Perhaps GG should clarify more on their method of Ray tracing, otherwise it would surely create some sort of confusion amoung the community since raytracing like you described covers a broader range than on the surface. Hope they'll include the "making of" on a bonus disc covering such areas.
 
Ray-tracing is about following paths. Traditionally it's associated with tracing paths of light, but it can be used for any path/intersect thing you want. Thus firing a laser-beam, you'd trace the path of the beam to see what object it hits, and then could trace a secondary ray along the direction of reflection if the beam bounces. There's also some confusion between ray-tracing and ray-casting. Ray-tracing can be used for any number of rays, but some people think it should only be used where iterations are >1. If you're only tracing one ray from origin to first object, that's ray-casting. I don't know if there's any official stance anywhere. Because of this confusion, we can't tell how complex the ray tracing is, whether just a simple collision test or an intensive multireflection path tracing.

So Ray-Tracing is not only for rendering?
Can you also use it for physics etc?

The demo that ATI used to show off the 4800 seies - is that only ray-traced rendering or the super all encompassing ray-tracing?
 
Would it be possible for B3D to interview GG like what CarlB did with High Moon ?

Unlike other media sites, you guys would be able to put things coherently in accurate context, and in simpler user terms.

And I would like to know more of this: :yes:

- they think they can go further and beyond what they're doing with killzone 2
AND they will show us in the future!!
 
Cool, I see now. Perhaps GG should clarify more on their method of Ray tracing, otherwise it would surely create some sort of confusion amoung the community ...
Well, that's more the community's fault ;) What it really needs is someone to ask technical questions if we want technical answers. If people get the wrong end of the stick from a sound-bite it's principally because they don't wait until the right questions are asked to find out what something actually means! "Ooo, they mentioned raytracing. The whole game must be raytraced like offline renders, in realtime!!!"

I would love to see a B3D interview. There's some really intersting tech appearing at the moment, but all we get of it are the occassional dev conference .pdfs. Would be nice if the media could infiltrate the developer side a bit more and open up the entusiast armchair-developer population to some Proper Eduficationizing.
 
https://www.cmpevents.com/GD09/a.asp?option=C&V=11&SessID=8873


The Rendering Technology of KILLZONE 2
Speaker: Michiel van der Leeuw (Lead Programmer, Guerrilla), Michal Valient (Senior technology programmer, Guerrilla)
Date/Time: TBD
Track: Programming
Format: 60-minute Lecture
Experience Level: Intermediate

Session Description
This session presents an overview of the rendering techniques used in Killzone 2. We put the main focus on the lighting and shadowing techniques of our deferred shading engine and how we made them play nicely with anti-aliasing.

In the second part of the presentation we take a look at our engine from the point of view of the CPU and we describe our GPU-driven block based memory allocation system that allows us to generate resources for the GPU out-of-order on multiple SPUs.

Takeaway
Attendees will gain information about rendering technology used in KILLZONE 2 and they will learn about different optimization possibilities the Playstation 3 offers.

Intended Audience and Prerequisites

This lecture is intended for graphics programmers. Basic understanding of common rendering techniques is recommended.
https://www.cmpevents.com/GD09/a.asp?option=C&V=11&SessID=8874


The PlayStation 3's SPU's in the Real World - KILLZONE 2 Case Study

Speaker: Michiel van der Leeuw (Lead Programmer, Guerrilla)
Date/Time: TBD
Track: Programming
Format: 60-minute Lecture
Experience Level: Intermediate

Session Description
This session gives an overview of the usage of Cell SPU’s in the engine used to develop KILLZONE 2 for the PlayStation 3. The techniques used for AI, image- based post-processing (motion blur, depth of field, bloom) and other graphical algorithms are discussed. An overview of all of the SPU usage and scheduling in KILLZONE 2 is presented to establish what SPU’s can do in the real world, in a real game. Some thoughts and lessons learned are presented to help attendees in establishing which SPU uses might help them in their next project.

Takeaway
Attendees get an insight into the SPU techniques used in KILLZONE 2's engine - many of which are generic and can be applied to other game engines. Based on an overview of the entire SPU usage of the Killzone 2 engine, its weak and strong spots and advice based on this use-case, they can make better decisions about their own SPU development strategy.

Intended Audience and Prerequisites
This lecture is intended for game, AI and technology programmers who have to write or design SPU code. A high level overview of the functioning of a game engine is required. Specific knowledge about graphics algorithms or PlayStation 3 programming is recommended, but not required.
old?
 
Status
Not open for further replies.
Back
Top