Pre-rendered 3D

>>2944024
The stock responses are "pre-rendered looks like ass" / "pixel arts looks awesome". If you can spare the time, please do chime in with some actual argumentation on why do you think this is so

>>2944024
It's like they didn't even try to clean Diddy's sprite.

I would definitely be down for a game with pre-rendered visuals but for some reason young gamers are really turned off by the style.

https://www.youtube.com/watch?v=SEj7M1ft4sM

>>2944039
>for some reason young gamers are really turned off by the style.
They're scum.

>>2944024
I would straight up say no but the idea of being able to accurately take the 3d render to a 2d form now would be easy to do now and honestly I would love to see a DKC where everything wasn't scaled down

>>2944024

What would be the point? Even the prettiest possible prerendered game will look like ass compared to a modern 3D game. The animation will be jerkier, the lighting will have discontinuities, the camera will be less dynamic and unless the sprites were designed with 4K in mind, it won't be as sharp.

>>2944039
>but for some reason young gamers are really turned off by the style.

And Miyamoto.

>>2944024
Sounds interesting, but sincerely i dont think the average gamer would support the idea.

I'd rather have a dkc remake in a full 3D environment (with the same photorealistic style of the originals)

It was the only reason the series was popular. The gameplay was very subpar and unimaginative given the number of excellent platformers of the day.

>>2944106
Don't forget the god tier music, anon.

>>2944118
Like this song:

https://www.youtube.com/watch?v=jMoroEuJPA8

>>2944106
>given the number of excellent platformers of the day.
Like?

>>2944106
>dkc series were only good cause graphics meme
nah, the second game introduced several gameplay mechanics, added a lot of extra material and replay value, and managed to improve what was already impressive. even the gameplay was smoother and more consistent.
the third game was pretty much the same except for the shitier music and visuals (also the autistic baby 2bh)

>>2944126
Plok

It never looked good and DKC was't anything special until 2

>people don't like pre rendered


jesus christ people have awful taste.

>>2944087
It'd be simpler to program from the ground up than an actual 2.5 platformer, and exporting prerendered CG from Maya or Blender or whatever would be faster and more practical than handmade sprite art.

>>2944089
dumb internet rumor he's already denied.

File: mldreamteam.jpg (44KB, 450x270px) Image search: [Google]

44KB, 450x270px

Mario & Luigi Dream Team did this with its character sprites. The game uses 2D sprites made from prerendered 3D models, it looks really nice and reminds me of what SMRPG could've looked like on better hardware. Definitely one of the better looking 3DS games aesthetically.

>>2944024
Five nights at freddies seems to do okay.

>>2944035
Yep, it's true, it's doubly shameful for being something easy to do and on a main character sprite too.

>>2945136
They're actually not prerendered from 3d models. The artists got rid of the outlines from past M+L games and upped the framerate, sure, but they're still hand-drawn sprites.

The style is meant to resemble "3d" though, so you aren't totally wrong but I still wanted to point this out

>>2944032
>If you can spare the time, please do chime in with some actual argumentation on why do you think this is so
Because pixel art fakes higher resolution by aligning features of the art to pixel boundaries. It's the graphical equivalent of font hinting. And the distortions needed to achieve this have a distinctive style of their own, so pixel art becomes a valid genre of art.

Pre-rendered 3D on the other hand is just a shit version of normal 3D. There's literally no reason to use it now that modern hardware exists.

>>2944024
>mid-90s 3D pre-rendered craze
That shit run into the early 2000's and ruined the GBA's library. Though some managed to pull it of, most didn't. Fuck you Rare.

File: 1452735462962.png (6KB, 158x159px) Image search: [Google]

6KB, 158x159px

>>2944024
Personally, I've never been a fan of pre-rendered graphics on older systems. They try to circumvent rather than work with the tile-based technology to give the illusion of quality. A lot of the opportunity for interesting art unique to the medium goes out the window when using this technique.

I think Yoshi's Island turned out to be such a graphical success partially because there was a protracted battle between the execs and artist over this issue. The execs wanted to replicate DKC's success with CGI while the artist argued for hand-drawn graphics. The influence of this tug-of-war can be seen in the wide variety of art direction of YI, and I think the artist made their point quite well that working intimately with your restrictions rather than circumventing them can lead to outstanding results.

That being said, hell yeah I asked my parents for Donkey Kong Country when I was a kid.

>>2945582
Joke's on them. The 3DS remake uses tons of prerendered stuff; finally, the producer's creative vision was properly realized

