NEW Lair Screens Plus Interview!

That's like saying the problem with a subdivision surface is that you can't educate it to act as a modeler.

I think about the subdivision schemes exactly like that; our internal wiki has the almost exact sentence in the modeling docs for a year now ;)
Subdivision won't do any modeling, won't add any detail, just smooth out the jagged curves. What you don't build into your model, you won't get it by letting the computer to chop up its polygons and average out the tensions between the vertices.


Yes, procedural generation which can only be guided by some abstract seeds is useles most of the time ... I don't see the relevance though, since that's not the kind of procedural generator you would actually use.

You can't design a level by adjusting the parameters of a procedural generator only... it has far too much effect on the gameplay...
 
Subdivision won't do any modeling, won't add any detail, just smooth out the jagged curves. What you don't build into your model, you won't get it by letting the computer to chop up its polygons and average out the tensions between the vertices.
You can still add local detail without giving up all of the benefits of the subdivision surface there though.
You can't design a level by adjusting the parameters of a procedural generator only... it has far too much effect on the gameplay...
My point is that you would not use something with generic parameters, just like with subdivision surfaces you use something which can work with local restraints (to whatever detail you wish to provide).
 
What you could do is to store the data in a displacement map, but even that would neet a lot of space: a 16K*16K 8 bit texture requires 256 MB of memory if I'm correct; and you can probably compress it a little more. But that would give you 256 levels of elevation, so even with 1 meter high changes you could still not use mountains.
thats prolly the worst way to store a terrain (sure its the easiest)
buw u could
A/ start at a point, and neighbouring vertices are stored as offsets (linear or log) handles mountains/vallys no problem + uses 1/4 the memory, also easy to do
B/ store terrain as patches eg 4x4blocks or 8x8 (like jpeg/dxt)
each block contains a height + offset pattern value, thus 3/4bytes per block thus youre down from 256mb -> 16mb + i believe u will see no visual difference. i must try this out
 
You can still add local detail without giving up all of the benefits of the subdivision surface there though.

What you're talking about is an extension called hierarchical subdivision surface.
 
thats prolly the worst way to store a terrain (sure its the easiest)
buw u could
A/ start at a point, and neighbouring vertices are stored as offsets (linear or log) handles mountains/vallys no problem + uses 1/4 the memory, also easy to do
B/ store terrain as patches eg 4x4blocks or 8x8 (like jpeg/dxt)
each block contains a height + offset pattern value, thus 3/4bytes per block thus youre down from 256mb -> 16mb + i believe u will see no visual difference. i must try this out

good idea but i'd find it surprising if it wasn't already in use in some similar way. conceptualy it's the same as some movie compression schemes. but then i do over estimate people at times.
 
Last edited by a moderator:
Captive did...

Yep, and though it was really a great game it had its flaws due to that fact. In the 2nd and 3rd world (not dungeon, but restarted rescue missions), each had one level where the "key" for a switch puzzle was beyond the area that the switch opened. The one in the second world was solvable, because the switch only had 8 elements (<= 256 tries). But the one on the third world had 16 elements so that's where the game sadly ended for me... ;)
 
Yep, and though it was really a great game it had its flaws due to that fact. In the 2nd and 3rd world (not dungeon, but restarted rescue missions), each had one level where the "key" for a switch puzzle was beyond the area that the switch opened. The one in the second world was solvable, because the switch only had 8 elements (<= 256 tries). But the one on the third world had 16 elements so that's where the game sadly ended for me... ;)
Yeah, the 3rd galaxy bug was there and a doozy, but given that the game provided plenty of hours gameplay up until that point, I don't think it was a killer! I was bored by the second galaxy (although it was a pretty great game for its time). The solution to that key was available though, and I know people passed it and played on and on. Addition of a text-console could resolve issues in future procedural games. You know, the sorts of consoles used in RPGs where even with the human designer they're bugged and impossible and need instructions to be typed in...;)
 
good idea but i'd find it surprising if it wasn't already in use in some similar way. conceptualy it's the same as some movie compression schemes. but then i do over estimate people at times.
no doubt ppl have done similar things in the past though fom my experience 'ppl (including myself) typically are lazy + take the easiest/most understood path'
comparring it to movies is valid + shows how well itll possibly work
eg take jpeg take a file of 1mb compress it 10:1 + theres visually little difference
now with heights u will get much better results
eg u only have to worry about luminance (height offsets) + not any other variables eg hue
also the differences of heights in a block is gonna be far far less than in a photo, eg terrain doesnt go from 0->200meters within 1 meter
typically a steep hill is like a 20degree gradient
also texturing anything with gradients over ~45degrees looks crap anyways due to the texture stretching
 
Interesting comment: Cell does all the polygons!!

In this months EGM (November), Julian Eggerbrecht states; The Cell generates all the polygonal models in the game, from the soldiers, creatures, and terrain (32 Kilometers square). While handling all the A.I. :oops:

I’m guessing many developers will probably be using the RSX mostly/only for pixel-shader and effects purposes. I knew the Cell was a badass…but damn!!

Edit: Also all Lairs ultra-hi-resolution textures stream off the Blu-Ray Disc (No HDD help?).
 
Last edited by a moderator:
I guess beauty is in the eye of the beholder!? :???:

Anyhow the mag Lair pics are actually nice looking. :smile:

Not trying to say LAIR is ugly or anything, it's a beautiful game. I would personally love to see something focused on RSX and Cell working together to make a beautiful looking game.
 
In this months EGM (November), Julian Eggerbrecht states; The Cell generates all the polygonal models in the game, from the soldiers, creatures, and terrain (32 Kilometers square). While handling all the A.I.
When he says generate, I presume he doesn't mean draw. And that's normal! The CPU generates the vertex data which is fed to the GPU to render.
 
When he says generate, I presume he doesn't mean draw. And that's normal! The CPU generates the vertex data which is fed to the GPU to render.

I’m assuming no; because that would be kind of lame of him to mention something that obvious and trivial. Plus his statement about that, is section off, from the main article. It’s pretty much a section where he spouts the Cells abilities among other things.

Edit: He's also states it's here
IGN: Quick ****** wars question -- Could Lair be done under its current spec on the Xbox 360? If so, why go with the PlayStation 3 "only" instead of going cross-platform?

Eggebrecht: Lair in its current form couldn't be done on 360. We are using large amounts of Cell's SPUs for all of our geometry, landscape, simulations, animations, even troop AI. When we create a game, we absolutely focus on the platform it is designed around. Would we do one for 360, it would be a different game and a different engine -- most crucially perhaps though: Lair is an entirely different game without the motion control and gesture recognition since it was designed around it.
 
Last edited by a moderator:
That makes no sense. Why use Cell for ALL geometry?! That's a bit of a waste, when RSX is more than capable at handling lots of it. Besides if the RSX vertex shaders are not used, that's a wast of resources too as they're left unused, unlike Xenos.
 
I think what he says is that the Cell SPU's are used for aspects of / in all geometry.
 
Back
Top