Support NeoGAF

[Snakeyes]

I posted this in the FFV/VI 3DS thread;

Could the 3DS revive the gorgeous pre-rendered 2d backgrounds that were abundant in the PS1 FFs? Let's take this for example:

Is it feasible to separate that background into a large amount of layers in order to create a believable illusion of depth? A camera a la TWEWY would shift the layers slightly as your character moves around the area in order to retain the effect.

Theoretically, this technique has two benefits;

1. It gives a sense of depth to a static but highly detailed background, making it pleasing to look at and fun to explore.

2. The hardware doesn't need to allocate a lot of polygons to the environments, so those can be used to create more detailed character models.

Thoughts?

 

[Let me in]

1. It gives a sense of depth to a static but highly detailed background, making it pleasing to look at and fun to explore.

This is what I always found irritating, sometimes I couldn't tell what element was background and what was foreground. This is a good idea... for a new game. Please, no 3D port-o-rama.

 

[Luigiv]

I posted this in the FFV/VI 3DS thread;

Could the 3DS revive the gorgeous pre-rendered 2d backgrounds that were abundant in the PS1 FFs? Let's take this for example:

http://i48.tinypic.com/24y8thd.png[IMG]

Is it feasible to separate that background into a large amount of layers in order to create a believable illusion of depth? A camera a la TWEWY would shift the layers slightly as your character moves around the area in order to retain the effect.

Theoretically, this technique has two benefits;

1. It gives a sense of depth to a static but highly detailed background, making it pleasing to look at and fun to explore.

2. The hardware doesn't need to allocate a lot of polygons to the environments, so those can be used to create more detailed character models.

Thoughts?[/QUOTE]
Wouldn't be hard to pull off. Since Pre-[B]rendered[/B] backgrounds are already 3D, you just need to take 2 renders to create the 3D effect (just like 3D CG movies). Hand-drawn backgrounds however (like in Baiten Kaitos) would be much more challenging to implement.

 

[Fafalada]

you're referring to the ps2, i assume?

PS2, GC, Xbox, PSP, Wii... and even the HD Twins, in cases where the PC Codebase is lagging in features and you want to be sure to take PR shots at any time.

what i'm saying is that anything involving tweaks in or around the projection transform will potentially suffer

Actually combining everything into a single transform matrix has been fairly common practice in the past. I've done a lot worse things then just appending Viewport to it too - on PS2 we've also included Conversions to/from Float, scaling of compressed values, and more.

I also wanted to add that having control over Frustrum traversal is pretty much a requirement for anything that isn't a simple tech demo. None of the APIs do anything useful for you in scene management anyway, and if your codebase is meant to be API/platform agnostic, you pretty much have no choice.

 

[Linkup]

Thoughts?

That would explain RE:revs graphics?

 

[blu]

PS2, GC, Xbox, PSP, Wii... and even the HD Twins, in cases where the PC Codebase is lagging in features and you want to be sure to take PR shots at any time.

why would you do manual jittering on platforms that already have hw FSAA?

Actually combining everything into a single transform matrix has been fairly common practice in the past. I've done a lot worse things then just appending Viewport to it too - on PS2 we've also included Conversions to/from Float, scaling of compressed values, and more.

I get the feeling we've been talking past each other for some time now. Let's start from some basic postulates for this problem:

1. We're looking for a comutationally free jittering mechanism, as in 'we want to plug the jitter in a pre-existing pipeline computation'.
2. We're looking for a stable, predictable effect from the jittering (as in 'it works each time we stop to closely look at it'), in every situation that would draw normally without jittering, i.e. it was not broken to begin with.
3. Floats lose precision with range. In expressions of the form (x + epsilon) <op> y, epsilon loses its significance with the increase of magnitude of x and/or y, for every trivial arithmetics operator.

