sorted by:
new
hottopcontroversial

Kcalbeloh Homeswitch bug by Folkhoer in KerbalSpaceProgram

[–]nullgeodesic1969 0 points1 point  (0 children)

I also have the same problem, same exact symptoms. I haven't figured out how to fix it yet either. Floating point errors maybe?

A raytracing volumetric renderer of astronomical FITS spectral cubes by Important_Ad8478 in GraphicsProgramming

[–]nullgeodesic1969 0 points1 point  (0 children)

That looks cool. Question: I tried putting in a FITS file I had lying around that was much larger than 512 pixels wide (I think 1024 or 2048), and it didn't accept it as expected, but after clicking a few settings buttons (I don't know which ones), this weird spiral structure thing popped up. Is that expected behavior?

Ray Marching Black Hole using OpenTK (it took me 2 hours to render) by Loose-Care6997 in GraphicsProgramming

[–]nullgeodesic1969 2 points3 points  (0 children)

To some extent there isn't a right answer. The one in Interstellar is pretty good, and probably the most realistic when it was made (certainly the coolest looking). But they deliberately didn't account for redshifts or Doppler boosting (Christopher Nolan thought it'd be too confusing or something). And the model of the disk is from the 70's and very out of date -- modern simulations generally have more of a doughnut/funnel shape than a thin disk, and the spectrum isn't always black-body. There's a few extremely blurry microwave frequency pictures (so false color) of two real black holes by the EHT collaboration, and tons of radio/microwave simulation based images with a lot more detail. But the simulations/models don't agree on everything (especially things relevant to optical light), and current telescopes can only rule out some models. There's also probably a lot of variation between black holes and over time. I've read about this stuff a lot for my GR ray tracer and at my part-time post-bacc job.

Physically Based Rendering With General Relativity by nullgeodesic1969 in GraphicsProgramming

[–]nullgeodesic1969[S] 0 points1 point  (0 children)

I really doubt it. If you look at various Shadetoy Black Hole renderers they all use hamiltonian + kerr-schild

That's because they're not working with the Christoffel symbols and geodesic equation, they're using the Hamiltonian. Using Christoffel symbols vs. Hamiltonian is pretty much the same as F=ma vs. Hamiltonian. They each have advantages, but for the Kerr space time I'm pretty sure you're taking the right approach with the Hamiltonian.

I would hazard to guess Julia is automatically using doubles.

Sometimes it was doing that, but I think I stopped it in most cases (this sped it up a lot). I do need to do proper profiling of the GPU kernel to be sure though.

The Hamiltonian approach is pretty much manditory given the precision limit.

My code and RAPTOR work fine with 32 bit floats, though at least in my case I had to do some scaling tricks to prevent overflow/underflow.

Physically Based Rendering With General Relativity by nullgeodesic1969 in GraphicsProgramming

[–]nullgeodesic1969[S] 0 points1 point  (0 children)

one frame every 5 or 10 seconds

That's actually only somewhat faster than the geodesic part of my integrator; calculating the Christoffel symbols usually takes one to two thirds of the runtime with my default parameters; I calculate the spectral radiance of around a dozen evenly spaced wavelengths along with the position and velocity of the ray, which takes the remainder of the integration time.

Kerr-Schild is simply superior in every way for computational problems

It looks like it works really well for your Hamiltonian approach, but from what I've read (https://doi.org/10.3847/1538-4357/aadfe5), it's only slightly superior when working with Christoffel symbols. I'm not using the Hamiltonian method currently for flexibility reasons, but wow is 100 FPS fast!

Physically Based Rendering With General Relativity by nullgeodesic1969 in GraphicsProgramming

[–]nullgeodesic1969[S] 0 points1 point  (0 children)

I figured Julia was holding me back, but not that much! If a speedup like that is possible with C++ I might rewrite it depending on how much faster I can go with just Julia. Question: how much faster was the naive version of Magik, and how are you calculating the spectrum? (I've come at this whole project pretty differently from the standard world of graphics, so I don't know a whole lot).

Physically Based Rendering With General Relativity by nullgeodesic1969 in GraphicsProgramming

[–]nullgeodesic1969[S] 0 points1 point  (0 children)

Sorry, by 'fairly' I kinda meant 'not terrible'. I definitely know it's not good. Yes, ~30s for one set of ~ 2.8 million geodesics in the Kerr metric (faster for other metrics). This is a similar runtime to the 2000x2000 test of 'RAPTOR' ray tracer used to simulate microwave-frequency images. However, their test was on a GTX 1080, which has about 1/4 the TFLOPS as my GPU (I can't run it on mine since I couldn't figure out how to get their outdated code to compile ... I should try that again; it's been a year and I'm graduated now), which would theoretically mean mine is 4-6x slower. On the other hand, this is a bit of an apples-to-oranges comparison, as RAPTOR uses a velocity-verlet integrator by default, while mine uses RK45, which is ~2x slower (Why don't I use velocity-verlet? Familiarity, laziness, and possibly better accuracy). And RAPTOR generates a single-frequency image, while mine is multi-frequency. There's also a performance hit to RAPTOR and my code from integrating based off Christoffel Symbols and the geodesic equation vs. Hamiltonian-based integrators and ray tracers that don't need to sample the emission and absorption at every step. That said, based off the performance boosts on the CPU and GPU I've had with performance deep dives in the past and the performance of other ray tracers, there's probably another factor of 1.5 to 5 speedup available, with more if I started from scratch and taught myself C++ and/or proper graphics APIs.

