On Mar 6, 2015, at 12:03 PM, benson chepkwony <bchepk...@att.net> wrote:

> Since this subject talks about "Performance" I was going to ask:
> 1. First do you have/carry BrlCad with Manual Guide or a Guide book?

Unclear question… try these:

http://en.flossmanuals.net/contributors-guide-to-brl-cad/
Also, our HACKING file in our source tree should be consulted along with 
README’s throughout the source tree.

If you mean for users, there is extensive documentation that can be found 
online and in any install.

Also, we say BRL-CAD, not BrlCad.

> 2. Is the main ray tracing written from OpenCL library/code?

I don’t understand your question.  If you’re asking whether our current 
production implementation is using OpenCL, then no.  There is experimental 
OpenCL code for exactly one entity type — ellipsoids — in a branch.

> And does this affects the following files:
> src/other/opennurbs
> src/librt/primitives/brep
> src/librt/opennurbs_ext.*
> src/proc-db/csgbrep.cpp
> src/proc-db/brep*

Does it currently, no.  Will it if/when someone implements an OpenCL pipeline, 
probably.

> 3. Can we Modify/Edit these libraries such as: OpenCL, Opennurbs and Rhino3D 
> folks or should we write a ray tracer from scratch, let say if we need to 
> optimize it?

We do not want a ray tracer written from scratch.  We have considerable ray 
tracing infrastructure already in place.  We want to enhance our existing librt 
ray tracing library with a coherent high-performance pipeline leveraging OpenCL 
where it can help.

> 4. Is NURBS used to find ray intersection on objects? and what about OpenCL 
> Code does it also do the same thing as NURBS? which one is better?

NURBS is a boundary representation format for geometry, not a ray tracing 
method.  We do implement NURBS geometry ray tracing, but not using a 
high-performance data-coherent method.

> I am interested in working on the "NURBS Optimization and Cleanup" and I 
> would like to optimize its algorithm as this often plays a pivotal role in 
> improving performance. This is just one classic place to optimize.
> To optimize ray tracer, I am planning on conducting a couple of these steps:
>       1. Implementing Kd-tree structure.
>       2. Implementing Bezier clipping method for NURBS Surface
>       3. Implementing BVH Ray traversal
>       4. Implementing Bounding Volume Hierarchy
>       5. Fine-tuning a NURBS-curve by specifying different weight
>           with knot-vector

It’s pretty much impossible to do all of these steps during GSoC and it’s 
unclear to me how some of these are different from what we already do.  

> Bounding Volume Hierarchy:
> In order to reduce intersection cost, a bounding volume should be drawn 
> around each polygon.

This indicates a lack of understanding of the problem domain.  There are no 
polygons with NURBS.  Moreover, we already have a BVH, so how is what you’re 
proposing going to be different?

> You also mentioned that:
> "The way ray tracing currently occurs, there’s even room to speed up 
> primitives on the host (CPU) by an order of magnitude or better ensuring 
> better data coherency and eliminating branch logic."
> Because you mentioned it, I would like to look further in this area.

A proposal should focus on one specific area of work.  Proposing more than is 
actually achievable will not increase chances of selection.  You’ve mentioned 
maybe a half-dozen potential GSoC topics already like NURBS-optimized KD-tree, 
OpenCL ray pipeline, OpenCL NURBS ray intersection, optimizing NURBS ray 
tracing, coherent ray tracing optimization, … Any of those could be focused on 
for a project.

These are all very complicated and hard topics.  I would suggest focusing on 
topics you believe you understand the most or have the most experience with 
already.  Remember that you’ll also have to spend considerable time 
understanding BRL-CAD’s code and validating implementation on top of 
understanding your own project goals.   

Cheers!
Sean

------------------------------------------------------------------------------
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

Reply via email to