/retro/ - Y2K

1990s and 2000s Nostalgia

SAVE THIS FILE: Anon.cafe Fallback File v1.1 (updated 2021-12-13)

Want your event posted here? Requests accepted in this /meta/ thread.

Max message length: 20000

Drag files to upload or
click here to select them

Maximum 5 files / Maximum size: 20.00 MB

Board Rules
More

(used to delete files and postings)


Wanna watch some /retro/ TV? Check out https://www.my00stv.com/


Modern /retro/ material that actually does it right Fellow Time Traveler 08/06/2020 (Thu) 18:36:27 No.768
Let's have a new thread without a tonne of broken images. Have there been any new forms of /retro/ media (could be movies, games, anime, websites, etc.) that wanted to look old and actually succeeded? There's an artist called BlueTheBone who makes "retro"-styled animations, cheesecake, and porn. Like any modern hack, he overdoses on visual clutter and uses filters that don't actually resemble the time period he's trying to emulate - but despite that, I think his style is consistently decent. If he relied less on computers and filters, then I think he'd be a much better artist, but that goes without saying for most contemporary artists. The really weird things happen when he tries to make modern character designs and media look old, like pic 2. It isn't exactly wrong, but there is something perplexing about viewing characters and series that were developed specifically with modern aesthetics in mind.
>>2148 Nice, all I remember from back then is Digital Blasphemy. It is neat to see some other similar images from around the same time.
Open file (55.72 KB 560x370 151z7mtrtd881.png)
Open file (84.00 KB 640x480 k72stx5cfq281.jpg)
Open file (78.10 KB 800x600 0o3bwwjp96781.jpg)
>>2154 I rally like this kind of image.
Open file (119.15 KB 672x413 1510459599165.jpg)
>>2156 Yeah, I just wished I posted them in the right thread.
Open file (1.14 MB 800x1620 ClipboardImage.png)
>>2124 A little update; I finally embraced the "spartan" design and my website looks so much better now, pic related. Initially I tried a Windows 95/98 style (which you've already seen) but it got boring really quickly, especially since the style is ubiquitous on other /retro/ websites. So I changed the colors and wrestled with the html/css for a while, but nothing was working... Until I threw in the towel and removed all the styling to start over from scratch, that's when I realized the website already looks good! The layout is uncluttered, the art pops out more, and the text is perfectly readable. The cherry on top is it all looks like a genuine 1990s website (see zlib.net for an example). A few tweaks later and I was done, now I can finally focus on writing for the website rather than writing the website itself... And speaking of, I'm currently working on a mini tutorial series for POV-Ray. I'll keep you guys updated.
>>2165 I do think the more basic does look better, and it definitely seems authentic.
>>2165 That's a nice functional design, the art is the focus point as it should be. Looking forward to the tutorials!
Check this one out. This track could fit right in to a Miami Vice episode. https://invidious.osi.kr/watch?v=ua0TXQ2_tjE
>>2167 >>2168 Thank you both. I have published part 0 of the tutorial series here: https://grecomoran.neocities.org/texts/2022-02-10-pov0/index.html Unfortunately I don't go into any 3D stuff in this article, only the basics of 2D for complete beginners. The 3D stuff along with the POV-Ray code will be in part 1, which I'm yet to write... Would love to hear what you think of part 0 though, especially if you're non-technical and not good at math/geometry.
>>2203 >Would love to hear what you think of part 0 though I'm already familiar with the subject but I think you've done well to cover the basics, anyone who did 2D coordinates in school will catch on quickly, though it might not be as accessible to complete beginners. The one thing I noticed is that you didn't render the chessboard and clock in Povray lol.
>>2205 >anyone who did 2D coordinates in school will catch on quickly, though it might not be as accessible to complete beginners. That's the thing though... The main demographic for that article are the complete beginners, I was trying to simplify the subject as much as possible so anyone can get into it. How can I simplify it further? >The one thing I noticed is that you didn't render the chessboard and clock in Povray lol. ¯\_(ツ)_/¯
>>2212 >How can I simplify it further? I think it's more to do with reinforcement and verbosity, i.e having redundancy in the text which reinforces and perhaps over explains the ideas you're talking about, I tried modifying the section on rectangles to illustrate what I mean: >A rectangle is made up of 4 different points connected to each other by straight lines, however each point is only connected to 2 other points. The 4 edges that make up the rectangle are divided into 2 horizontal edges and 2 vertical edges. > >We denote a rectangle by 4 pairs of coordinates in an order that creates a "closed" shape, for example (0, 2) , (0, 4) , (4, 4) , (4, 2), which gives us our bottom left, top left, top right and bottom right points respectively. > >An alternative notation for a rectangle is only 2 pairs of coordinates, such that these coordinates correspond to 2 points that are opposite to each other, for example (0, 4) , (4, 2) defines our upper left and bottom right points, so that we don't have to specify all 4 points. Notice how the x coordinate is different across the two pairs, and so is the y coordinate? We will be using this alternative notation from now on. It's not that big of a thing and I'm most likely overthinking it, chances are that anyone who wants to make retro-style renders and isn't just using Blender for that purpose probably has the right mindset anyway. Keep up the good work.
>>2214 >I think it's more to do with reinforcement and verbosity Yeah I see what you mean, and the example you provided is perfect. I'll try to be more verbose in the next article. >I'm most likely overthinking it Not at all! You're providing the exact type of feedback that I need, and you bet I'll looking forward to your feedback on the coming article too.
>>2203 I haven't finished reading it completely, but it seems pretty straightforward to me. That's saying something because I'm horrible with just about anything involving numbers.
Check out Especia: https://www.youtube.com/watch?v=HQz4GIOB8gg Sadly they're now disbanded, but they did release some MV VHS/DVDs! I downloaded it from Jpopsuki
Open file (73.74 KB 1686x992 FLbKUhuX0AUq5sP.jfif)
Open file (418.98 KB 1342x1016 FKJAn5WWUAQEDdy.jfif)
Open file (68.64 KB 989x627 FJ-_q4vWYAEYBGZ.jfif)
Open file (187.75 KB 2096x768 FDYjY-iWYAMvzfZ.jfif)
Open file (221.88 KB 2732x768 FCAsJGpXEAkSduy.jfif)
YinyangGio on Twitter is someone who actually uses video programs to impact his art to look much more aesthetics. As well as imitating the imperfections really well, especially with 3D models. I actually tricked some people on discord into thinking his art was a screenshot from a show
>>2264 >YinyangGio Impressive... Are all these pressed to real tape or did he just use a filter? If it's a filter I would really really love to get my hands on it.
Open file (17.39 KB 640x480 bplate2.png)
After a few months I finally uploaded part 1 of the POV-Ray series, with actual 3D content this time! https://grecomoran.neocities.org/texts/2022-06-04-pov1/index.html >>2214 >>2220 I reworked part 0 somewhat since I last posted, it should be more elaborate now.
>>2386 Looking good anon! The only notes I have is that you might want to host your build (is there a reason it's an older version?) on archive.org and potentially use Wayback copies of any legacy external pages to avoid potential link rot in the future. >I reworked part 0 somewhat since I last posted, it should be more elaborate now. Yep, that's definitely improved. I'm glad the feedback was useful.
Open file (101.63 KB 640x480 part1demo.png)
>>2386 Just for fun, a demo render using the concepts introduced in part 1. Source: https://files.catbox.moe/akezbw.pov
>>2388 That's great to hear and thank you for the feedback! >host your build on archive.org and potentially use Wayback copies of any legacy external pages Good call, I'll start archiving my links. Although I'm reluctant to use archive.org as my primary host, because it gets slow often and sometimes has connection issues. >is there a reason it's an older version? Yes. It's because POV-Ray 2.x is a good version for beginners; it's not too bare-bones but not too full of features that it's overwhelming. With POV-Ray 3.x scene writing became full-on scripting, with the introduction of conditional statements, loops...etc which are useful no doubt but again not to a beginner (or anyone making retro CGI exclusively). There's also another (technical) reason; version 2.x is small and self-contained, so it compiles cleanly on modern systems. Starting with 3.0 there are dependencies on old libraries so compilation is a hassle, and the current 3.x releases are too big and too bloated so also a hassle to compile. >>2391 That's so cool! A Rubik's cube house made using only basic shapes, pretty creative anon. I'm overjoyed to see the tutorial being put to good use. :-) This gives me an idea... I should probably dedicate a later tutorial to building a complete scene from scratch. Nothing too fancy, just something anons can show for completing the tutorial series.
>>2392 That makes sense, I better grab 2.x to ensure scene compatibility if we're sharing pov files. >I should probably dedicate a later tutorial to building a complete scene Sounds good, reinforcing what the reader has learned is an important part of a good tutorial.
Open file (14.60 MB 1292x14368 benchmark.png)
I was curious about POVRay 2 vs 3 so I did some tests. Versions 2.2 and 3.7 were put up against the LEVEL2 scene set (found in https://www.povray.org/ftp/pub/povray/Old-Versions/Official-2.2/POVSCN.ZIP) using the following arguments: [code]povray2 +L<povray2include> +I<scene.pov> +O<scene.tga> +FT +W640 +H480 +A0.1 +V[/code] POVRay 3 was given the +MV parameter to engage backwards compatibility mode (2.2 in this case): [code]povray3 +I<scene.pov> +O<scene.tga> +FT +W640 +H480 +A0.1 +MV2.2 +V[/code] The resulting images and render times (from start of program execution to completion) were recorded and can be seen in picrel (warning: fuck hueg). What we can see is that POVRay 3's backwards compatibility is mixed, while it generally does well there's obvious and less obvious differences from the 2.2 render. In fact some images fail to render at all mainly as a result of syntax errors (though it is likely possible to fix those errors without much issue). The reason for these discrepancies appears to be a combination of tweaks over time to the default texture set as well as larger changes in the underlying render engine. More concerning is that POVRay 2 failed to produce the 'pawns' scene successfully, at least in my case segfaulting after partially rendering the image (though POVRay 3 didn't do the scene justice either). Perhaps code rot is finally catching up to the nearly 30 year old codebase? On a more positive note we can see where POVRay 3 benefits in this benchmark: the render times. In most cases (with some exceptions where 2.2 is faster, presumably due to 20 extra years of development resulting in a bit of overhead), 3.7 manages to shave fractions of a second to several seconds off of the render time, altogether resulting in almost half a minute of time saved vs 2.2. The biggest reason for this is simple: 3.7 is multi-threaded whereas 2.2 is stuck with a single core (not surprising for a program of its vintage). This is something that you'll definitely notice while iterating on a scene. In conclusion it's impressive that POVRay 3 can render projects from decades prior, even if those results are flawed. Even more impressive is that POVRay 2 works at all on modern systems, though if the raytracing community wants to preserve these legacy scenes as they were meant to be seen then 2.2's code may need some TLC.
Open file (451.59 KB 640x480 ClipboardImage.png)
>>2395 Interesting tests and results, I always knew 3.x was backwards-compatible so I'm a little disappointed to see that's not entirely true. But I'm surprised that `pawns.pov` didn't render for you, it rendered fine for me just now... Can you tell me your specs? What OS are you running? Did you compile v2.2 yourself or did you use the binaries linked in the tutorial?...etc. >Even more impressive is that POVRay 2 works at all on modern systems POV-Ray was written to be portable from day one, with strict standard compliance in the code and rigorous testing on multiple systems. And that was back in the 90's when there were a gazillion different machines and operating systems! It's only natural that it works everywhere, and I'm so glad that it does. >2.2's code may need some TLC I recall seeing only a handful of warnings when compiling it so I don't know how much it can be improved, if at all. That being said it might be fun taking a look at the code.
>>2396 >Can you tell me your specs? Debian 11 x64 on a Sandy Bridge i3. Compiled from source using the machine files from the UNIX folder. After some tests the issue appears to be with +A0.1, higher values or lower resolutions render successfully (strangely the way that textures are mapped on my build is visually different for some reason). Perhaps compiler differences are the cause? What about you? Were there any particular steps you used to build (your build did work - producing identical output so there's definitely some variable in the compilation process)?
>>2397 Nice to see other anons using linux. Hope you don't mind me getting a little technical then! >Compiled from source using the machine files from the UNIX folder This is what I did, with 2 minor changes: 1. POV-Ray depends on random numbers to create patterns/textures, and by default uses the system's random number generator function. Naturally, this causes the output to be different on each system, so to remedy this problem I forced POV-Ray to always use its own "fallback" random function instead of the system one. 2. The binaries that I compiled are statically linked instead of dynamically linked, with the musl standard library instead of glibc. I'm not sure if this matters at all but I'm mentioning it regardless. >After some tests the issue appears to be with +A0.1, higher values or lower resolutions render successfully Strange... This usually happens on low memory systems (think less than a MB of RAM) which is definitely not the case here. >the way that textures are mapped on my build is visually different That's because the binary you compiled is using your system's random function, instead of POV-Ray's internal one. It's very easy to change that though, scroll down the manual to Appendix A at the bottom: https://pastebin.com/raw/vHhn3Nm2
Open file (14.97 MB 1292x14368 benchmarkv2.png)
>>2399 Thanks anon, it was that meddling RNG all along. Kind of surprising that they used the system RNG when determinism is so beneficial for a program like this. >>2395 So, with a fully working build of POVRay 2 we can now complete the benchmark. With the addition of the pawns scene we can see that 2.2 is over a minute behind 3.7 in total render time, I think POVRay 3 definitely has a place for scene prototyping where the visual differences aren't too stark. In fact, given that textures are randomized, that may account for quite a few of the texture discrepancies we see (though there's still plenty of other issues of course).
Jason Scott, known for textfiles.com and his work at the Internet Archive, recalls what it was like to raytrace back in the day (including POVRay): https://www.youtube.com/watch?v=BWGJPH1qbXs
Open file (298.75 KB 1280x960 wakka.png)
I've got a (Pacman) fever, and the only prescription, is more POVRay! Source: https://files.catbox.moe/tusbn7.zip
Open file (9.81 KB 640x480 ClipboardImage.png)
>>2400 >determinism is so beneficial for a program like this Agreed. I think the 3.x series uses the internal RNG already, at least judging from a few tests I made. >I think POVRay 3 definitely has a place for scene prototyping POV-Ray 3.x has certain "quirks" that come to light when rednering 2.x scenes, so I just use POV-Ray 2.2 but with low render settings, this makes rendering quite fast and does the job very well throughout the initial scene design phase... I plan to cover render settings in a future article along with other "good practices" for saving time, but all in good time. >>2401 Great insight, and pretty much what I expected to hear. 1980s-1990s consumer PCs were extremely slow, it's a wonder any raytracing was done on them at all. One popular trick to save time was drawing the entire scene by hand on graph paper first, engineering style, then typing all the coordinates into a POV file in one go. It wasn't perfect of course, but it was a good enough hack for the time... I like to do that even today when creating my scenes, but I use "virtual" graph paper on GIMP, haha. >>2404 Beautiful. You're on a roll lately! I see you used boxes to model individual pixels, a better way to go about this is by using a height field. In brief, if you already have a pixel-perfect screenshot of the game screen you intend to model, make it black and white (black=empty & white=object) and enlarge it by x10 without interpolation, then use it as a height map. To add color, apply value propagation to the original screenshot in GIMP or similar, then use the screenshot as a texture. This may be a bit advanced so don't stress over it too much for now, I'll probably cover all this in depth later on. You did good with your scene anon.
>>2406 >I plan to cover render settings in a future article along with other "good practices" for saving time A good part to include for sure, there's no doubt countless useful tricks and tweaks. >One popular trick to save time was drawing the entire scene by hand on graph paper first Interesting, that reminds me of how game sprites were designed way back before general purpose art software. Visualization is such a key skill for this kind of thing. >I use "virtual" graph paper on GIMP, haha You're living the raytracing life! >Beautiful. You're on a roll lately! Thanks! POVRay is good fun. >a better way to go about this is by using a height field That's a great tip anon, would've saved me writing this: https://files.catbox.moe/u9m0i5.zip
>>2404 That reminds me of a video I watched last year. The channel is mildly cancerous but they usually have insightful things to say about VFX. Their goal to recreate old school Tron effects using semi-old 3D technology is genuinely pretty impressive. https://yewtu.be/watch?v=T2-yhFTCCzY The VFX for Tron were apparently done mostly using math and spreadsheets to plan out where objects would go and how they would appear on the screen.
>>2401 A prelude to that podcast written many years prior: https://web.archive.org/web/20121025031942/http://ascii.textfiles.com/archives/1240 Not much new but some nice links inside.
Open file (53.15 KB 703x234 ClipboardImage.png)
>>2422 It's actually him wow
Open file (183.13 KB 640x480 mona.png)
So that's where Vigo is hiding. Source: https://files.catbox.moe/pjmie0.zip
>>2431 At first glance I thought this was a screenshot from a 90's game, great job anon... So happy to see anons bringing back the spirit of old CGI. What's with the bumpiness on the Mona Lisa though? It looks a bit like pixel art.
>>2433 Thanks, I'm glad you like it! >What's with the bumpiness on the Mona Lisa though? Do you mean the mottled paint or the square tiles? For the latter I thought it would be interesting if it looked as though the different parts of the painting were shifting in and out (kind of like the main menu in Chronicles of Riddick I guess).
>>2431 Very nice.
>>2408 >https://files.catbox.moe/u9m0i5.zip What's this code for? I ran it on a random PNG and it just generates a 20MB POV script that renders nothing.
>>2484 I think it takes a pixel art image and turns each pixel into a cube in POV-Ray. Try it on a small image first to see if it works, and adjust the camera/lights as they may not be properly positioned.
>>2484 >>2487 The script creates an object that needs to be referenced by your scene to appear (so 'object {<name>}'), as the help suggests it can also attempt some optimizations to make the file smaller and easier to read. It's not really needed though (except perhaps if you want to quickly generate lots of walls or something), height fields are much better for pixel/blocky effects (see the Mona source for an example).
Does anyone know if it's possible to create 16 point Bicubic patches in Blender? The POVRay addon doesn't expose them and the closest option I could find (rectangle curve) is missing the middle 4 points. Alternatively are there any maintained FOSS patch modellers? Manual calculation is possible of course but beyond a certain level of complexity that becomes less feasible.
>>2669 I'm in the same boat as you, I've hit a roadblock with POV-Ray because I couldn't find any proper patch modelling tools. The only programs I know of are historic ones like Hamapatch and sPatch, which I couldn't get into. How difficult would it be to program a simple patch modeler?
>>2673 >historic ones like Hamapatch and sPatch Yeah I've seen those mentioned (apparently they work with WINE too). I looked into Wings 3D but it doesn't seem to have any kind of curve functionality (there's a WIP plugin on the forum which has something to do with curves but I don't know if that includes patches). >How difficult would it be to program a simple patch modeler? That's definitely beyond me (though the rendering is the hard part probably). I wonder how difficult updating some of the existing old tools would be? I guess it depends on how many legacy dependencies they have. Looking at https://www.povray.org/resources/links/3D_Programs/POV-Ray_Modelling_Programs & https://wiki.povray.org/content/Knowledgebase:POV-Ray_Modelling_Programs there's a number of open source (and Linux) programs, surely at least one of them supports Bicubic patches?
>>2674 I went through the lists you linked and found 2 free modellers that support bicubic patches, unfortunately both are ancient and I couldn't compile them... > Model Scene Editor > https://mse.sourceforge.net/ A modeler written in Pascal for an old Windows IDE called Delphi, it was ported to Linux but pulled due to bugs. > Truevision > https://truevision.sourceforge.net/ Another modeler written in C++, depends on ancient GNOME-related libraries that are no longer available. Tried compiling one of them from source and gave up, maybe someone else will have better luck.
Open file (40.15 KB 1001x617 bicubic.png)
>>2676 I did more digging and discovered some interesting things. For some reason this slightly different link https://www.povray.org/resources/links/3D_Programs/POV-Ray_Modelling_Programs/ shows a list with some extra software. Now sometimes it's worth searching Github for older programs and incredibly, KPovModeler has a QT5 port with a commit as recent as 2021! After cloning https://github.com/eticre/povmodeler and sorting out dependencies (the only additional thing I needed was libqt5x11extras5-dev) it compiled! The program seems pretty well featured and although it's for POVRay 3, it shouldn't be difficult to do any necessary syntax changes for version 2. I may poke around at some of the other tools to see if their code can be updated with modern libraries, just for the sake of choice. Either way though this is exciting, the possibilities povmodeler opens up are enormous!
Open file (123.72 KB 320x240 ants.png)
Open file (24.32 KB 320x240 bee.png)
Open file (104.74 KB 320x240 ink.png)
Open file (458.98 KB 640x480 table.png)
>>2677 Thank you so much for finding this! The program looks easy to use and even has sample scenes. Can't wait to play around with it.
Found some POVRay related things of interest: 1. Another podcast, this time from 2008 during the 3.7 beta period, featuring David Buck as a special guest: https://twit.tv/shows/floss-weekly/episodes/24 2. Mentioned in that podcast is the first render in space, performed by Mark Shuttleworth of Ubuntu fame, more details here: https://www.povray.org/posters/ 3. Also mentioned is Povray's acquisition of the commercial Moray modeller, which has sat on the back-burner ever since due to a lack of developers. However, the Moray site at http://www.stmuc.com/ is apparently under construction, earlier this year the old homepage was still available so something might be afoot: https://web.archive.org/web/20220517133442/http://www.stmuc.com/ 4. Furthering this suspicion is a fairly active thread on the newsgroup with talk of a potential source release for Moray: https://news.povray.org/moray.win/thread/%3Cweb.6295c4ddaeb80d548af0bb1fd061826%40news.povray.org%3E/ On the subject of modelling software, povmodeler is a very useful tool for prototyping ideas, though it lacks the ability to stitch bicubic patches together. Fortunately the POVRay 3 docs feature a handy bicubic patch guide that's applicable to POVRay 2. If Moray does see a modern release it will be interesting to compare the feature sets.
>>2701 Damn how do you find this cool stuff? Good effort anon. >though it lacks the ability to stitch bicubic patches together That's an issue for me as well. One workaround is noting the numerical values for a specific patch and manually inputting them into another patch, it's not optimal but better than nothing. I'm having another issue though; wireframe view. I often get confused looking at models because both front-facing and back-facing polygons are drawn, which doesn't provide any visual clues as to which "way" I'm looking. There should be at the very least a "flat" view that fills in the polygons. >Fortunately the POVRay 3 docs feature a handy bicubic patch guide that's applicable to POVRay 2 Care to link the guide?
>>2704 >There should be at the very least a "flat" view that fills in the polygons Yeah that would be handy, something Moray does of course. Another thing that would be cool (probably pretty easy to add actually) is a freecam like in GtkRadiant, Trenchbroom, etc. which Moray also has. >Care to link the guide? Sure thing: https://www.povray.org/documentation/3.7.0/t2_3.html#t2_3_1_5 Should create smooth transitions though depending on the design sometimes you won't get the desired shape.

Report/Delete/Moderation Forms
Delete
Report

no cookies?