cmo
New Member
Posts: 6
|
Post by cmo on Feb 22, 2021 23:11:27 GMT
Didn't run it as a benchmark, just a single instance.
Took about 7 minutes:
1280 x 1024
single core of Raspberry pi 400
Go implementation
What is your reflective recursion depth? I think a large value could potentially slow down rendering. Mine was set at 5.
-C
|
|
|
|
Post by signal11 on Feb 23, 2021 4:48:42 GMT
Didn't run it as a benchmark, just a single instance. Took about 7 minutes: 1280 x 1024 single core of Raspberry pi 400 Go implementation What is your reflective recursion depth? I think a large value could potentially slow down rendering. Mine was set at 5. -C for me the recursion-depth is '5' and the numbers that i had posted were in milliseconds. so the overall render time was '14.671' seconds. my implementation is c++ based, and runs on a decade old "Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz"... -- best regards signal11 |
|
|
|
Post by bezdomniy on Feb 25, 2021 22:30:19 GMT
I got 1.1 seconds on an M1 MacBook Air on my native implementation. The web implementation is pretty fast too - you can select the reflections scene and change the camera size at the top of the yaml to check it out: iliathoughts.com/posts/raytracer2/Btw, Apple silicon is really great for cpu ray tracer performance. I've tested my implementation on my 12 thread ryzen 3600X on my desktop and it wasn't as fast on my m1 macbook air. |
|
|
|
Post by signal11 on Feb 27, 2021 8:55:07 GMT
I got 1.1 seconds on an M1 MacBook Air on my native implementation. The web implementation is pretty fast too - you can select the reflections scene and change the camera size at the top of the yaml to check it out: iliathoughts.com/posts/raytracer2/Btw, Apple silicon is really great for cpu ray tracer performance. I've tested my implementation on my 12 thread ryzen 3600X on my desktop and it wasn't as fast on my m1 macbook air. that's awesome ! m1's are blowing everything out of water these days  unfortunately, i have the machine that i have, and can't really be bothered to upgrade yet. for the timings that you have quoted, may you please specify the final image resolution that gets generated ? from your webpage, it seems to be a 800x600 image ? for my case, with that resolution it takes, approx. 6 seconds. relevant lines from the benchmark: .../ray-tracer/src/render_with_t3r.cpp : 00087 | benchmark details : {mean (ms): '05950', standard-deviation (ms): '00096'}
would you happen to have a good resource for implementing BVH and other acceleration optimizations for the ray-tracer ? the only place i know is PBRT aka the god-book. and unfortunately, it is not of the 'ready-fire-aim' variety. you need to really sit down and then drink from the firehose. -- best regards signal11 |
|
|
|
Post by inventordave on Feb 27, 2021 19:26:44 GMT
I successfully implemented a rather speedy BVH implementation using Jamis's bonus chapter here: BVH Bonus ChapterI did some extra thinking, nothing too dramatic, and it speeds things up no end. |
|
|
|
Post by signal11 on Feb 28, 2021 4:56:36 GMT
I successfully implemented a rather speedy BVH implementation using Jamis's bonus chapter here: BVH Bonus ChapterI did some extra thinking, nothing too dramatic, and it speeds things up no end. thank you kindly for the link. i was also looking around yesterday for references on BVH, and found ingo-wald's paper 'ray tracing deformable scenes using dynamic bounding volume hierarchies'. at first blush, the paper seems pretty comprehensive in its treatment of the topic. when coupled with your suggestion, i might have a shot at it  let's see how it all goes... -- best regards signal11 |
|
|
|
Post by bezdomniy on Feb 28, 2021 11:00:10 GMT
I essentially just copied the code from pbrt in the following function: github.com/mmp/pbrt-v3/blob/aaa552a4b9cbf9dccb71450f47b268e0ed6370e2/src/accelerators/bvh.cpp#L236There is a lot in there, but most of the logic is to do with implementing SAH (Surface Area Heuristic) partitioning which you don't really need, you get most of the way there with EqualCounts split method which just tries to put the same number primitives in each branch of the tree. In terms of other optimizations, just profiling to find slow methods and try and improve them is the way to go. If the language you are using allows, finding ways to get rid of dynamic memory allocation during render time leads to pretty significant speedups. Also, on the web implementation, the image is indeed 800x600, but you can change the camera size in the text box and it will render at whatever resolution you put in (in the -add: camera yaml tag) - you can change other stuff too. |
|
|
|
Post by vorpal on Jan 17, 2023 5:48:36 GMT
I really need to implement a YAML importer, but I'm not sure how easy that's going to be, given that I'm using functional programming and immutable objects, so I kind of build things backwards as to how much of the code goes: I set up all the pieces, and then assemble them instead of creating the top level objects and then setting properties on them and adding to them. (I've never worked with YAML on that level before.) I was getting a slight glitch on the rightmost foreground sphere where I wasn't getting that upward curvature on the left hand side, but now everything appears to be working properly after seeing I had made some mistakes translating the YAML to source, thankfully, instead of making an obscure error in my calculations:   |
|
unfortunately, i have the machine that i have, and can't really be bothered to upgrade yet. for the timings that you have quoted, may you please specify the final image resolution that gets generated ? from your webpage, it seems to be a 800x600 image ? for my case, with that resolution it takes, approx. 6 seconds. relevant lines from the benchmark:
