Hello,
I have been reading the 'librt' source code.
There is some OpenCL prototype code in there for testing intersections with
ellipsoids. But this kind of architecture is not going to work performance
wise. It is allocating buffers and sending geometry data to the device (GPU
or whatever) on every single ray/primitive intersection call
(src/librt/primitives/sph/sph.c:clt_shot). I also checked the main
intersection code and it uses a function table to figure out which
ray/primitive intersection routine to call (src/librt/primitives/table.c)...
Then I did some 'wc -l' runs to see how much effort it would take to
recode parts of the pipeline:
src/librt/*.c - 33516 lines
src/librt/primitives/*.c - 4653 lines
src/librt/primitives/*/*.c - 141351 lines
= Proposed architecture
Most code is ray/primitive intersection routines. I have to read some more
to see how the librt object database is stored, updated, and accessed. But
I think the most viable architecture is probably going to be something
like... we store some accelerated primitives on the device (GPU), and
unaccelerated primitives on the host (CPU). Then when we do the ray
shooting we perform it on both databases and merge the results. In theory
the more accelerated primitives (GPU) we have the smaller the unaccelerated
primitives database (CPU) will be and the faster the ray shooting will be.
As a proof of concept we can reuse the accelerated ellipsoid intersection
code over this architecture.
= Other tasks
We need to perform some kind of analysis on which primitives people are
most likely to use and work on accelerating them. So basically we need some
statistics on a corpus of scenes i.e. how many primitives each model total
has and how many primitives of each type each scene has as a percentage.
I haven't checked if this is implemented yet but it would be nice to have
some built-in statistics like framerate or geometrical complexity that
could be displayed on user demand via the UI.
= Links
http://brlcad.sourceforge.net/doxygen/
http://svn.code.sf.net/p/brlcad/code/brlcad/trunk/src/librt/
Regards,
On Thu, Feb 19, 2015 at 7:36 AM, Christopher Sean Morrison <brl...@mac.com>
wrote:
>
> On Feb 19, 2015, at 12:14 AM, Vasco Alexandre da Silva Costa <
> vasco.co...@gmail.com> wrote:
>
> > I was reading your mailing-list archives and noticed you guys are
> interested in a real-time RT visualization mode. I am currently doing my
> PhD on that topic and it just so happens that I ended up bumping into
> BRL-CAD. I have not made a code review to see what needs to be done.
>
> Hello and welcome! Glad to see the interest. If you need help finding
> your way around the code, please don’t hesitate to ask here or on our IRC
> channel (if you’re willing to wait for a reply). The ray tracing is almost
> entirely concentrated into two directories: src/rt for the front-end ray
> dispatcher and src/librt containing the rest. Digging down into
> src/librt/primitives is where you’ll find individual entity logic (the
> familiar shot/intersection functions for example).
>
> > AFAIK BRL-CAD uses CSG. So I assume you guys use a classical RT approach
> where you have a bunch of primitive types and support complex object
> hierarchies.
>
> It’s a hybrid representation system with different intersection behavior
> based on the geometry representation type (implicit, triangle, polygonal,
> NURBS, volumetric, etc), but you basically have it right. We do support
> Boolean combinations of any solid entity type against any other. This
> involves calculating ray intersections and then “weaving” segment
> partitions together based on the CSG operations. All highly expressive
> with modern coherency and vectorization techniques, but a rather woefully
> unexplored area of research within the academic community.
>
> > Most modern real-time RT systems only support triangles as a primitive
> for code simplification and performance reasons. It is not impossible to
> support multiple primitive types but I do not know how good the performance
> would be in a system like that. Is your OpenGL backend (I'm assuming you
> have one for the modeling stage) totally different?
>
> Ever since real-time RT really hit the research scene, circa 2002-2004
> with Ingo’s thesis and Reschetov’s tracer, I’ve strongly asserted that the
> exact same techniques can apply to a primitive-based system like we have in
> BRL-CAD and that the results would be even more impressive. We’ve just not
> had anyone try. The downside is as you describe — that you have to tune a
> dispatcher, a dozen intersection algorithms, a lighting model, and a
> boolean weaver instead of just a dispatcher, one intersection routine, and
> a lighting model. This is not intractable difference though.
>
> In fact, one of the tenants of real-time is actually encouraged by using
> implicit geometry with CSG operations — data coherency. Implicit CSG
> geometry requires approximately two orders of magnitude less data to
> express the same shape compared to a roughly equivalent triangle mesh. CSG
> implicits are also, on average, spatially larger than your average triangle
> and often with fewer intersection calculations required (e.g., all the
> quadratics — cones, cylinders, ellipsoids, etc).
>
> Cumulatively, this means that not only should the same real-time
> performance improvements be realizable, but the results will likely exceed
> triangle tracing.
>
> For what it’s worth, as a mildly related aside, it’s fun to note that
> BRL-CAD’s ray tracing library is actually credited [1] as being the world’s
> *first* real time ray tracing implementation. Circa 1987, librt and our
> remrt/rtsrv tools achieved 5-10fps rendering across a network of
> ridiculously slow machines by today’s standards. :)
>
> Cheers!
> Sean
>
>
>
> [1] http://en.wikipedia.org/wiki/Ray_tracing_(graphics)#In_real_time
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
--
Vasco Alexandre da Silva Costa
PhD Student at Department of Information Systems and Computer Science
Instituto Superior Técnico/University of Lisbon, Portugal
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
