> On 20 Jun 2017, at 18:03, Christopher Sean Morrison <brl...@mac.com> wrote:
>
> Hi Marco,
>
>> So after reviewing the code with the ‘weave_segs’ kernel last thursday with
>> Vasco Costa via Skype, i made some improvements on the code and submitted
>> today an initial patch with the ‘weave_segs’ kernel and the code to weave
>> segments into partitions. (The patch can be found here
>> https://sourceforge.net/p/brlcad/patches/468/
>> <https://sourceforge.net/p/brlcad/patches/468/>).
>
>
> Outstanding. Great to see some real useful progress.
>
>> It contains a bit vector of 32 bits to represent the segments in each
>> partition and the respective assertion on the host code to ensure that there
>> aren’t more than 32 segments per ray.
>> Would appreciate some feedback on the patch.
>
>
> Where in the patch is the 32-bit limit exactly? I glanced quickly, but
> didn't see a comment. Please at least leave a comment about it even if the
> limit is type-based. Also, curious why you disabled all of the coloring code
> in rt.cl Presumably just for testing, but did something not work right?
> Also curious that your cl partition structure still contains pointers
> (instead of SoA) -- that intentional?
My bad! Should have added a comment in the first place. Will do so! Yes I
disabled the colouring code in rt.cl only for testing purpose. That code would
overwrite the white shading from boolean evaluation since it shades all
intersected segments and not only the segments from evaluated partitions. I
will have to change that code to shade only segments from evaluated
partitions. I just wanted an easier solution to test the code.
Regarding the pointers in the cl_partition structure there isn’t any good
reason to use them, and I should replace it to something like this:
struct partition {
struct seg inseg;
struct hit inhit;
struct seg outseg;
struct hit outhit;
uint segs; /* 32-bit vector to represent the segments in
the partition */
}
Thanks for pointing that out
>
>>
>> I tested the code with scenes containing union, difference and intersection
>> operations and the resulting images matched the images from the ansi c code.
>
>
> Can you report what the difference in timings is looking like for just
> segment weaving? I know your test cases were pretty simple, but curious
> where the times are at in comparison.
>
>> I will attach a diff file with the code I made to eval the partitions and to
>> shade the evaluated partitions (white/black shading). It doesn’t support CSG
>> scenes with more than 1 region yet!
>
>
> Feel free to share a picture, or include some more in your dev log. The
> picture from June 9th was cool to see. While we do eventually want the
> raytrace picture to match, it's more important to first get ray partitions
> matching. For comparing Ansi C timings, you should try using a different
> lighting model (rt -l#) that does less work, otherwise it's apples n' oranges
> different. Diffuse is -l1, surface normals is -l2, curvature is -l5. Feel
> free to add a new lighting model that does the simple while/black shading so
> you have a more exact comparison.
>
>> I will be working next on adding support to evaluate CSG scenes with more
>> than 1 region and shading the objects with the correct materials.
>
>
> Excellent. Sounds like Vasco has you right on track. Thanks for the update!
>
I followed your suggestion and added a lighting model to the ansi c code that
does the white shading :) And uploaded some more new images of the results and
also added a table with the time comparison. Running the OCL code in my CPU is
faster than running it on a Nvidia GTX 970, which isn't a great board to
perform double-precision calculations. I have included those times for
reference.
> Cheers!
> Sean
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org!
> http://sdm.link/slashdot_______________________________________________
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
> <https://lists.sourceforge.net/lists/listinfo/brlcad-devel>
Thanks for the help!
Cheers,
Marco
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
