On Thu, Mar 17, 2016 at 7:54 PM, Vasco Alexandre da Silva Costa <
vasco.co...@gmail.com> wrote:
> On Thu, Mar 17, 2016 at 7:47 PM, Christopher Sean Morrison <brl...@mac.com
> > wrote:
>
>>
>>
>> On Mar 17, 2016, at 05:33 AM, Param Hanji <param.catchch...@gmail.com>
>> wrote:
>>
>> Great. I'm happy to help!
>> Also is ehy running fine in OpenCL mode? My generated PNG is just a blank
>> black screen with no figure. The terminal logs don't seem to indicate
>> anything wrong. Maybe ehy_shot.cl has a bug?
>>
>>
>> 1) Does that exact same ehy render correctly in non-OpenCL mode?
>> 2) Does another primitive (e.g., an ell via mged> make ell ell) render
>> correctly in OpenCL mode
>>
>
> The problem is the material lighting code. The results are not the same.
> In OpenCL mode it renders that ehy in a really dark color and you nearly
> miss it. If you render the ehy in surface normals lighting mode (i.e. rt
> -z1 -l2) the output is as expected here.
>
The problem was more complicated that I thought. It turns out the OpenCL
code was calling the ehy normal computation routine more than once. It
turns out that routine (ehy_norm) both depends on hit_vpriv to compute the
proper normal, and clobbers hit_vpriv after normal computation to store
some temporary value for later computation of curvatures.
It just so happens that this only happened in the Full lighting mode.
I put a fix for this on SVN trunk.
--
Vasco Alexandre da Silva Costa
PhD in Computer Engineering (Computer Graphics)
Instituto Superior Técnico/University of Lisbon, Portugal
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
_______________________________________________
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