Well, there are developpers that make eroge using pre-rendered cell-shaded sprites from 3D Custom Girl. So I guess there's still a public for those.

>>2944042
agreed.

>>2944087
what was that? Resident Evil HD Remaster looks amazing. Prerendered extravaganza

>>2944024
>Would a game developed today with throwback visuals emulating the mid-90s 3D pre-rendered craze have something close to an actual audience?
Yes. Five Nights at Freddy's.

File: lostvik2.png (100KB, 640x240px) Image search: [Google]

100KB, 640x240px

I was going to make side-by-side comparison pics with pre-rendered graphics and not, I know a lot series went pre-render back then, but I think I need more notable examples than just Lost Vikings 2 or HoMM.

>>2944035
>clean a sprite

what's that mean? erasing the grey spots?

>>2945989
Yeah, they're obviously a leftover from the grey background of the renders. If not erase them, at least change their color to be more consistent with the surrounding pixels. Donkey's alright in this respect.

>>2944024
I've always been of the opinion that 90% of pre-rendered 3D look like shit. I much prefer the look of games with competent art direction like Plok or Yoshi's Island as opposed to games that just use pre-rendered 3D as a cheap trick to look realistic.
That's not to say pre-rendered 3D can't have competent art direction, but it's usually used in place of it.

>>2944024

I think so. Remember that people didn't take pixel art seriously at first either.

I have a current obsession with pre-N64 early 3d, PSX and Saturn and 3DO and early DOS and so on. I think that is going to become a valid art style someday.

Pillars of Eternity used late 90s/early 2000s style pre-rendered graphics.

The game was pretty boring, but it certainly looked great.

>>2945160
BS, Diddy's sprite looks fine and was the best with the limitations they had. For a top quality high budget Rare game that's a pretty strange accusation to come up with.

>>2946672
I think his sprite is cleaner than DK's, perhaps because of his big eyes and hat which are easy to read from far away

>>2944024
I don't know much about the actual creation of games but pre-rendered graphics are most useful for machines that have lots of storage but weak processing, right?

>>2947959
Only in the most roundabout sense. In that something like that was physically impossible to render in 3d in any sort of consumer hardware in 1994. DKC isn't a huge game, you don't really need that much storage space because the sprites and backgrounds aren't any larger than any other platformer.

Some PC games have really high res pre-render backgrounds, those probably took up way more space. The BG games max out at a 1 gig full install IIRC.

>>2948128
The original BG install was 5 CDs and most of those discs' content was huge area bitmaps, a full install was more than 2 GB then. They managed to compress them for later revisions, and the one I have is only 3 discs.

I find that prerendered backgrounds can be nice, but characters usually have that plastic appearance and they look like toys.

>>2944024
As long as you described the game in the hipster style of your post I'm sure you could convince hipsters to be an actual audience.

>>2944717
Of course he would deny it NOW, after DKC has become one of the most successful Nintendo franchises. Letting one of your most iconic designers shit on your games is bad PR. But back then it was likely for him to be pissed that Nintendo wanted him to use pre-rendered graphics for the next Mario game, which is why he gave it a super-cartoony style and justified it by using 3D background objects to give it an edge over DKC without using ugly CG art.

>>2944712
There would be no difference in terms of programming the engine, as it's sprite based regardless. The only thing would be, instead of providing a billion high resolution images on disc, that you'd have to stream and keep in memory, you just provide a model, and render it via parallel projection (no need for full world transform) into the "sprite". From there on the engine is just as 2D as it always was, but you get perfect resolution and smooth animation, even if the future will bring higher refresh rates or resolutions.

>>2945692
and it'll look like ass again on 16k HDRR displays. Never underestimate the development of technology.

Also, the only thing prerendered in RE are the backgrounds, which tend to not move as much. In fact, the RE characters are 3D models precisely for the reasons >>2944087 mentioned. More flexible and fluent animation, more faithful lightning and camera alignment

>>2945563
"pixel art" relies on the output being of very limited resolution. The endless "filter" fights we have nowadays are precisely because bitmaps do not define an interpolation method (nearest neighbor IS an interpolation method). Just like pre-rendered 3D is made obsolete by modern hardware, pixel art is made obsolete by it as well. In this case the high resolution takes away the need to tune the pixels, and the variety of resolutions requires to step away from bitmaps altogether and instead go for high quality vector art

>>2946672
they're talking about the grey pixels at the hat. They're a result of the render being anti aliased and in front of a grey background. You either got to render to transparent and support alpha, or render to a sharp outline.
It's not an issue of limitations but of wrong render settings or lazy cropping.

