u/deftware

Put the house in a trust before you die, in your kids' name. Then the bloaty medical industry can kick rocks.

Nice! I was really baffled that telelocation wasnt a huge selling point with the modern headsets that's built right into the homescreen: see what your friends are doing in VR. If you could put portals up around your play area that show you the scanned area around your friends' play areas, with their VR avatar rendered in there. It used to be that you would launch ICQ back in the 90s and see who was online, to message them. That's how it should be with VR, except telelocation. Obviously people could put an away/private mode on so friends can't portal into their home or whatever.

It's like they know how to build the hardware, but don't know what to make the hardware do. The people they hire nowadays lack creative vision.

You should be able to get splats going pretty smooth on headset hardware, provided it's baked down enough. There was a geometry/scene preprocessing thing that I believe Google made, named after an artist. It bakes stuff way down based on actual visibility - remeshing it to have consistent geometric/texture density in your FOV based on vantage. What the heck was that called... oh yeah, Seurat: https://github.com/googlevr/seurat It's kinda dated, IMO, maybe, maybe not, hard to say. Yeah it's like a decade old. I think Gaussian splats could be faster/better so long as they're sorted front-to-back and super cheap to individually render, then you just throw the cloud at the GPU with them mostly sorted, perhaps 3D chunks that you can quickly sort, and let the GPU handle them. I don't know how good perf is on mobile headsets for Gaussian splat rendering.

Anyway, enough out of me. I have work to do! Good luck :D

This is what I wanted to have in VR so that you could see your friend's avatar in their play space from your play space - have portals all around your play space that open up into theirs, so you can teleport into theirs or at least merge your play spaces and play games with eachother over the internet that are built into the thing.

If you build it they will come.

I have been messing with a little traffic simulation as a part of a larger project and discovered MOBIL https://mtreiber.de/MicroApplet/MOBIL.html

check the edge points of the bbox first

Nice. It sounds like the most expensive part then is when a bbox doesn't early-out and you're checking it against all of the pixels. The larger the bbox the more depth pixels it checks against. At that point I would suggest taking another look at getting min/max miptree building cooking, you could build both of them simultaneously - walk the depth buffer once to build both.

I forgot to show this to you https://hacksoflife.blogspot.com/2016/05/simultaneous-mipmap-level-generation.html

Once you have your min depth miptree then each bbox is just a check against one mip pixel.

Anyway, just my two cents. Have you done any profiling yet to see where the slowest parts of your renderer are?

Colds and the flu and other things are more abundant in colder seasons.

Basically a bitmap?

Nice. Are you using a z-max (or z-min, or both!) miptree for quickly comparing bounding boxes against the depth buffer? I did see a fun article about single-pass miptree building, where you're basically iterating over all LOD levels of the miptree simultaneously, by walking the image's pixels once and figuring what they contribute to each miplevel's pixels. So at LOD1 each pixel is contributing 25%, at LOD2 it's contributing 1/16th, etc... The trick to avoid precision issues was to sum everything up first, and then divide by number of contributors at the end. Granted, building a miptree is most expensive for the first few levels, and then the rest of the levels are really cheap, but it was a fun idea that I once used when building a high-precision scalar field codec, where it had to be fast. The trade-off is a bit of extra memory being used. :P

Cheers! :]

Yeah, basically if you are drawing a bunch of stuff and having the GPU change state to do all kinds of things then a thinner API like Vulkan is what you want, so you are in control of what memory different data sits in and when/how everything happens on the GPU. With OpenGL it abstracts all of that away from you, resulting a simpler and easier to use API but also one that doesn't afford the fine grained control that a complex renderer would benefit from.

In OP's case, they're just using whatever graphics API was handiest for them to take their CPU-generated buffer of pixel RGB values and putting it up in a window or fullscreen, which can be a vkCmdBlitImage(), probably after some pipeline barriers to change image layouts. With OpenGL you would use a PBO to async transfer the pixels to a texture image that's attached to a framebuffer object and then blit the framebuffer object to the main framebuffer that the window has. Or you can upload the pixel data to a texture image and then draw the texture image to the main framebuffer. It's arguable which is faster. The key is making it asynchronous, so a ring buffer of pixel buffers that you output to, and submit each one to OpenGL, leaving it alone for a few frames so that OpenGL has a chance to actually grab the data while you're already rendering the next frame on the CPU to the next buffer in the ring.

Alternatively, OS-specific APIs might be fast too, like win32 GDI on Windows.

Super impressive.

OpenGL is less boilerplate, for one - and since all that OP is doing is taking a buffer of pixels and putting it onscreen, it almost makes no difference what API you use. Pixel Buffer Objects allow for asynchronous transfer so it's going to be pretty quick, minimal API calls on the whole. I would be very surprised if there was any performance difference between DX12/VK/GL.

Well done. Are you doing any kind of spatial partitioning, sorting, visibility determination, occlusion culling, etc?

Nice! How fast is the actual rendering part, before sending the frame to OpenGL to be put onscreen?

