yo /g/working on a basic 3d raytracer right now, trying to nail that bryce 3d look (which seemingly no games have done in real time despite the method existing since LITERALLY 1980 (whitted raytracing, I even read the paper on that shit) and instead try to emulate really intense methods like pathtracing with ugly fake compromises). I just assumed this wasn't possible for the longest time until I saw this https://youtu.be/2jee4tlakqo which was on a FACKING snes so I knew it could be pulled off on a real computer. I've been working on this with my mate for the last week and we've got this in vulkan so far. was very suprised it runs at such a high framerate which just proves how dogshit these game developers are. In the corner you can see the FPS and frame time but also:S:256 (number of spheres)B:32 (number of light bounces for reflections, set to 32 just to push it but you wouldn't see any issues at 16 or higher, lower you can see some black reflections)
Now add multiple light sources. 32 to start, 128 for stress test.
>>108818653Just vibecode it bro. Don’t be a fucking snailcat
>>108818690forced bullshit
the DREAM is to see if a look like this or something in myst is at all possible in real time, I think its mostly down to art direction once you get the basic rendering down. luckily I have some friends who actually know that shit>>108818687the lightsource is dynamic right now but I gotta test this next>>108818690desu a lot of the vulkan was aided by claude cause I don't know that shit.
>>108818653ts tuff twinglad you used a cutting-edge industry standard API rather than trying to do something STUPID like write a CPU raytracer
>>108818653>despite the method existing sincemath and physics has been available since LITERALLY 1980???
>>108818817Lots of rendering techniques only existed on paper before computers were powerful enough to actually put them in practice.
Cool project nigger wish you good luck
>>108818746SOVLOVL
>>108818817Yes, math was invented by G. Will Hunting in 1980. 'G' stands for GNU
>>108818653vulkan is indisputably based. i intend on getting into rt once i build my new pc + work on rewriting my gpu emulator in vulkan to add rt support
>>108818653No shit rendering a plane and a bunch of spheres is fast.Now do more complex triangle meshes. Have you already built an acceleration structure (BVH)? That's where it gets really fun.
>>108818817You're absolutely correct. In fact, Euclid explained light propagation and reflection all the way back in 300 BC. I'm actually suprised they even had computers back then.
here's it in video form showing it at different light bounce levels. hoping to apply it to some real models and in a more complex scene which we'll do tomorrow as >>108819223 mentioned (to answer your question yes using VK_KHR_acceleration_structure but I dunno the specifics my friend did most of the work), hopefully there's still some juice to squeeze in terms of performance if we hit a major wall but so far it seems stupid fast considering this is running on a laptop running outdated nvidia drivers (4060 tbf). we initially posted this for shits and gigs but I'd be happy some more stuff on this in >>>/g/gedg if people are interested. this is part of a larger experiment we're trying with really portable single-header game engine, basically the antithesis to UE5 lol>>108818774yessir would be STUPID and we would NEVER do something like that ;)>>108818949good luck that, sounds awesome
>>108818690do you also assume projects posted here weren't all vibecoded? gramp, it's 2026.
>>108818653looks cool, which ai model did you use for it?
>>108818653The problem with raytracing isn't that you can or can't do it on a NES at low resolution. It's that the complexity is exponential on render target size.
>>108818746reds and purples are OP indeed
>>108818653That demo doesn't do any actual raytracing on the SNES itself. It's all done on a coprocessor using modern hardware.
>>108818653that demo doesn't run on the snes directly. it runs on a recent fpga + arm processor. the snes processor simply sends the rendered data to the screen.in the video it's said that the limiting factor is the bandwidth, and not computing power because the demo runs on very beefy components (compared to the snes cpu)
>>108819223what a retarded take. sure if you try to render billions of triangles, raytracing isn't feasible. but you can look at iquilez demos to see that you can make a lot of complex geometry without any triangle.picrel is just 1 thousand lines of webgl, without using any mesh, just pre-rendered noise/perlin textures
>>108820865based inigo enjoyer
>>108820865Those things are an artform: carefully selected mathematical functions that describe the geometry and if I'm not mistaken these are rendered with ray marching, not ray tracing (ray marching allows you to nicely "blend" geometric shapes together). Authoring such scenes is much more involved than arbitrary meshes that are easily created with 3D software. Typically people write ray tracers to be a renderer for "arbitrary" scenes, and those are most commonly made from triangle meshes.The point of my remark was that plane and sphere intersection tests are computationally cheap compared to triangles, and rendering a few hundred spheres is trivial on modern hardware. It gets interesting when you start pushing the limits of naïve approaches rendering more complex scenes and are forced to start optimizing to keep it performant. And then when you personally experience the dramatic difference in performance when you're trying to render some moderately sized triangle mesh the simple way vs with proper acceleration structures you can get some amazingly satisfying neuron activation.
>108819551We've mostly just used free models on opencode but for implementing this in particular, my mate used the free version of claude as its meant to be the best for this. Even then we spent about a week before that researching whitted ray tracing so we had enough information and even a small document to give to the AI in advance>>108820330>>108820845you both raise a good point, I really don't know that much about the specifics regarding FPGA hardware but the DE10-Nano he uses in the video isn't that powerful (its nearly a decade old now so it isn't exactly recent either) and he explicitly states he doesn't make use of the ARM chip built in, he also mentions in the video using the board ONLY as an expansion and not a replacement for the SNES hardware itself in the same vein as the original Super FX chip (I couldn't find an exact number for the chip but the 3x50Mhz certainly isn't outperforming a decent CPU and graphics card and if you follow the MiSTer community, accurately recreating 5th generation consoles like the N64 took a lot of effort and pushes the board to its limits, also worth noting since that video came out, you can now get the same hardware in a MiSTer Pi which only costs about $100 for just the board when in stock at least). You are right the bandwidth is limiting factor in that demo but my point is with even a decent rig you can at the very least make basic surreal environments with real time ray tracing like you see in a lot of 3D renders made over 30 years ago now and create a game like LSD Dream Emulator, ideally we want to do something beyond this however
>>108821401I agree, but extremely complex scenes can be created with very simple SDF (in the case of ray marching), ray marched fractals are a good example of that.Early 3D demos showcased how raymarching could be used to render terrain based on coherent noise, something that was unfeasible using triangles.ray tracing is a different technique, but you can apply the same rules (shapes constructed by union/intersections of primitives) to get complex geometry for cheap.
>>108820845>the limiting factor is the bandwidthMostly true of the SuperFX back in the day too. The SFX chips are faster than the games we got demonstrate. Too much time is spent transferring data to VRAM and games that could have had higher resolution rendering had to use small window sizes to keep the data rate up. Overclocking your SFX2 chip (real or emulated) is sadly only fixing half the problem. You spend less real time rendering the screen but you're stuck behind the slow bus for the VRAM copy just the same.
>>108821401You're bang on with everything you said, but just wanted to add that when RARE did DKC they were using b-splines, quad patches, shape morphs, etc. That's part of why that era of Rare games have a look that just can't be matched in any of your "render64" and modern RTX recreations because all those curves have infinite detail. So it's not like it hasn't been done in the past on shipping products, it's just something of a lost art.
>>108822886There was also that 'game' that became a creative tool kinda thing called Dream for ps2 I think, it also used SDFs for everything as I recall.
>>108818690you will never be a meme
>>108819223other dev from this little project here. Yeah we're using BLAS to store each sphere mesh's BVHs. The program doesn't use the full VK_KHR_ray_tracing pipeline yet because it's even more boilerplate, but that would allow for absolute maximum performance if I understand correctly. I will admit to not having a full understanding of raytracing as just kind of dived into coding this for a bit of fun, but looking at potentially making a CPU raytracer from scratch to get a better understanding before resuming the hardware accelerated version