>>2949320
>nearest neighbor IS an interpolation method
It's not, because there is no standard number of subpixels per pixel. On CRTs it's not even consistent across the entire screen. Integer ratio nearest neighbor is literally the same thing as increasing the pixel size (with more subpixels per pixel).

>>2947959
correct, you need a shitton of memory to hold that sprite data, especially if you want to pretend these are not 2D sprites, but 3D models. People understand sprites to have a limited set of views. 3D models, not so much.
That's why on modern hardware it's much more efficient to just keep the 3D model around and render it just in time into the memory reserved for the sprite, or even straight into the scene, keeping a single pass render

>>2949326
>you need a shitton of memory to hold that sprite data

You do not. The SNES does not, by any definition, have "a shitton of memory". Including by early 90s definitions.

>>2948736
>but characters usually have that plastic appearance and they look like toys
That's an artifact of the time. The plastic look is a result of using a phone shader for practically everything. It's possible, and has been done in the past, to render these objects with very realistic materials, that match the quality of the background

>>2949325
A pixel is not a little square. A pixel is a sample, within a logical grid. Its surroundings are undefined in terms of data. In order to map that logical grid onto a physical pixel grid, you need to computer intermediate samples. The most simple approach is to just take the value of the nearest sample, the nearest neighbor filter. Without doing that, you'd have a screen full of undefined pixels, as none of the screen pixels match the logical pixels.

>>2949290
>Random /vr/ user telling me to believe him over Miyamoto on Miyamoto's opinion.
>Calling Miyamoto a liar

This fucking meme about pre-rendered being crap and Miyamoto hating it and how superior you are by not liking DKC graphics has to be the most retarded faggotry ever.

>>2949330
it has more memory than 3D processing power, so it's more efficient to store prerendered images for all the sprites you want to use, instead of computing their looks just in time.

File: 0575.png (37KB, 240x160px) Image search: [Google]

37KB, 240x160px

>>2949330
also, you omitted the very important "especially if you want to pretend these are not 2D sprites, but 3D models". Because the implication here is that a 3D model can show any movement frame at any angle, and can have a lot of these frames. Bonus points if you can accessorize it (different player character outits, for example). With a 2D sprite you quickly hit a limit there, with tens of thousands of frames, which won't fit anywhere, SNES or otherwise. That's why 2D sprite animations, especially during the SNES times, have few frames that handle repetition well (loops), and avoid different angles (sidescrolling).
Compare against a game like Tony Hawk on the GBA. They decided to use a parallel mapped untextured 3D model for the player sprite, on classic bitmap backgrounds. The reason was what I mentioned above. The player needs to be able to perform any trick at any angle (movement direction and slope), with any of the skaters. That would have been way too much for even GBA carts. Keeping a handful of 3D animations on the cart though, and rendering them just in time, was possible, and ultimately done.

>>2949335
>none of the screen pixels match the logical pixels
Lets say you have a native 640x480 LCD and you want to display 320x240. Simply declare each pixel on the LCD as being made from 12 subpixels, and now it has a native resolution of 320x240. How you update those pixels is an irrelevant implementation detail, just like if the pixels are made of 3 subpixels. "Pixel" isn't something with an objective hardware definition, it depends on intention.

retro or not, pre-rendered looks like ass.
pre-rendered images looked bad in Mortal Kombat and pre-rendered 3D looked bad in Donkey Kong. You can only enjoy this games with some pink tinted nostalgia googles.

Donkey Kong Country ruined Rendering Ranger. It was supposed to be handdrawn and named Targa. I mean, in the end the game is one of the best looking prerendered games, but still, I want to see Targa.

>>2949451
logically a pixel is a sample within a grid, no exceptions. That applies to logical images, physical displays, anything. On the hardware level, a pixel is the smallest element of a raster display (subpixels are smaller, but incapable of reproducing the full color space). When outputting data on a raster display, a transformation from logical pixels to physical pixels must take place. That is, for each physical pixel the color must be determined based on the logical pixels. Whenever there's no exact match for a lookup, for example if the display has a different resolution, even if it's an exact integer multiple, an interpolation needs to be applied, to "guess" the missing sample.

In your example, declaring them as "12 subpixels" means that each of these "subpixels" has no equivalent on the logical image data, they map to parts of the logical image, that are not defined by a sample, so an interpolation needs to be applied, to fill in the blanks, and determine a color for the physical pixel. Nearest neighbor is one such interpolation. Bilinear is another common one. There are more complex interpolations with different qualities, some of them generic (bicubic, sinc), some of them domain specific (sal, super eagle)

