[Bf-cycles] 2 questions and progress report on Cycles baking

Dalai Felinto dfelinto at gmail.com
Thu Jan 16 17:33:43 CET 2014


> Why did you do this, what problem does it solve? It doesn't seem like
a good idea to mix these things.

Simply put it was as a test/prototype to see if we could consider this

I was familiar with this part of the code (camera, projection, ...) and
thought (correctly so) that it would be straightforward to do. It does work
by the way, even if it's not an optimal design. This has the advantage of
adding little extra code to Cycles, since it benefits from the entire
rendering pipeline. I assumed I could access the final renderresult inside
Cycles though. Anyways.

I may write the barycentric to local function just to have results I could
use to test again the real implementation. But I'll look shortly at
"creating a dedicates kernel function for baking".

I won't be on irc today, but if you can be on tomorrow I'm sure I could use
a hand on using/creating a kernel function for that.

On Jan 16, 2014 12:40 PM, "Brecht Van Lommel" <brechtvanlommel at pandora.be>

> Hi,
> On Thu, Jan 16, 2014 at 1:04 AM, Dalai Felinto <dfelinto at gmail.com> wrote:
> > 1) How to convert UV Barycentric to world coordinates?
> > uv_barycentric_to_world() in blender_camera.cpp
> >
> > I assume Cycles may already have something for that?
> > If not, could you land me a hand on this?
> There isn't really a function for this outside the kernel, but why do
> you need this here? You should pass the UV coordinates to the kernel,
> and in the kernel it can then map them to world coordinate on the
> surface of the mesh. If you look at kernel_displace.h, there it calls
> shader_setup_from_displace with UV coordinates, and then ShaderData.P
> will be the world space position.
> > 2) How to access engine.re->result from Cycles?
> > (I need that for the populate_bake_result() in blender_session.cpp )
> > This I should be able to find by myself later, but I thought I may as
> > well ask ;)
> Not sure what you need this for, but the typical way is to call
> b_engine.begin_result() and then it gives you a temporary RenderResult
> for the tile, which will be merged back into the main one which is not
> directly accessed.
> For baking you shouldn't need access to a RenderResult, it shouldn't
> exist then as far as I know?
> > 4) Some Notes:
> >
> > I decided to use the render structure for the baking (instead of
> > mimicking the importance sampling code). For that I created a new
> > internal camera type (BAKE) and I feed the camera with a few lookup
> > tables for the position and direction of the rays.
> Why did you do this, what problem does it solve? It doesn't seem like
> a good idea to mix these things. You could prototype the code like
> this, but it shouldn't be difficult to create a dedicated kernel
> function for baking.
> Brecht.
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20140116/8677fb98/attachment.htm 

More information about the Bf-cycles mailing list