Your're telling me that you can plug the jitter in the projection matrix, and this is how you'd normally do it. I tell you you surely can, but that would yeild accidental success, as there exitst otherwise normal frustums, which would not produce the desired constant jittering across their entire depth because of (3). Coincidentally, vendors like 3dfx, who actually had implementations of accumulated FSAA through jittering, did not do that through jittering of the projection matrix - they jittered the scree-space coordinates, *after* viewport clipping & perspecitve division. Why? Perhaps they were looking for numerical stability of the effect?

I also wanted to add that having control over Frustrum traversal is pretty much a requirement for anything that isn't a simple tech demo. None of the APIs do anything useful for you in scene management anyway, and if your codebase is meant to be API/platform agnostic, you pretty much have no choice.

i don't think i've ever disputed that. unless you misunderstood me when i talked of not having rigid control over the frustum extents - by that i meant that the control is somewhere else in the pipeline (as in 'not at the stage of introducing jitter'), not that the pipeline as a whole does not have full control over the frustum - of course it does. but the pipeline includes factors like artists producing assets, game-logic requirements, etc, so our little jittering logic is not the top authority on the view frustum extents.

 

[Nirolak]

That would explain RE:revs graphics?

RE is more a case of having extremely small and sparse environments in favor of using all the resources on the character models.

 

[lostinblue]

RE is more a case of having extremely small and sparse environments in favor of using all the resources on the character models.

Also called the Doom 3 trick.

I wonder if they can recreate RE4 graphics (it hadn't open environments, but they also weren't exactly closed) on this thing. I dont care if they have Hulk Chris from RE5.

Oh, and the RE4 lighting *drools*

 

[Pimpbaa]

Also called the Doom 3 trick.

They didn't use all resources on the character models. They were very low poly with normal mapping to make them look better. They kept everything simply in Doom 3 just for the lighting (which was really resource intensive).

 

[lostinblue]

They didn't use all resources on the character models. They were very low poly with normal mapping to make them look better. They kept everything simply in Doom 3 just for the lighting (which was really resource intensive).

true, but truth to be told these RE models didn't seem all that detailed as well.

I'll go with the Doom 3 trick. shading and normal mapping on closed spaces.

 

[WillyFive]

I posted this in the FFV/VI 3DS thread;

Could the 3DS revive the gorgeous pre-rendered 2d backgrounds that were abundant in the PS1 FFs? Let's take this for example:

Is it feasible to separate that background into a large amount of layers in order to create a believable illusion of depth? A camera a la TWEWY would shift the layers slightly as your character moves around the area in order to retain the effect.

Theoretically, this technique has two benefits;

1. It gives a sense of depth to a static but highly detailed background, making it pleasing to look at and fun to explore.

2. The hardware doesn't need to allocate a lot of polygons to the environments, so those can be used to create more detailed character models.

Thoughts?

No need for layers. Just have two versions of the same background, and have one of each for each eye, so it would naturally in 3D, no need to separate it into layers.

 

[Snakeyes]

Wouldn't be hard to pull off. Since Pre-rendered backgrounds are already 3D, you just need to take 2 renders to create the 3D effect (just like 3D CG movies).

No need for layers. Just have two versions of the same background, and have one of each for each eye, so it would naturally in 3D, no need to separate it into layers.

So this would create a believable static 3D background and not just a "cardboard cut-out" type of 3D?

 

[Enkidu]

So this would create a believable static 3D background and not just a "cardboard cut-out" type of 3D?

If you used layers like you suggested, then you would pretty much only need a 2D source image to create the 3D effect, although you would get the "cardboard cut-out" feel that you are describing. Rendering the entire scene from 2 different angles gives you a proper 3D feel that isn't layered.

 

[Snakeyes]

Good to know. Hopefully some developers have the same idea.

 

[camineet]

I'm satisfied that 3DS will provide a graphical leap from DS that is worthy of being called next-gen.

 

[Easy_D]

Do you think thing could run luigis mansion? Would the texture quality, poly detail and effects all be there?

Considering how good the RE and MGS demos look I'm pretty sure the 3DS could handle Luigi's Mansion level graphics with no issues at all. The fact that it would only have to render smaller rooms help too.