>>2949338
Wasn't he a producer for DKC? if there was anything in the game he didn't like, it wouldn't be in there - he's fucking Miyamoto, his word is basically law.

>>2949484
Doesn't matter what Shiggy thought, the rest of Nintendo of Japan's execs were impressed by DKC's graphics. And he's only given "Creator of Donkey Kong Arcade" in the DKC credits.

>>2949467
>they map to parts of the logical image, that are not defined by a sample
They're exactly as defined as in the 3 subpixel case. Alternatively, you can say that the 12 subpixel case is really a 3 subpixel case, and the subpixels are overlapping and have weird non-contiguous shapes. If this is "interpolation" then native resolution is also interpolation. In no case do you ever have infinitely small pixels.

>>2949524
logical pixels are infinitely small, as they're point samples by definition. Physical pixels have a size, but for lookup reasons they're usually approximated as singularities. Usually, because when downsampling (several logical pixels result in one physical pixel) the sampling area can be defined by the shape of the physical pixel, though I'm not aware of any system actually doing that beyond approximating that region as a simple square. Also subpixels usually don't get their own lookup. The pixel is assumed to be one entity.

>If this is "interpolation" then native resolution is also interpolation
At native resolution each physical pixel's representation maps to a logical pixel in the image. It is not necessary to interpolate values. Physical interpolation happens by virtue of the physical pixel having a size and shape. That is, the physical output of the sample is not infinitely small, but has a size and shape. This might be a square of 3 colored lines (some LCDs), it might be a square of 4 colored squares (some OLEDs), it might be a blurry line (some CRTs), it may be a blurry circle (some other CRTs), it may be a cluster of light bulbs (stadium display), and so on. The common factor is that there's no control on the output below the size of a pixel, it's the smallest element of the raster display. So treating it logically as a singularity is a reasonable approximation. Otherwise the display driver would have to know the physical offsets of RGB components (the assumption of RGB components may not necessarily hold true) and perform a lookup for these offsets. I'm not aware of any software performing that kind of lookup.

>They're exactly as defined as in the 3 subpixel case
As described above, physical pixels are usually treated as monolithic entities. As such, there's a perfect match for each physical pixel, even if the subpixels are not physically in the exact same location. Per-subpixel lookup is highly uncommon, if it happens at all.

File: Memoria-Ocean-ffix.png (182KB, 384x336px) Image search: [Google]

182KB, 384x336px

>>2944024

My suggestion would be, if you're going to make a pre-rendered game, just make it at a 1:1, high resolution -- that is, not the low resolution that suits pixel art. I think that would look fantastic because you can get all kinds of detail and the lighting/shadows and anti-aliasing will be as perfect as you render machine will allow. You get this nice WYSIWYG effect where everything is as the artist intended. Compared to real-time 3D, where on different machines, people might have to turn off AO, FXAA, turn down the resolution, turn off color correction, etc. And the animations might glitch or something. With pre-rendered that will never happen, everyone sees the final "beauty" render. Plus there's a huge performance boost because everthing is essentially baked to a quad, like how thousands of trees are billboarded for performance in a crysis game.

It's a great idea, but probably, if you're going to work in 3D, it's like you may as well just make it real-time, to get all the real-time benefits (dynamic rotation, perspective, lighting, animation blending, etc.)

>>2949579
on top of that, you are not stuck with prerendered or realtime 3D. A third option is rendering just in time. So what if it takes your GPU a full second to render that single static background? That's time you can use for a fancy transition effect, or start rendering it off-screen when you're about to leave the screen (player hovers over a "exit screen" marker), and then you can re-use that pic. You can render any camera angle and lighting conditions, but still get all the beautiful looks.

>>2949590
that's kind of what a lot of old 1st person dungeon crawlers do. The view of the dungeon, with the paths branching to the side, traps and whatever else matters at the moment is rendered just in time, from a small set of standard elements. It does not have to be realtime, since the rendered view is static, and players can handle transitions that take a couple frames.

>>2949590

Maybe if this is for a mobile game, that would make sense. Because you could reuse all the 3D assets but pre-render/bake at run-time to get the best possible render. For modern PCs, you have a case of diminishing return, ie. theres no point when you can brute force the same render on a medium/high end card and reasonably get the same result.

>>2949621
it's trivial to push a modern high end card into single digit fps and lower. Just add some radiosity and drop some imposters. The subject was rendering visuals that are too demanding for realtime. I just suggested that instead of pre-rendering everything, requiring large amounts of storage, rendering just in time, without a realtime requirement, can be a reasonable in-between option.

