The strain of going from a 32 x 22 image to a 256 x 176 one is evident in how much longer this secondary image took to render. From 879.75 seconds (nearly 15 minutes) to 61,529.88 seconds (over 17 hours). Luckily, some optimisations and time-saving tweaks meant this could be brought down to 8,089.52, or near-ish two and a half hours.
Those are really reasonable values. I guess my laptop would take that long to render a 4k image as well.
pixeltree@lemmy.blahaj.zone 5 months ago
Really depends on the complexity of the frame being rendered for how fast your laptop can render it
frezik@midwest.social 5 months ago
Ray tracing speed primary depends on the number of pixels, not the complexity of the scene.
pixeltree@lemmy.blahaj.zone 5 months ago
The complexity of your scene makes a huge difference. If your scene has fewer things for light to bounce off of, doing the ray tracing ia much faster
frezik@midwest.social 5 months ago
So I’m not exactly sure how Blender implements this. There can be a few details that can make a huge difference. Just for starters, is Blender rendering 100% ray tracing here, or is it a hybrid model with a rasterizer. Rasterizers tend to scale with the number of objects, while ray tracing scales with the number of pixels. A hybrid will be, obviously, something in between.
Then there is how it calculates collisions. There is a way to very quickly detect collisions of AABB boxes (basically rectangles that surround your more complicated object), but it takes a little effort to implement this and get the data structures right. You can actually do Good Enough sometimes by matching every ray to every AABB, and then you do more complex collision checking against what’s left, but there’s a certain scale where that breaks down.
Blender is generally very well done from what little I know of it, but I’m not sure how it handles all these tradeoffs.