Re: [Aqsis-development] Proposal: Aqsis as a micropolygon pathtracer
Brought to you by:
ltatkinson,
pgregory
Menu
▾
▴
Re: [Aqsis-development] Proposal: Aqsis as a micropolygon pathtracer
|
From: Nathan V. <ce...@ce...> - 2012-01-31 03:14:47
|
That is a valid point. If we do decide to focus on this alternative, non-renderman-compliant architecture, perhaps we should re-brand? Aqsis is so heavily identified as "Open Source Renderman" already. If we do rebrand, to what extent should we do so? Should a new renderer still be under the Aqsis umbrella, but with a different sub-project name? Or should it make a complete break with Aqsis branding altogether? --Nathan On Mon, Jan 30, 2012 at 2:21 PM, Josh Stratton <str...@gm...> wrote: > Just out of curiosity, at what point would overhauling aqsis no longer > make sense keeping the aqsis name? If aqsis is associated with REYES > rendering, if the removal of REYES rendering for primary visibility > and switch to OSL--may both be great ideas, what are the motivations > to keep the aqsis name as opposed to starting a new project? This > proposal seems to be a fundamental change in aqsis even if any code is > shared in the new renderer like caches or texture lookups. > > On Sun, Jan 29, 2012 at 12:38 PM, Nathan Vegdahl <ce...@ce...> wrote: >> I agree with all of your points, Chris. :-) More below. >> >>> It's impressive that they only >>> need to redice a few times for GI, even without a cache. >> >> Indeed! And this would be useful as well for handling large data sets >> that are difficult to reduce (e.g. dense hair/foliage/etc.). >> >> Moreover, there's nothing that says we can't implement a cache on top >> of this, to further improve performance. >> >>> * They ray trace against bounding boxes of micropolygons in the >>> hierarchy rather than the micropolys themselves. >> >> Yeah, it's an interesting approach, but IMO we shouldn't imitate it. >> Not just because of possible intersection issues, but also because it >> would reduce the quality of edge antialiasing for similar dicing >> rates. >> >>> * Their dicing strategy seems a bit rough. First, the heuristic for >>> choosing the dice size doesn't look very robust. >> >> Yeah, IMO it's better to stick with ray differentials for determining >> dicing rates. >> >>> * Crack avoidance is implemented by expanding the micropoly bounding >>> boxes to include the exact "underlying" surface after displacement. >>> This is very interesting, but it seems like it would be a lot of work >>> to implement as a general strategy applicable in a shading language. >> >> Yeah, I was thinking the same thing. If we're going with OSL, it >> would then have to support such things. >> >>> (perhaps heuristic bounds would be >>> sufficient?) >> >> That's what I'm wondering, too. We could, for example, line the edges >> of grids with something like this: >> http://wscg.zcu.cz/wscg2002/Papers_2002/A83.pdf >> >> And then determine the widths with a heuristic. We'd need some way to >> avoid false double-intersections, though. >> >> I've also been thinking that if we dice edges at a separate rate from >> the inside of the grid, it might make grid cracking a more tractable >> problem? >> >> Another observation is that once grids are stitched, they only need to >> be re-stitched if one of them changes resolution, which only happens >> occasionally (if it happens frequently, that means the cache is >> thrashing anyway). >> >> So maybe if we dice edges separately from the inside of the grids, >> then when a ray needs to be tested against a grid, only the abutting >> _edges_ of its neighboring grids have to also be diced, and stitching >> is done based on that? Then full grids are only diced in the event >> that they themselves need to be tested against. >> >> Of course, we could still potentially run into cases in the parallel >> case where a neighboring grid gets re-diced and thus re-stitched due >> to a second parallel-processed ray, resulting in apparent grid-cracks. >> But perhaps that can be addressed with locking of neighboring grids >> when doing intersection tests. Hopefully that wouldn't result in too >> much contention. >> >>> * Their method appears to efficiently support a lot of production goals >>> which are difficult for raytracing, eg, displacements, procedural >>> geometry and motion blur. In principle it's not a toy! >> >> Indeed! Although I'll note that based on my experience with >> psychopath, motion blur is actually pretty trivial in ray tracing, at >> least when using BVH's. But displacements and procedural geometry, >> yes. >> >> I'm getting pretty excited about this. Ha ha. :-) >> >> Anyway, I'll add the two-stage tracing to my to-do for psychopath. >> Seems like it will have a lot of benefits. >> >> --Nathan >> >> >> On Sun, Jan 29, 2012 at 6:28 AM, Chris Foster <chr...@gm...> wrote: >>> On Fri, Jan 27, 2012 at 5:33 PM, Nathan Vegdahl <ce...@ce...> wrote: >>>> On Thu, Jan 26, 2012 at 11:12 PM, Nathan Vegdahl <ce...@ce...> wrote: >>>>> Oh, also just noticed that that paper has a really interesting/unique >>>>> solution to grid cracking. Not sure how relevant it is to us, but >>>>> could spawn some ideas in any case. Here's the link again: >>>>> >>>>> http://www.uni-ulm.de/fileadmin/website_uni_ulm/iui.inst.100/institut/CG_Images/project_images/rayes/rayes.pdf >>> >>> Haha, I like the name - "rayes" - though it's liable to cause some >>> confusion I think :) >>> >>> I read this paper, it's certainly quite interesting. In many ways it >>> does resemble reyes: the focus is on generating surface geometry, using >>> it once and discarding it immediately. It's impressive that they only >>> need to redice a few times for GI, even without a cache. >>> >>> Another thing I like about this approach is that it's inherently data >>> parallel, and I suspect it would fit reasonably well onto current GPU >>> architectures. What's more, I think it's likely that the expensive >>> dicing, shading, and ray intersection in the bottom-level hierarchies >>> could be handled on the GPU without having to rewrite the rest of the >>> code. This could be a big deal since HPC seems to be going in the >>> direction of increasingly data-parallel architectures. >>> >>> >>> More observations: >>> >>> * The algorithm needs the split tree to fit in memory. I think it may >>> not be too hard to avoid this problem if necessary. >>> >>> * They ray trace against bounding boxes of micropolygons in the >>> hierarchy rather than the micropolys themselves. They cite some other >>> paper (Ref. DK06) which I need to read regarding this, but I can see >>> it causing self-intersection problems in addition to those which are >>> partially worked around in the paper. >>> >>> * Crack avoidance is implemented by expanding the micropoly bounding >>> boxes to include the exact "underlying" surface after displacement. >>> This is very interesting, but it seems like it would be a lot of work >>> to implement as a general strategy applicable in a shading language. >>> In particular, the displacement needs to be evaluated using interval >>> arithmetic to get rigorous bounds (perhaps heuristic bounds would be >>> sufficient?) >>> >>> * Their dicing strategy seems a bit rough. First, the heuristic for >>> choosing the dice size doesn't look very robust. Second, their grids >>> can be rather large and are restricted to powers of two in size. To >>> me, this suggests they might get over/under tessellation problems. >>> Perhaps that's the price you pay for simple data parallelism, but I >>> wonder whether a more complicated dicing strategy could >>> >>> * Their method appears to efficiently support a lot of production goals >>> which are difficult for raytracing, eg, displacements, procedural >>> geometry and motion blur. In principle it's not a toy! >>> >>> >>> In all, it would be very interesting to prototype some of this stuff and >>> see whether it lives up to expectations. To me, the general feel of >>> the approach is quite interesting because I can imagine it scaling to >>> massively parallel systems. The same can't be said for a lot of >>> existing algorithms and I worry that if we choose one of those >>> approaches it won't be able to keep up with growing parallelism in a few >>> years... >>> >>> ~Chris >>> >>> ------------------------------------------------------------------------------ >>> Try before you buy = See our experts in action! >>> The most comprehensive online learning library for Microsoft developers >>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, >>> Metro Style Apps, more. Free future releases when you subscribe now! >>> http://p.sf.net/sfu/learndevnow-dev2 >>> _______________________________________________ >>> Aqsis-development mailing list >>> Aqs...@li... >>> https://lists.sourceforge.net/lists/listinfo/aqsis-development >> >> ------------------------------------------------------------------------------ >> Try before you buy = See our experts in action! >> The most comprehensive online learning library for Microsoft developers >> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, >> Metro Style Apps, more. Free future releases when you subscribe now! >> http://p.sf.net/sfu/learndevnow-dev2 >> _______________________________________________ >> Aqsis-development mailing list >> Aqs...@li... >> https://lists.sourceforge.net/lists/listinfo/aqsis-development > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > Aqsis-development mailing list > Aqs...@li... > https://lists.sourceforge.net/lists/listinfo/aqsis-development |