>>2949635
It's not a terrible idea or anything, but you still have a significant trade-off. Really, really nice static images, vs. average nice graphics that are fast and dynamic (as in, a fps where you can run around in it). In this case, I think you would have to describe the gameplay mechanics that justify the use of this just-in-time technique, I mean for people to be on board and truly understand what you're trying to do.

>>2944039
That was hideous. I recognised the main character from playstation magazines back in the day, I think. Game looked alright; reminded me more of Jazz Jackrabbit or Monster Bash than DKC, I absolutely hated the intro.

And holy shit that aliasing on the load screen.

File: Desolate hope.png (588KB, 1280x720px) Image search: [Google]

588KB, 1280x720px

>>2944024
FNaF is all pre-rendered, and pic related done by the same guy looks pretty good IMO

>>2944106
Nope.

As somebody said, the music is much better than the graphics. And the game is satisfying and fun to play. Jumping on enemies feels fun, the levels are fairly well designed, you can play through quickly and it doesn't dick you, the barrel bits are hella fun. The list goes on - it's not perfect, but it's a good game.

https://www.youtube.com/watch?v=w7WUBrxf09I

One of the few none ugly pre-rendered sprite games.

File: what.jpg (112KB, 1280x1024px) Image search: [Google]

112KB, 1280x1024px

https://www.youtube.com/watch?v=QkhDrngAQZ0
have ye seen this, lads? the prerendered graphics were a big part of the look n feel of abe's oddysee & exoddus

I think modern gamers in general have an aversion to old 3D graphics. They appreciate 2D graphics because their limitations are seen as stylish, while the blockiness and low res textures of early 3D are just dated and "aged poorly"
Personally I like pre-rendered sprites, they sort of feel like a digital claymation sometimes.

>>2949715
Think Dungeon Master or Myst series. Games that have static locations, but a lot of them. The transition from one view to the next can take a brief moment (not a second, not half a second, less than that). Alternatively, think something like RE, but you can deliberately avoid bad camera angles, or show progression of the environment throughout the game.
Basically, any game that nowadays relies on static backgrounds, but you get to do more of them, and partially editable. In the Myst example, you can use that technique to render a full cube map, and then provide a standard cubemap viewer for a 360 degree experience, just like later Myst games had 360 degree views for their locations.

>>2949715
>>2950774
To clarify, the suggestion of just-in-time rendering is as a substitute for prerendering. In other words, the gameplay mechanics are identical to those of games with prerendered visuals. You only get to do more of it, because the storage constraint of prerendered imagery is not there. It's not for a new genre, or new kind of gameplay. Just a mechanism to tackle some of the shortcomings of prerendering, while still taking advantage of its strong points.

>>2950117
that's very true. I personally love low poly visuals, maybe more so than blocky rasters, but it's definitely treated like a fault, not a style

>>2944032
>pre-rendered looks like ass.
>please do chime in with some actual argumentation on why do you think this is so
I'm amongst the few people that always though DKC looked fucking hideous. I don't think is a issue with the idea of pre-rendered graphics but a issue on how was it done at the time.
>Bad models (lack of textures
>Bad lighting.(shiny look, shadows are too dark)
>Sprites aren't cleaned properly.
>Sprites perspective don't match with background perspective
>Sudden change from fluid animation to static animation.
I believe if its done correctly It can look great, sadly, can't think of any example of it right now.

>>2944024
>Why does extremely minimal pixel art almost seem to validate a project creatively today by itself?
Its the new fad. Is easier and faster to make, and they can hide the fact they barely put effor in their graphics with a 'is original, risky, new and looks retro' facade, while appealing at the same time at the nostalgia of people who probably never really played anything older than SNES games games.

>>2949332
I just mean that when prerendered sprites were popular, Phong shading was the standard and as a result : plastic, which I find ugly.

Now with all those fancy BSSRDF models, fur/hair rendering and let's not forget how 3D animation technique became better, of course you could make awesome sprites.

>>2951424
>of course you could make awesome sprites.
Yeah, you could make it look good. I have to question why it would be pre-rendered when you could just have a 2.5D game, though.

>>2951438
I agree with you, as I think prerendering wouldn't have any advantagesu upon models. I just wanted to acknowledge that, yes,you can make good looking prerendered sprites nowaday. But why would you? People won't notice the difference between a render and a nicely shaded model.
Plus you have more freedom with your camera, coherent lighting, smooth animations and outfit customization. Even sprite games have switched to 3D with Guilty Gear Xrd for example.