I've felt the same way about SGs for a long time. IMO SGs are better than SHs because they better capture the irradiance than SHs can, without the kind of artifacting that SHs can result in. SHs require more coeffs to capture finer detail. It also depends on how well you tune your SGs to fit to the actual sampled light.

Yeah, that page you linked from 10 years ago is what sold me on SGs back when it was going around the web.

I'm working on a project right now that directly generates sky irradiance, not necessarily as gaussians, but it was inspired by SGs.

EDIT: Also, a lot of games that want realistic lighting have moved to other GI methods, raytracing/pathtracing, etc. SGs kinda came in at the tail end of their era and didn't have a chance to gain traction and become more popular.

Hah, the P-384 curve is my 11th bday! :D

The gameplay and mechanics remind me a bit of aerogauge on the Nintendo 64. The aesthetic is pretty slick, it's like future-retro synthwave.

I'd go for a more low-poly aesthetic though, with bent normals so that instead of perfectly flat triangles and faces you have their shading/reflectivity slightly convex looking - that's been my jam the last few years.

I'd like to see some high-rez screenshots of the analytic specular lighting on there, reddit video compression is flubbing it up a bit for me.

It looks awesome! Keep refining the visuals. Throw some neon lines on stuff :D

Oh man, I can't believe you're still around - I thought for sure you must've kicked the bucket or something, no sign of you anywhere for nearly 20 years! What the heck have you been up to? We might could move this conversation elsewhere. I'm on the google chat. I just sent you a message on the reddit chat thing (I never use it but it will suffice).

There's a few artists out there who make all kinds of fractallesque sculptures out of dichroic glass. They splice together pieces and then cut them orthogonally and recombine them, so that the patterns just keep getting more and more intricate. This is one of them https://jackstorms.com/

You live!!! Charlie/Chazz :]

Chiners have been stealing games for a long while, posting them on chiner distribution platforms.

Oh how the turntables.

I don't think moving to browser/cloud will help anything. The machine learning is going to be able to replicate everything eventually. The only thing it won't be able to replicate is true originality in engineering, that there are no tutorials for or prior art about.

What people pay for isn't just a product these days either, they are paying to support creators themselves, as human beings honing their craft to be able to share it with others, and share their experience developing the thing with others.

I figure this whole ripping thing is transient anyway - eventually AI will be looking for rips and low effort copies of things someone else made. People already hate AI stuff enough as it is, they're definitely not going to favor the AI-ripped version of something.

It's like Heisenberg's little Say My Name speech about Coca Cola. Do you really want to live in a world without classic Coke? Same thing! Nobody wants the garbage aping the genuine article, especially if someone had an automatic generator steal it from the genuine article. They want the genuine article, that someone cool made and shared. Not the faceless nameless lazy wannabe.

Do the rippers steal others' thunder? Sure, all the time, but not every time - and the more you put yourself out there, and have something legit that someone can't just one-shot and post before you. The key is selling yourself, not just what you make.

That's fun! :D

As long as the new phone supports VoLTE, which is what Tracfone switched over to when they jumped from ATT's network to Verizon's network. You just need to hop on the tracfone.com chat or make a phone call to them and get them to turn the phone on. You'll have to be able to find and give them the phone's IMEI or SIM numbers that are in the phone (no more physical SIM card).

EDIT: I don't know about the phone being carrier-locked. It very well may be. You'll have to find out!

Two years ago I started tinkering with hydraulic erosion for the first legitimate time, with the goal of generating a large area of land along with bodies of water - the streams and rivers and lakes, but it seemed like no matter what I tuned things to I would always just end up with something that looked like water moving sand around. All the lower areas would flatten out, and the higher areas would erode to look like, well, wind-eroded rocks. I guess what was happening was "effluvial" erosion.

What I wanted to produce were huge mountain canyons like you'd find along the Sierra Nevada mountain range, where it was like wide flows of water cut progressively narrower, faster, and sharper streams and rivers into the granite - leaving behind deep canyons with steep hillsides.

I landed on some kind of macro drainage algorithm that does the actual large-scale canyon formation, and then relying on the hydraulic erosion for small-scale features to be added to the thing. That ended up being sufficient. The only problem was that using it for anything interactive meant users would have to sit through tens of thousands of erosion iterations, which even on a mid-tier GPU could take dozens of seconds, after a bunch of optimization work had been done on the compute shaders and data structures.

I think there's still room there for both improving the output, as well as speeding it up a bit more, but yeah - it probably would've been easier to just train a neural network on a bunch of real terrain and have the thing generate terrain and bodies of water directly, with some kind of diffusion network, or something like texture synthesis (which is related to model synthesis, and also wave function collapse).

Anyway, props on the work!

My life.

Now we're talking. This is what I think of when I think of 3D graphics in the 90s. Back then I was making random stuff in a DOS 3d modeling/animating program called TOPAS, and another Windows based on called Truespace (made by a company called Caligari).

I made many-a-3d-model-and-animation in Truespace back in the day. Its output looked exactly like the vaporwave aesthetic.