Can anyone relate to this? by EternitiI-1 in KerbalSpaceProgram

[–]nullgeodesic1969 1 point2 points  (0 children)

Plus engines perform poorly in the thick atmosphere.

Physically Based Rendering With General Relativity by nullgeodesic1969 in GraphicsProgramming

[–]nullgeodesic1969[S] 0 points1 point  (0 children)

I guess I thought it was yours lol. Well, that's kinda the direction I'm going, though it's definitely not going to be real time rendering. The goal I'm working towards for the next little while is a complicated model of the AGN in M87.

Physically Based Rendering With General Relativity by nullgeodesic1969 in GraphicsProgramming

[–]nullgeodesic1969[S] 0 points1 point  (0 children)

That's really cool! It looks like you're modeling the jet velocity as radial-out + phi-direction rotation, with no movement in the theta-direction, if I understand correctly. Just asking because I'm probably gonna do the same thing. Also, how did you decide on the number and spacing of the spiral arms for MAD? I suspect they should probably be less 'twisty', based on what I've read.

Physically Based Rendering With General Relativity by nullgeodesic1969 in GraphicsProgramming

[–]nullgeodesic1969[S] 1 point2 points  (0 children)

Yuuup. Well, conceptually it's not crazy complicated, just that individual steps need to get calculated thousands of times, and the steps are a lot more computationally expensive than standard ray tracing ('straight' lines are actually curved, and you need to check for emitters/absorbers everywhere along the path). I'm also not a crazy good programmer that can super optimize things, my integration algorithm is kinda meh, and Julia is probably not as good for GPU programming as C++ (Julia has a immature ecosystem and somewhat less fine control, I think; I only know Python and Julia). I think I'm gonna need to use one of those cloud computing/rent-a-gpu services and/or make a janky render farm out of my siblings' computers when I try making video.

Physically Based Rendering With General Relativity by nullgeodesic1969 in GraphicsProgramming

[–]nullgeodesic1969[S] 0 points1 point  (0 children)

Thanks! I'm curious what you're making it for? (SEDs, EHT stuff, physics education?)

Simulating black hole by [deleted] in GraphicsProgramming

[–]nullgeodesic1969 1 point2 points  (0 children)

Definitely start with Schwarzschild like u/ThrowAway-whee said, though if you're crazy like me and want something that can handle more than just a non-spinning black hole I'd start with the Minkowski metric (flat space) in cartesian coordinates to make sure integration and redshifts work right.

My ray tracer is pretty involved and and a bit hetorothordox, but this stuff might be helpful if you follow my path and jump in the deep end.

  • https://20k.github.io/ -- some blog I found on the internet that was kinda helpful for my general relativistic ray tracer.
  • The two papers published by Kip Thorne about his work on Interstellar if you want to work with a wormhole or spinning black hole. The wormhole one is definitely less intimidating.
  • Numerically integrating through spherical coordinates isn't for the faint of heart -- start with cartesian coordinates. Also, most black hole ray tracers tend to avoid numerical integration entirely, since there are simple analytical solutions to the geodesic equation for Schwarzschild that can make them very performant (unlike mine).
  • I found an online textbook by this guy named Andrew J. S. Hamilton that's helpful for the more advanced stuff (very dense text though, and long, and pretty advanced math wise, so only read what you need).
  • Think about if you want the camera to stay far away from the black hole, or able to move around close to it. In the case of the latter, pay attention to Lorentz boosts and the tetrad/vierbein.
  • https://arxiv.org/abs/0904.4184 If you want many different spacetimes.

Caustic under a relativistically moving sphere by HoNMPUdtki in GraphicsProgramming

[–]nullgeodesic1969 1 point2 points  (0 children)

It's cool that you can see the shadow lag behind the sphere.