HOME | DD
Published: 2016-03-01 17:16:55 +0000 UTC; Views: 255; Favourites: 1; Downloads: 9
Redirect to original
Description
Maybe if I do not put in a decent title, it will distract from the fact that I used the scene setup from the previous render.As usual, render was done with my own software. Enjoy.
Finally got around to adding surface area heuristics (SAH) when building the acceleration structure for mesh intersection (currently using BVH), and boy was that easy. On the face of it, SAH appear to require some tricky calculation, however when the values calculated are only used for each build node it is reduced. Only four values needs to be calculated then and they are the easy ones to do, although significantly slower than middle split. SAH will build a tree that at worst perform the same as a regular middle split for a, depending on the number of elements, small increase in pre-render time.
The rendered object was built in about 6 seconds (vs. ~0.2 with mid split) and reduced the render time with 1-2 hours. Another test object was build in about the same time with SAH and middle split, but render time was less than a few second with the SAH tree, compared to minutes for a single sample per pixel render with middle split (e.g. unusable).
I have a suspicion that it is possible to reduce the construction time using the surface area of the bound volume for each element in the object, but some experimentation is needed for that. Also need to add multi thread support, to reduce the build time.
Edit: Now rendered with double to correct for the limitations of float.
Related content
Comments: 2
lyc [2016-03-02 06:31:53 +0000 UTC]
you should make the fullview be 1:1, so you don't have to click download
viewing this full-res image, it appears like there's some bug in the code, you can see some weird aliasing / block artifacts on the edges of the 1:1 image
👍: 0 ⏩: 1
Mathness In reply to lyc [2016-03-03 15:34:52 +0000 UTC]
Was hoping to track down the issue and get a re-render uploaded before anyone noticed (new one should be up tomorrow).
I thought it was a bug as well, either from camera sampling or the thinness of the object (but the previous render did not have that issue, so that idea was put down fast). Rather it is from using floats instead of doubles for the vertices along with a transformation matrix to place the object in the scene that causes it. Guess I have to move into the modern area of doubles, although it makes me wonder if GPU have the same issue (if I ever get around to working on that render engine again) as GPU is slow with doubles.
👍: 0 ⏩: 0

























