Re: Glitch Pictures anyone? back
Board:
Home
Board index
Raytracing
Visuals, Tools, Demos & Sources
(L) [2012/06/18] [toxie] [Re: Glitch Pictures anyone?] Wayback![IMG #1 Image]
[IMG #2 Image]
[IMG #3 Image]
provided again by a colleague of mine.. [SMILEY :)]
[IMG #1]:
![[IMG:#0]](images/28ca7f9596f4d163defd43a0d2671fec2a6f624f0c8a69c23740bac1f241cab6.png)
[IMG #2]:
![[IMG:#1]](images/3ead196dfe9c9435e319fcba3827bbb5276569e64732f15f9cf79c01c871343d.png)
[IMG #3]:
![[IMG:#2]](images/324a3561530f953498baaab84fef6d4e298d44c673b1ac1d54c667c7e4a355ea.png)
(L) [2012/06/22] [franz] [Re: Glitch Pictures anyone?] Wayback!Glitch images archive updated: [LINK http://appleseedhq.net/galleries/glitch-pictures-ompforg].
As usual, drop me a line if you wish to remove your image(s) from the archive.
Cheers,
Franz
(L) [2012/06/26] [yiningkarlli] [Re: Glitch Pictures anyone?] Wayback!Recently a friend of mine and I implemented a basic CUDA Pathtracer, and we had some fun/interesting looking glitched renders along the way:
Incorrect but cool looking refraction:
[IMG #1 Image]
More incorrect refraction:
[IMG #2 Image]
What happens when you don't clear the image buffer after moving the camera:
[IMG #3 Image]
[IMG #1]:
![[IMG:#0]](images/ccd3f72b99966416d70de1ee09832fea9c2f9c1b2a635611205eb41a3b158231.png)
[IMG #2]:
![[IMG:#1]](images/fcc43007641a05c5b7c791a0b443947fe12a3036faa1a3026e2526394d0e0b7b.png)
[IMG #3]:
![[IMG:#2]](images/b69fe32fde3c8eb8b593feb193ab4bb87a072e199ea6bf0dfcbe3b3d5e84b4a8.png)
(L) [2012/06/27] [ingenious] [Re: Glitch Pictures anyone?] Wayback!>> yiningkarlli wrote:What happens when you don't clear the image buffer after moving the camera:
Hey, that's patented by Ray Tracey! [SMILEY 8-)]
(L) [2012/07/05] [toxie] [Re: Glitch Pictures anyone?] Wayback![IMG #1 Image]
(from another colleague of mine, thanx!)
[IMG #1]:
![[IMG:#0]](images/441c405928657c0b0adc8ffca80894262b20bbf24be1c9188955a69f54ccc04e.png)
(L) [2012/07/05] [franz] [Re: Glitch Pictures anyone?] Wayback!This one is truly awesome. Who made it?
Franz
(L) [2012/09/05] [fursund] [Re: Glitch Pictures anyone?] Wayback!Funky smoke [SMILEY :)]
[IMG #1 Image]
[IMG #1]:
![[IMG:#0]](images/40d3f3a8d83ffb2a272a82542f93ef9cd5675dd4bac0c39a2e48f5a380615023.png)
(L) [2012/09/07] [waldheinz] [Re: Glitch Pictures anyone?] Wayback![IMG #1 Image]
(writing a wavefront parser by looking at a sample file instead of the specification)
[IMG #1]:
![[IMG:#0]](images/218ab6b03b2b987d7b6ec4ae43a8033e03eaf7bfd675cf2a3281cfb3aa3197ae.jpg)
(L) [2012/09/23] [dylan] [Re: Glitch Pictures anyone?] Wayback!Having meant to join this forum for a while, this glitch looks like a good reason:
(You may need to right-click and view image to see the entire images)
My first stab at Kelemen-style Metropolis:
[IMG #1 Image]
Statistically correct (I think) reference made with normal importance-sampled PT and similar time:
[IMG #2 Image]
I think the contrast enhancement gives it a peculiar style, but the stars/speckles are annoying. Looks like old samples are splatting into new sample's coordinates, among other things.
[IMG #1]:
![[IMG:#0]](images/32523810105e1041f249ab22c249c7b754ba653fb002a8d9a3f5cf7f68a7ed5e.jpg)
[IMG #2]:
![[IMG:#1]](images/747d5b3402b3fc7a8d4a31ac8962457429d86953f7568785d65ef62a7dfb3b30.jpg)
(L) [2013/07/02] [toxie] [Re: Glitch Pictures anyone?] Wayback!And a new one created by Dietger:
[IMG #1 Image]
[IMG #1]:
![[IMG:#0]](images/1bd5fa91991c63f8476960b591641496959eae371e07b771d982a19e98f2a7f1.png)
(L) [2013/07/02] [ypoissant] [Re: Glitch Pictures anyone?] Wayback!That one is worth a frame.
I'd like to have glitches like that.
(L) [2013/07/07] [Dade] [Re: Glitch Pictures anyone?] Wayback!Quite amazing, is it related to something gone wrong with bump mapping ?
(L) [2013/07/07] [1040st] [Re: Glitch Pictures anyone?] Wayback!>> Dade wrote:Quite amazing, is it related to something gone wrong with bump mapping ?
No, actually that is a (tesselated) glass sphere [SMILEY :D]
I don't remember all the details - the picture is quite old - but it was a combination of mistakes: wrong uv coordinates for normal interpolation, missing normalization and a wrong fresnel term.
(L) [2013/07/12] [sriravic] [Re: Glitch Pictures anyone?] Wayback!I guess I was trying to do conic rays.!!! Figured out finally the issue was caused by not doing a normalization of direction..!!
(L) [2013/09/08] [Dade] [Re: Glitch Pictures anyone?] Wayback!>> Thammuz wrote:(pro tip: don't stare at it for too long, might cause headache/seizures)
Haha, it is true [SMILEY :shock:]
(L) [2013/10/28] [Dany0] [Re: Glitch Pictures anyone?] Wayback!This thread looks like something David O'Reilly would like.
(L) [2014/01/23] [cessen] [Re: Glitch Pictures anyone?] Wayback![IMG #1 Image]
A bicubic bezier surface with motion blur. The weird effect came from incorrect indexing of the geometry. I got coordinates over the surface confused with coordinates over time. It didn't cause any issues until I rendered something with motion blur.
[IMG #1]:
![[IMG:#0]](images/e38866a43a04e4a2b13ab52d9bcd8f775777ec694c8d470380e884916d798d0a.png)
(L) [2014/05/09] [ingenious] [Re: Glitch Pictures anyone?] Wayback!I don't see anything wrong with that snow... [SMILEY :roll:]
(L) [2014/05/10] [snwy_] [Re: Glitch Pictures anyone?] Wayback!A bug was fixed where moisture was created out of thin air under certain circumstances, leading to what I assume you thought was snow. But then, they're much the same thing, clouds and snow.
(L) [2014/06/11] [toxie] [Re: Glitch Pictures anyone?] Wayback!Precision issues on curved surfaces created by a colleague
[IMG #1 Image]
[IMG #1]:
![[IMG:#0]](images/17c43560fb4168420ae2aa6ecd01bb1502643bcf1b114312042625dde701953c.png)
(L) [2014/07/17] [toxie] [Re: Glitch Pictures anyone?] Wayback!As the link in the first post to franz' archive is broken, here some more old stuff of mine:
[IMG #1 Image]
Generating a Sierpinski Tri by accident:
[IMG #2 Image]
Filtering gone wrong:
[IMG #3 Image]
[IMG #4 Image]
Killing precision:
[IMG #5 Image]
[IMG #1]:
![[IMG:#0]](images/f838860c953727624b48753e50a2903bfc19c6a0bf9fb1e883cc6631669aa463.jpg)
[IMG #2]:
![[IMG:#1]](images/0ec28f526de8cb10c01d948493ed6ff731d049ccf79416268874d0b627425a92.png)
[IMG #3]:
![[IMG:#2]](images/3a516a8a845f4d2fc7d2762edcaa97596621893a687a68a8e73a5bd94c6b7326.png)
[IMG #4]:
![[IMG:#3]](images/6c0f288a235e3bf56edd31f40663691e2f055d2e8e3e660658f248b0215d8cd3.png)
[IMG #5]:
![[IMG:#4]](images/5dc497f97cd001c21d06a4a0d615be89dab81c9e6ab88e037baf49375b58f07d.png)
(L) [2014/07/17] [toxie] [Re: Glitch Pictures anyone?] Wayback!And a new/old one:
[IMG #1 Image]
[IMG #1]:
![[IMG:#0]](images/7b49c2b3d0bae4350c7ef7ba1a8d3ed579df46548c3f4cc11cc818da99f922eb.jpg)
(L) [2014/07/31] [yuriks] [Re: Glitch Pictures anyone?] Wayback!My tracer had some funny ideas about how shadows work for a while:
[IMG #1 Image]
[IMG #1]:
![[IMG:#0]](images/d805241d6c688f92fe529742172812008ee0826a124fe9f7348d7cdd166c25e8.png)
(L) [2014/10/17] [citadel] [Re: Glitch Pictures anyone?] Wayback!Alien smoke (keyword: HG)
[IMG #1 Image]
[IMG #2 Image]
[IMG #1]:
![[IMG:#0]](images/ebc3ab85df65e5e85f9d7582e79de90d6603501c9026ed490207be0613d241ee.png)
[IMG #2]:
![[IMG:#1]](images/73aa5cf5697e8e57be80d6bf6ef000a54e00efface0be5cea45e3578a1aa3ab3.png)
(L) [2014/10/18] [JasonSmith] [Re: Glitch Pictures anyone?] Wayback!I think this looks pretty much right.
(L) [2014/10/18] [fpsunflower] [Re: Glitch Pictures anyone?] Wayback!Not sure what happened here ...
(L) [2014/10/20] [Agorath] [Re: Glitch Pictures anyone?] Wayback!Not sure yet what exactly happened here, but it kind of looks like my tracer decided that light should behave like a wave as opposed to independent particles [SMILEY ;)]
(L) [2014/12/14] [ost
by Benjamin-L] [Re: Glitch Pictures anyone?] Wayback!A very broken implementation of stratified sampling:
cornellBoxSphere.jpg
(L) [2015/02/23] [sriravic] [Re: Glitch Pictures anyone?] Wayback!I really have no idea what is going on but this image kind of looks like disco lamps in full glow.
(L) [2015/05/25] [ost
by snwy_] [Re: Glitch Pictures anyone?] Wayback!Some old glitches from the archives.
[IMG #1 Image]
[IMG #2 Image]
The first was a bvh issue, I recall; the second had to do with subsurface scattering making creepy lighting (and some nan pixels).
[IMG #1]:
![[IMG:#0]](images/fae18cd6de7b38886d6458c0c4caf3b31fbb8872b91aaa5aed2ac35e62d45093.png)
[IMG #2]:
![[IMG:#1]](images/630aa325ed34a6fba03148d4ef92c45f856807c7fc6b176fba8b44521e8e8e07.png)
(L) [2015/08/25] [ost
by toxie] [Re: Glitch Pictures anyone?] Wayback![IMG #1 Image]
floating point precision going downhill (this should be a sphere), from a colleague.
[IMG #1]:
![[IMG:#0]](images/6b891733f6874573f771244814f8950fc44d42cf142d76e9d336c001b3f6b95a.png)
(L) [2015/08/26] [tby ultimatemau] [Re: Glitch Pictures anyone?] Wayback!Accidentally forgot to turn of galaxy DOF mode in the some shader [SMILEY :roll:]
(L) [2015/09/12] [ost
by danielthompson] [Re: Glitch Pictures anyone?] Wayback!One of my first path tracing renders:
trace000000.png
Fail.
(L) [2015/10/30] [tby yiningkarlli] [Re: Glitch Pictures anyone?] Wayback!Toxie posted one like this a while ago, I managed to reproduce the same glitch by accident!
In this case it's the photon tracing part of VCM drawing samples from Sobol in a bad way.
[IMG #1 Image]
[IMG #1]:
![[IMG:#0]](images/f8de762fff2adf9ea04be163c675d0db647fe0d8e7ae598f469a8040a24951e9.png)
(L) [2015/10/30] [tby davepermen] [Re: Glitch Pictures anyone?] Wayback!>> ultimatemau wrote:Accidentally forgot to turn of galaxy DOF mode in the some shader
back this renderer up as wallpapergenerator.exe somewhere.. [SMILEY :)]
(L) [2015/10/30] [tby asyrov] [Re: Glitch Pictures anyone?] Wayback!Here is mine, with ray hit calculation 2 issues which I'm working on now in my hobby ray tracer:
(1) sometimes rays go through the wall, this issue is caused by a difference in calculation method of distance in triangle intersection and kd-tree (at least this is my current understanding of it). the issue is clear, especially on left wall;
(2) hitting into angle point (point that belongs to both (say left and back walls), still thinking how to deal with it (probably need to add self check into shadow ray intersection test, instead of epsilon);
(yet another issue is that how to paint windows, right now they are confusing...)
[IMG #1 aheadeps.jpg]
[IMG #1]:Not scraped:
/web/20160823011244im_/http://ompf2.com/download/file.php?id=215&sid=014236623c0d7dc69be55ad511b5fc49
(L) [2015/10/30] [ost
by asyrov] [Re: Glitch Pictures anyone?] Wayback!Here is mine, with ray hit calculation 2 issues which I'm working on now in my hobby ray tracer:
(1) sometimes rays go through the wall, this issue is caused by a difference in calculation method of distance in triangle intersection and kd-tree (at least this is my current understanding of it). the issue is clear, especially on left wall;
(2) hitting into angle point (point that belongs to both (say left and back walls), still thinking how to deal with it (probably need to add self check into shadow ray intersection test, instead of epsilon);
(yet another issue is that how to paint windows, right now they are confusing...)
aheadeps.jpg
(L) [2015/11/03] [tby tex] [Re: Glitch Pictures anyone?] Wayback!I was searching an old render of mine when I've stumbled upon this picture. Not sure how I got this effect but that's quite the quantum leap... [SMILEY :geek:]
(L) [2016/02/02] [tby rouncer] [Re: Glitch Pictures anyone?] Wayback!That last head render is nice, like the dithering on the skin.
As far as a glitch from me, im not sure what to post cause the whole thing is one. [SMILEY :)]
If a glitch is anything unintentional, the whole thing is really. I think mistakes are the most beautiful part of developing anything in life.
Starts off a glitch, ends up an effect.
(L) [2016/06/20] [tby szellmann] [Re: Glitch Pictures anyone?] Wayback![LINK https://youtu.be/DrEkr1PJIDs]
Glitch starts at sec. 14 where the path tracer tries to converge while the scene data changes. Found this "effect" especially interesting with the animation moving this particular way.
(L) [2016/06/27] [tby spectral] [Re: Glitch Pictures anyone?] Wayback!Motion blur for free [SMILEY :-D]
(L) [2016/07/14] [ost
by danielthompson] [Re: Glitch Pictures anyone?] Wayback!Sphere + affine transformations = fail
10994455_670364286407562_4875625012403618091_o.png
(L) [2016/07/14] [ost
by patlefort] [Re: Glitch Pictures anyone?] Wayback!It's possible to not fail affine transformation for a sphere if you transform the ray into the local coordinate of the sphere.
(L) [2016/07/15] [ost
by papaboo] [Re: Glitch Pictures anyone?] Wayback!It is, but then he wouldn't have rendered a glitch picture. [SMILEY :)]
(L) [2017/01/05] [ost
by T.C. Chang] [Re: Glitch Pictures anyone?] Wayback!After a bad refactor of my simple path tracer [SMILEY :shock:]
bad%20refactor%20cornell%20box.png
(L) [2017/02/07] [ost
by stefan] [Re: Glitch Pictures anyone?] Wayback!How to not optimise CUDA BVH traversal.
Screen Shot 2016-06-03 at 13.55.15.jpg
(L) [2017/02/09] [ost
by toxie] [Re: Glitch Pictures anyone?] Wayback!spooky, but also extremely artsy..
(L) [2017/02/10] [ost
by stefan] [Re: Glitch Pictures anyone?] Wayback!Lesson learnt: When you want all threads in a warp to participate in a memory fetch (see Tony Scudiero's GTC presentation "Memory boot camp III"), first make sure all threads are active.
(L) [2017/04/20] [ost
by patlefort] [Re: Glitch Pictures anyone?] Wayback![IMG #1 Image]
Fail trying to use sobol sequences with bidirectional path-tracing.
[IMG #1]:
![[IMG:#0]](images/470a7675a7cae405514db6015b44f48453e5ef17f5f392a741933d54d5b0e087.png)
(L) [2017/04/29] [ost
by beason] [Re: Glitch Pictures anyone?] Wayback!>> toxie wrote:spooky, but also extremely artsy..
Agreed. Quite nice effect! Suitable for stylish avatar pic.
(L) [2017/05/13] [ost
by jbikker] [Re: Glitch Pictures anyone?] Wayback!Trying to implement 'Irregular grids'. Almost there. [SMILEY :)]
(L) [2017/05/17] [ost
by ziu] [Re: Glitch Pictures anyone?] Wayback!>> jbikker wrote:Trying to implement 'Irregular grids'. Almost there.
Heh. I have seen much worse than that. In case you need someone to talk with about this we published a couple of articles on gpgpu rectilinear grids some time back. If you eventually publish something with grids I would be interested to look at it.
(L) [2017/05/17] [ost
by ultimatemau] [Re: Glitch Pictures anyone?] Wayback!>> jbikker wrote:Trying to implement 'Irregular grids'. Almost there.
Looking good! I might give this a try myself [SMILEY :)]. Are you looking at: [LINK http://www.kalojanov.com/data/irregular_grid.pdf] ?
(L) [2017/05/17] [ost
by jbikker] [Re: Glitch Pictures anyone?] Wayback!Correct. [SMILEY :)]
(L) [2017/05/19] [ost
by ziu] [Re: Glitch Pictures anyone?] Wayback!>> ultimatemau wrote:Looking good! I might give this a try myself . Are you looking at: [LINK http://www.kalojanov.com/data/irregular_grid.pdf] ?
That is an interesting paper! While it does have some similarities to macro-regions it looks a lot more similar to this old algorithm that dynamically increases and decreases the size of each of the grid's voxels depending on the amount of rays entering it and the amount of primitives to be intersected inside the voxel (i.e. the load). The difference with the irregular grid paper above is there the SAH is pre-computed and the voxels are resized as a pre-processing step instead of being dynamically re-computed during rendering like in the old paper (that I link below):
[LINK http://graphicsinterface.org/wp-content/uploads/gi1986-9.pdf]
It is a shame Nemoto & Omachi's (1986) paper was not linked in that article since it seems a lot more relevant than most of the things it references. There are also more recent references with macro-regions e.g. "Macro 64-regions for uniform grids on GPU" (2014), Eugene M. Taranta II, Sumanta N. Pattanaik. The proximity clouds references are kinda pointless. Although it is also a space skipping technique it's different.
Also: The data structure used in the "GPU Ray Tracing using Irregular Grids" paper (uniform grid/bounding volume hybrid) looks really similar to that proposed in the paper "Adaptive cell division for ray tracing" (1991), B. Pradhan, A. Mukhopadhyay. (see Fig. 3). or "A new algorithm of space tracing using a CSG model" (1987), Kadi Bouatouch, Mohamed Ouali Madani, Thierry Priol, Bruno Arnaldi. (see Figure 4). Link:
[LINK https://hal.inria.fr/inria-00075942/document]
This data structure is also described in "The EXCELL Method for Efficient Geometric Access to Data" (1982), M. Tamminen. (see Figures 2, 5).
So this paper lacks essential references. Plus it has too many pointless BVH and kd-tree references. This part of the paper, the related work and the references, could use some improvement.
Their grid construction algorithm could also be faster. Looking at their 'emit_new_refs', for example, it uses a per primitive loop to generate the prim and cell ids, which will have poor workload distribution in scenes with dissimilar sized primitives. We solve that in our paper:
[LINK https://www.academia.edu/13928983/Efficient_Grid_Construction_on_Streaming_Architectures]
It is nice that the article comes with code and the algorithms are interesting (though not completely novel) also the results speak for themselves. The solution also has quite nice rendering performance!
It is nice to see people working on grids. They have been IMHO under explored in the present literature so this paper is very welcome!
(L) [2017/06/03] [ost
by javor] [Re: Glitch Pictures anyone?] Wayback!Hi, I tried to create a new topic and post a reply there several times already, but without success. Sorry for carrying this thread further off-topic.
It is great to see that our paper received attention from members of the forum. Myself and Arsene will be happy help anyone who is interested in experimenting in this direction.
To address Vasco's concerns:
>> ziu wrote:So this paper lacks essential references. Plus it has too many pointless BVH and kd-tree references. This part of the paper, the related work and the references, could use some improvement.
The Nemoto & Omachi and Taranta et al. citations are certainly an oversight on our side, thanks for pointing this out. I was not aware of the first paper, and have no excuse for forgetting to cite the Macro/Micro regions papers. When writing the paper, we considered positioning the paper only as a grid-based ray tracing method, but decided against that. Personally, I think that pointing the reader towards the state-of-the-art ray tracing approaches on current hardware is more important than differentiating our method from algorithms tested so far back in time. If it was up to me, we would also leave out the comparison with macro-regions, which was forced on us by the primary reviewer. We are aware that a multitude of similar approaches exist and have been tried before. The important point is that the particular combination of techniques we implemented delivers surprisingly good performance from a type of acceleration structure, which, as you said, does not see a lot of attention.
>> ziu wrote:Their grid construction algorithm could also be faster. Looking at their 'emit_new_refs', for example, it uses a per primitive loop to generate the prim and cell ids, which will have poor workload distribution in scenes with dissimilar sized primitives. We solve that in our paper:
[LINK https://www.academia.edu/13928983/Effic] ... hitectures
The construction speed is indeed the part where we expect to see improvements in the future, however, I would look elsewhere for optimization opportunities. Overall the initial two-level grid construction is the fastest part of the build process, and most of the time is spent merging and expanding cells. Also, the first level grid we create is too sparse for the suggested technique to work, which is why Arsene did not include it in the implementation. Of course, we are happy to be proven wrong!
(L) [2017/06/07] [ost
by ziu] [Re: Glitch Pictures anyone?] Wayback!>> javor wrote:The Nemoto & Omachi and Taranta et al. citations are certainly an oversight on our side, thanks for pointing this out. I was not aware of the first paper, and have no excuse for forgetting to cite the Macro/Micro regions papers. When writing the paper, we considered positioning the paper only as a grid-based ray tracing method, but decided against that. Personally, I think that pointing the reader towards the state-of-the-art ray tracing approaches on current hardware is more important than differentiating our method from algorithms tested so far back in time. If it was up to me, we would also leave out the comparison with macro-regions, which was forced on us by the primary reviewer. We are aware that a multitude of similar approaches exist and have been tried before. The important point is that the particular combination of techniques we implemented delivers surprisingly good performance from a type of acceleration structure, which, as you said, does not see a lot of attention.
Hey Javor,
Well some of the references I mentioned are obscure and rather dated. So I can certainly understand how they could have been overlooked.
But it is essential that you guys reference the EXCELL (Tamminen et al.) data structure papers in future publications. It is the exact same acceleration structure even if the construction method might not be the same. You guys quote already Cleary and McDonald and Booth which are also quite old and IMHO less apropos. So it doesn't make sense to ignore the references of the guys who actually describe the same data structure. I've searched the literature some more afterwards. Jensen mentions using EXCELL in the early 1980s in the RTNews archives and it seems to have been fairly commonly used back then (e.g. it's also referenced in Bouatouch's papers). For whatever reason both later favored kd-tree data structures. My guess is this was due either to hardware limitations back then or due to improvements to kd-tree SAH methods which made them faster. For example, regarding hardware, back in the 1980s it was common to use an hashtable to store the grid due to memory limitations but today quite often we just use a plain array because memory is much more plentiful and pointer chasing degrades performance. Back then the memory wall barrier characteristics were a lot different. Hardware memory latency was comparatively better versus instruction latency so the algorithms reflect that.
>> javor wrote:The construction speed is indeed the part where we expect to see improvements in the future, however, I would look elsewhere for optimization opportunities. Overall the initial two-level grid construction is the fastest part of the build process, and most of the time is spent merging and expanding cells. Also, the first level grid we create is too sparse for the suggested technique to work, which is why Arsene did not include it in the implementation. Of course, we are happy to be proven wrong!
Well in that case you guys would indeed be better off looking at the kd-tree (morton) or macrocell related literature for improvements in build times. But looking at Figure 5 in your paper you spend like 40% of construction time building the initial grid on average. San Miguel in particular has a lot of dissimilar sized triangles. In our experience this can be done up to 9x faster for such scenes. It's a shame we can't compare your build times with a state of the art high-quality GPU BVH or kd-tree like (Karras and Aila 2013) since their code is AFAIK not publicly available. Still it seems to me, from reading your paper, that you guys have achieved state of the art rendering performance, which is the main focus of your algorithms. So kudos for that!
So it's interesting to see you guys show it's possible to have good rendering rates with a grid based acceleration structure. I suspected as much from looking at the late 1980/early 1990s literature but I couldn't convince people on arguments alone. The thing is, what burned a lot of people back then, was that hierarchical grids have a lot of edge cases where the memory consumption exploded or the performance didn't go up no matter how much you increased the grid resolution so it kind of put people off grids for ever. Typically this involved scenes with nested geometry akin to the Hairball scene we use today. The Standard Procedural Databases "Shells" scene is the example typically used back then.
(L) [2017/12/12] [tby papaboo] [Re: Glitch Pictures anyone?] Wayback!SPTD_glitch.png
Messed up a transform while cleaning up my implementation of A Spherical Cap Preserving Parameterization for Spherical Distributions. I call it the Blackhole Sun effect. [SMILEY :)]
(L) [2018/11/12] [ost
by olliej] [Re: Glitch Pictures anyone?] Wayback!Behold the majesty of an exceptionally bug in my BVH construction - a copy/paste error that resulted in completely bogus behavior when merging bounding boxes:
weird iterative bvh results.png
(L) [2019/02/08] [ost
by olliej] [Re: Glitch Pictures anyone?] Wayback!Something going very wrong in photon mapping:
[IMG #1 Image]
[IMG #1]:
![[IMG:#0]](images/5197eecc31cb76dfcdd05fb2ae62595841a83599df02c0bd0f56e99ed172e9c9.png)
(L) [2019/02/23] [ost
by dawelter] [Re: Glitch Pictures anyone?] Wayback!Trying to implement beam radiance estimation.
Regular photon mapping. This is roughly what it should look like.
photonmap.jpg
I use a piecewise constant estimate of the transmittance function where I do the beam query. Read beyond array bounds. Need to put range checks in assert macro everywhere, even where I'm sure I got it right [SMILEY ;-)]
beamestimatebug1.jpg
I don't know yet. I think it has a certain appeal. As if an artist became extra creative, spraying paint across his canvas [SMILEY :lol:]
beamestimatebug2.jpg
(L) [2019/02/23] [ost
by jbikker] [Re: Glitch Pictures anyone?] Wayback!So basically your out of bound error caused a Buddha apparition? [SMILEY ;)]
(L) [2019/02/24] [ost
by dawelter] [Re: Glitch Pictures anyone?] Wayback!Ha ha! Well, it's a manifestation of my wish to render a better looking scene, and I'm not talking about bugs. So I was basically just messing around [SMILEY ;-)]
The second bug was a too long query beam. Now I call this good enough in spite of the color bleeding below the bunny [SMILEY :roll:]
box_bunny_medium.jpg
(L) [2019/05/16] [ost
by olliej] [Re: Glitch Pictures anyone?] Wayback!I vaguely recall the problem being texture loading related
[IMG #1 Image]
[IMG #1]:
![[IMG:#0]](images/dc79b754bb803440a0d355f0cb8bcab6d7fb8df7a9de300b0e72b1a7415e97c4.png)
back
