> On 27 Jul 2017, at 00:25, Vasco Alexandre da Silva Costa
> <vasco.co...@gmail.com> wrote:
>
> Marco,
> I have seen your July 26th update. Great work! The normals look fine now!
>
> As for the material colors we need to adjust the material's region code to
> make it more in line with the way that regions are stored now with CSG
> implemented. Places that need to be checked include 'rt.cl
> <http://rt.cl/>':struct region vs 'common.cl <http://common.cl/>':struct
> bool_region. This needs changes. Also check the phong/plastic shader at rt.cl
> <http://rt.cl/> vs ANSI C liboptical.
>
> As for the differences in look with the actual shading per se, ANSI C vs
> OpenCL, at a glance this seem to be due to: different light parameters
> (position and maybe color), different Phong specular/shine color and maybe
> intensity.
>
> For more context:
> https://en.wikipedia.org/wiki/Phong_reflection_model
> <https://en.wikipedia.org/wiki/Phong_reflection_model>
>
> I would say that besides the performance improvements and code cleanups
> getting the correct material is the next most important aspect, but getting
> the exact same shader render output can be left for later as this probably
> requires a careful look at liboptical. What is important is that the
> intersections, normals, and hit primitives are 100% correct, as this impacts
> the rest of the code.
>
Yes, there seems to exist a slightly difference in the light position and with
the specular color, when comparing with the ANSI C results. But fixing the
problem with the materials should be a priority. I’ve tried some things, like
translating the regions as I did for the boolean trees, but that didn’t fix it.
I will keep looking for a possible solution for this.
Regards,
Marco
>
> On Wed, Jul 26, 2017 at 2:43 PM, Vasco Alexandre da Silva Costa
> <vasco.co...@gmail.com <mailto:vasco.co...@gmail.com>> wrote:
> On Wed, Jul 26, 2017 at 12:21 PM, Marco Domingues <marcodomingue...@gmail.com
> <mailto:marcodomingue...@gmail.com>> wrote:
>
> Hm I guess one alternative would be to have a buffer for the output queue (a
> buffer of cl_uints with the indexes of the partitions evaluated) but unless
> we run the rt_boolfinal kernel 2 times (1st to count the number of partitions
> evaluated and 2nd to store the partitions evaluated) I don’t see how it would
> skip invalid partitions. We would have to test the output queue buffer
> against UINT_MAX in the shading process, which would be similar to the
> ‘pp->evaluated’ test I do. Maybe I am missing something?
>
> There is another way. You simply store another 'pointer' in struct partition
> that points to the next valid partition.
>
> --
> Vasco Alexandre da Silva Costa
> PhD in Computer Engineering (Computer Graphics)
> Instituto Superior Técnico/University of Lisbon, Portugal
>
>
>
> --
> Vasco Alexandre da Silva Costa
> PhD in Computer Engineering (Computer Graphics)
> Instituto Superior Técnico/University of Lisbon, Portugal
> ------------------------------------------------------------------------------
> 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
------------------------------------------------------------------------------
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
