tag:blogger.com,1999:blog-7773532993303488759.post6300854194343420440..comments2023-04-12T08:33:48.690+02:00Comments on Icare3D Blog: Ph.D thesis: GigaVoxelsCyril Crassinhttp://www.blogger.com/profile/16474299434636795969noreply@blogger.comBlogger15125tag:blogger.com,1999:blog-7773532993303488759.post-14174350484638440262013-01-16T13:35:42.318+01:002013-01-16T13:35:42.318+01:00In your thesis you describe how to cone trace soft...In your thesis you describe how to cone trace soft shadows for point lights and area lights - what difference would the technique be for a directional light - like the one in the Sponza scene that you show?gboxentertainmenthttps://www.blogger.com/profile/03328289442403438955noreply@blogger.comtag:blogger.com,1999:blog-7773532993303488759.post-52233636253172552772012-11-09T11:56:08.257+01:002012-11-09T11:56:08.257+01:00Hi Cyril,
I've noticed in your demo video of t...Hi Cyril,<br />I've noticed in your demo video of the Sponza scene that you only use bricks (the voxels in red) at the lowest level - is this correct?Anonymoushttps://www.blogger.com/profile/02602891305954916435noreply@blogger.comtag:blogger.com,1999:blog-7773532993303488759.post-82694362038850408912012-10-17T10:20:32.765+02:002012-10-17T10:20:32.765+02:00Hi Cyril, great job!
This is interesting that I re...Hi Cyril, great job!<br />This is interesting that I read through it recently. In your paper you mentioned that you chose to store isotropic Gaussian lobes characterized by an averaged vector D and a standard deviation σ. By Toksvig's paper, we have σ2 = 1-|D|/|D|. To understand this, I found Toksvig's paper of Mipmapping_Normal_Maps(http://developer.download.nvidia.com/whitepapers/2006/Mipmapping_Normal_Maps.pdf). However, I don't quite understand how he draw the curve of function of σ and |D| by Gaussian distribution. I mean, if |D| = f(σ), what the f(σ) is?xiao.yuhttps://www.blogger.com/profile/01607699138847238411noreply@blogger.comtag:blogger.com,1999:blog-7773532993303488759.post-43748723775243699552012-04-03T12:32:06.441+02:002012-04-03T12:32:06.441+02:00Impressive work!
At the end of the thesis you pro...Impressive work!<br /><br />At the end of the thesis you provide FragSniffer tool, which I can't compile unfortunately with visual studio 2010 because you provide precompiled nemographics.lib binary compiled with earlier visual studio version which I don't have access to (I believe it is vs2005). This makes it impossible to build your tool with other versions of visual studio.<br />I wonder if you could provide the sources or recompile this library with visual studio 2010 compiler ?SergeyNhttps://www.blogger.com/profile/13447857343418516702noreply@blogger.comtag:blogger.com,1999:blog-7773532993303488759.post-53043413840768278472012-03-13T02:30:41.216+01:002012-03-13T02:30:41.216+01:00This comment has been removed by the author.PShttps://www.blogger.com/profile/03992527788905662829noreply@blogger.comtag:blogger.com,1999:blog-7773532993303488759.post-53255008506373159492012-03-12T01:04:25.064+01:002012-03-12T01:04:25.064+01:00Ah of course ... the second I started reading your...Ah of course ... the second I started reading your reply it clicked! :) Merci!PShttps://www.blogger.com/profile/03992527788905662829noreply@blogger.comtag:blogger.com,1999:blog-7773532993303488759.post-75681866921091967062012-03-11T16:07:30.304+01:002012-03-11T16:07:30.304+01:00In facts you need more for two reasons. The first ...In facts you need more for two reasons. The first reason is that in your 8x8x8 brick you count 8 voxels in depth, so to cover the 2M pixels screen you need more bricks. Also the depth complexity per pixel is usually >1, wish means that you need more than 1 voxel per pixel. However, your bricks do not necessarily align with the voxels actually needed for each pixel and thus you often need more than one brick in depth per pixel. These two reasons link with the problem of the granularity of the bricks, and reducing brick size allows to converge to the storage of the exact number of voxels actually needed per pixel. But then the borders become very costly...Cyril Crassinhttps://www.blogger.com/profile/16474299434636795969noreply@blogger.comtag:blogger.com,1999:blog-7773532993303488759.post-66875782020701338872012-03-11T12:47:19.077+01:002012-03-11T12:47:19.077+01:00Thanks for the clarification! Another quick questi...Thanks for the clarification! Another quick question: if N=2 and M=8, each brick contains 512 voxels and hence (since one node addresses at most one brick) a total of 512 node tiles (4096 nodes) would be sufficient to address 2 million voxels -- which in turn should be quite sufficient to cover a screen resolution of say 1920*1080 (also roughly 2 million pixels), correct? But if a node needs 8 bytes, that gives just 32KB vram usage for the node pool (excluding additional cached node pools here). That number seems low -- the octree storage numbers in section 5.3 seem higher than that, as in 1-9 MB. Surely I'm missing something, what is it? :)PShttps://www.blogger.com/profile/03992527788905662829noreply@blogger.comtag:blogger.com,1999:blog-7773532993303488759.post-71795042076701945042012-03-10T18:03:46.270+01:002012-03-10T18:03:46.270+01:00Hi Phil.
To answer your first question, many thing...Hi Phil.<br />To answer your first question, many things changed, but the main one i can give you is the fact that I am now using one border bricks (only on one side on each axis), but with node-centered values. This is sampled correctly by fetching value in a neighboring brick when the sample ends-up in a region with no border.<br /><br />For your second question, sub-nodes are arranged sequentially and that's why we only store one pointer to the 8 sub-nodes. But this is not a real pointer, this is just an offset in the linear buffer encoded in 30bits. However we do need to store this reference because the octree is sparse and updated dynamically, and thus there is no predictable way to "compute" this offset.<br /><br />Hope it helps :)Cyril Crassinhttps://www.blogger.com/profile/16474299434636795969noreply@blogger.comtag:blogger.com,1999:blog-7773532993303488759.post-47455515604015114722012-03-10T17:13:36.139+01:002012-03-10T17:13:36.139+01:00A silly n00b question -- for an N3 tree, each node...A silly n00b question -- for an N3 tree, each node has 8 childnodes and they are arranged sequentially -- why do you need to store a pointer to the sub-node at all? Would computing the "location" (index/offset really) of a node's sub-node be too expensive?PShttps://www.blogger.com/profile/03992527788905662829noreply@blogger.comtag:blogger.com,1999:blog-7773532993303488759.post-86482818563726916712012-02-14T10:41:01.890+01:002012-02-14T10:41:01.890+01:00Working through this right now (page 77!), as a vo...Working through this right now (page 77!), as a voxel newbie. Amazing work on all levels! One question -- in one sentence, since you defended this last July (6 months ago after all), has anything significantly "changed" that would affect an OpenGL implementation of your GigaVoxels pipeline? Encountered any issues since then, or keeping any errata?<br /><br />This is truly outstanding work... from the focus on identifying and building on fundamentals, to the scalability upwards and downwards, to the extensibility and integrateability with existing mesh-based data or custom procedural generation or lighting techniques of one's choosing. I'm seriously inspired and motivated to put this to work to capture and/or create more beauty out there =)PShttps://www.blogger.com/profile/03992527788905662829noreply@blogger.comtag:blogger.com,1999:blog-7773532993303488759.post-16491622067233689792012-01-30T12:56:18.200+01:002012-01-30T12:56:18.200+01:00Congrats, well done :)Congrats, well done :)Sander van Rossenhttps://www.blogger.com/profile/13955123864686957569noreply@blogger.comtag:blogger.com,1999:blog-7773532993303488759.post-90889142440268230212012-01-27T23:09:45.614+01:002012-01-27T23:09:45.614+01:00Congrats! That looks awesome.Congrats! That looks awesome.PeterKhttps://www.blogger.com/profile/08094872288100604029noreply@blogger.comtag:blogger.com,1999:blog-7773532993303488759.post-46067968540708538202012-01-27T16:58:33.426+01:002012-01-27T16:58:33.426+01:00This is excellent work. Do you plan to release any...This is excellent work. Do you plan to release any source code packages based on GigaVoxels?Thomashttps://www.blogger.com/profile/15348190820120109336noreply@blogger.comtag:blogger.com,1999:blog-7773532993303488759.post-90643058954716851682012-01-26T14:38:48.706+01:002012-01-26T14:38:48.706+01:00Congratulations Cyril, really nice work! I never t...Congratulations Cyril, really nice work! I never though about the overshading problem in the context of micro-polygons. Great summary of voxel vs. polygon rendering and of course great contribution with the Gigavoxels approach. Thanks!Klaushttps://www.blogger.com/profile/18337481710323367698noreply@blogger.com