Not really sure about passing transform all over the place is the cleanest approach.

Did you check if it's possible to use same object info as we're using for instances in render kernel?

And also not really sure. You put transform into Task, is it because you're aiming doing multiple instances in separate threads?

Did you check if it's possible to use same object info as we're using for instances in render kernel?

The multiplication bit? I will check, I'm not even sure on how to use the Transform, so any sample code will help.

And also not really sure. You put transform into Task, is it because you're aiming doing multiple instances in separate threads?

I went along with what we were doing for shader_type. I can store the orientation in the kernel globals instead.

Shader type makes sense to be stored in Task since it describes how exactly task is to be handled. using task for passing some extra data for the kernel invocation is a bad design. Using kernel globals for that is also wrong because it is supposed to be used for data which is global for the whole kernel.

I'm still not sure why you can't use __objects storage which already contains object transform.

I'm still not sure why you can't use __objects storage which already contains object transform.

I'm not familiar with this. But I can look at that once we get the patch working. Either way I hope it's clear that the transformation we need is not already in __objects since it's neither the parent object or the duplicated object matrix.

Only minor suggestions. (ontop of sergey's comments)

Replies to @Campbell Barton (campbellbarton) :

Realize its not directly related to this patch (since the triangulate modifier was used already), but think we could use tessface layout, or have a version of BKE_mesh_recalc_tessellation that outputs MPoly tri's instead of MFace's

As you mentioned, triangulated modifier was used already. I'm ok with trying this *after* dupli group is fixed. But not as part of the main/current patch.

No strong opinion. But this could just be a NULL argument. to avoid doing any transformation. (since this is such a common case)

Ok, this is addressed here:
https://developer.blender.org/D1271?vs=4559&id=4560&whitespace=ignore-most#toc

See my previous comment on that matter (re: GPU)

@Sergey Sharybin (sergey) I tried a new/clean approach yesterday, but something is not working.

Basically I'm passing the ob_dup->mat for the baking function, and using it to get the correct object_id:

	/* for duplicated objects, we get the object id by the object name and its transformation matrix */
	if(matrix)
		tfm = get_transform(*matrix);

	/* find object index. todo: is arbitrary - copied from mesh_displace.cpp */
	for(size_t i = 0; i < scene->objects.size(); i++) {
		Object *b_ob = scene->objects[i];

		if(strcmp(b_ob->name.c_str(), b_object.name().c_str()) == 0) {

			/* duplicated object of the same type but not the right copy of it */
			if(matrix && tfm != b_ob->tfm)
				continue;

			fprintf(stderr, "%s : %lu : %s\n", __func__, i, b_ob->name.c_str());

			object_index = i;
			tri_offset = b_ob->mesh->tri_offset;
			break;
		}
	}

(and add a #if 0 #endif in kernel_bake.h to remove the transformations previously added)

This part works fine, and it gives me different ids for each of the baked objects and dupli objects. The problem is, I still need to transform the position and direction in kernel for this to work correctly.

Shouldn't the above be all I need? I expected the dupli object to work just like any other object.

@Brecht Van Lommel (brecht) do you have time to take a quick look at this? Maybe some suggestions ... sergey has been quite busy lately (understandably so), and I would love to be done with this patch :)