I'm more worried about if there'll be a sequel/remake/port at all

Edit: Er, did I just quote something from the first page? I fail. :lol

Double Edit: How did I even get here. Sorry for bumping.

 

[Chaplain]

http://gear.ign.com/articles/112/1122613p1.html

New Nintendo 3DS Hardware Info

IGN has learned that the Nintendo 3DS will pack not one, but two 266MHz ARM11 CPUs, along with a 133MHz GPU, 4MBs of dedicated VRAM, 64MBs of RAM, and 1.5GBs of flash storage. The information comes from persons familiar with the hardware who spoke to us under the condition of anonymity.

While we were unable to determine which variation of the ARM11 processors the 3DS will feature, we now have a better sense of the system's capabilities. Currently there are a number of devices being powered by the ARM11, including the Zune HD, a variety of Android smartphones, and prior to the introduction of Apple's A4 processor, the iPhone and iPod touch.

The handheld will also have substantially larger storage capacity than preceding models, jumping from only 256MBs on the DSi to 1.5GBs of flash memory on the 3DS. The total drive space can, of course, be expanded using the 3DS' SD card slot..

 

[ShineALight]

I'd say that that deserves it's own thread.

 

[Why would you do that?]

http://gear.ign.com/articles/112/1122613p1.html

Sounds impressive and somewhat expected...

You really should make a new thread for this, though.

 

[Chris1964]

Make a new thread.

 

[Joe Shlabotnik]

Surprised to find myself most excited about the flash memory size! Holy shit they might actually have robust DD plans

 

[Slayer-33]

"Numerous developers working on software for the platform have likened its graphical capabilities to current-generation consoles like the Xbox 360 and PlayStation 3, albeit on smaller, lower-resolution screens.

The handheld will also have substantially larger storage capacity than preceding models, jumping from only 256MBs on the DSi to 1.5GBs of flash memory on the 3DS. The total drive space can, of course, be expanded using the 3DS' SD card slot."

Holy fucking stripteasing batman.

 

[Bizzyb]

http://gear.ign.com/articles/112/1122613p1.html

:lol

Already Trumps the Wii.

I don't know if I should be sad or happy...

edit: Make this a NEW Thread!

 

[m.i.s.]

Mark Rein, the boss of developer Epic Games, has stated that as far as he’s aware the 3DS is not powerful enough to port over any version of the studio’s Unreal Engine.

3DS ‘below’ Epic’s minimum specs

 

[Gravijah]

Mark Rein, the boss of developer Epic Games, has stated that as far as he’s aware the 3DS is not powerful enough to port over any version of the studio’s Unreal Engine.

3DS ‘below’ Epic’s minimum specs

There was a thread for that:

http://www.neogaf.com/forum/showthread.php?t=409441

 

[m.i.s.]

Oops, did a search and still missed it!!

Doh! :lol

 

[A Human Becoming]

There seems to be a lot of contradictory information. That or some developers have no idea what they're talking about.

 

[Donnie]

There seems to be a lot of contradictory information. That or some developers have no idea what they're talking about.

Its simply a case of one engine, UE3, not being suited to the the 3DS architecture. People are really making far too much out of it. Assuming that its less powerful then Iphones GPU for instance.

Developers working on it now will be playing to its strengths, rather then worrying about the lack of fragment shaders.

 

[wsippel]

There seems to be a lot of contradictory information. That or some developers have no idea what they're talking about.

I don't really see a contradiction. Assuming Rein is correct, it's just that the architecture of UE3 isn't suited for the 3DS due to memory limitations or what not (would have had a lot more weight to it if Sweeney said it, though). We know that other current generation console engines can be brought over. Some have already been ported, in fact - MT Framework isn't the only one. Foundation 9's inhouse engine, Atomic, is also based on their current console engines. And I'm sure Ubisoft uses LyN and possibly even Anvil on 3DS.

 

[Boerseun]

The fact that it was Mark Rein making that comment tells you all you need to know.