Lighting pipeline choices - Revision history

Bassam at 16:21, 24 August 2011

2011-08-24T16:21:25Z

Bassam: moved Lighting pipeline to Lighting pipeline choices: shouldn't be the main lighting page

2011-08-24T15:33:12Z

moved Lighting pipeline to Lighting pipeline choices: shouldn't be the main lighting page

Bassam at 02:22, 17 August 2011

2011-08-17T02:22:32Z

Bassam: /* Lighting pipeline choices */

2011-08-17T02:16:33Z

Lighting pipeline choices

Bassam at 02:09, 17 August 2011

2011-08-17T02:09:22Z

Bassam: Created page with " == Lighting pipeline choices == If we have to start from before anim is locked down, we should be able to work in seperate files to enable a flexible pipelinish workflow. I've l..."

2011-08-17T02:07:53Z

Created page with " == Lighting pipeline choices == If we have to start from before anim is locked down, we should be able to work in seperate files to enable a flexible pipelinish workflow. I've l..."

New page

== Lighting pipeline choices ==
If we have to start from before anim is locked down, we should be able to work in seperate files to enable a flexible pipelinish workflow. I've looked at the following:

1- linking anim scenes into lighting/comp scenes via background scenes:
-pros:
*immune to addtions/changes in anims.
*clean (one link)
*allows full flexibility of animators while lighters are working.

-cons:
*you get everything in the scene linked
*animators can mess up lighters
*lighters can't do anything to non-animated assets, except turn layers on or off.
*doesn't handle cameras.

2- linking animated assets into light scenes as groups.
-pros:
*immune to most changes in anim, provided new dependencies are added to the group.
*clean: one link per group
*flexible: allows linking different sets of animated 'stuff' as different groups.
*lighters can change layers for animated stuff, and have full control over non animated assets.

-cons:
*blender has a showstopper bug where the proxy animation doesn't come through in the link
*non animated stuff/rest of scene has to be rebuilt by hand/ some other method.
*again, doesn't handle cameras.
*animators need to add new objects involved in the animation into the group by hand.

← Older revision		Revision as of 16:21, 24 August 2011
Line 1:		Line 1:
−	~~== Lighting pipeline choices ==~~	+
	If we have to start from before anim is locked down, we should be able to work in seperate files to enable a flexible pipelinish workflow. I've looked at the following:		If we have to start from before anim is locked down, we should be able to work in seperate files to enable a flexible pipelinish workflow. I've looked at the following:

← Older revision		Revision as of 02:22, 17 August 2011
Line 50:		Line 50:
	*If new objects are added into the anim, they will likely need to be linked in manually (needs checking). At any rate, safer to start this fairly late in the anim process.		*If new objects are added into the anim, they will likely need to be linked in manually (needs checking). At any rate, safer to start this fairly late in the anim process.
	*(related) Animators can accidentally sabotage lighters by doing invasive things.		*(related) Animators can accidentally sabotage lighters by doing invasive things.
		+
		+	===5- Linking light rigs into anim scenes. ===
		+	====-pros====
		+	*works well. No bugs that I can see.
		+	*automated approach. lighting is based on light rigs or light tables, more like rigging.
		+
		+	====-cons====
		+	*reverses pipeline. anim produces assets to light and render, not the other way around.
		+	*lights/light rigs in anim files.
		+	*not easy to iterate while anim is not finished.
		+	*not really suitable for per shot lighting.
		+
		+
		+	== Our choice ==
		+
		+	We will go with number 4, linking all objects from anim into light files. conventions:
		+
		+	ansnn.blend is an anim file
		+	ansnnlight.blend is light/comp file that references the anim file.
		+	ansnncomp.blend is a comp file that pulls off rendered frames (doesn't link 3D data) and may or may not exist.
		+
		+	we can establish a library of lights under lib/lights/ to reuse for some shots (append or link) and a similar library of node groups under lib/nodegroups/ for compo.

← Older revision		Revision as of 02:16, 17 August 2011
Line 26:		Line 26:
	*again, doesn't handle cameras.		*again, doesn't handle cameras.
	*animators need to add new objects involved in the animation into the group by hand.		*animators need to add new objects involved in the animation into the group by hand.
		+
		+	===3- Linking animated objects into light scenes as objects. ===
		+	====-pros====
		+	*extremely flexible: linked objects gives great choice over what is linked and what not.
		+	*lighters can change layers on an object per object basis.
		+	*works well. No bugs that I can see.
		+
		+	====-cons====
		+	*If new objects are added into the anim, they will likely need to be linked in manually (needs checking). At any rate, safer to start this fairly late in the anim process.
		+	*doesn't handle cameras.
		+	*rest of scene needs building in another way.
		+	*complex: to start a lighting file, you have a lot of steps, some of which are hazily defined.
		+
		+	===4- Linking all objects into light scenes as objects. ===
		+	====-pros====
		+	*extremely flexible: linked objects gives great choice over what is linked and what not.
		+	*lighters can change layers on an object per object basis.
		+	*works well. No bugs that I can see.
		+	quick easy setup of lighting file. new scene, use project settings for render, save as as**.blend, then link in everything. Can even be scripted as "make_light_comp_file" or so.
		+	*Lighters can make various objects local if they need to, on an object by object basis. This needs some care for depgraph stuff e.g. for parents or constraint targets.
		+
		+	====-cons====
		+	*If new objects are added into the anim, they will likely need to be linked in manually (needs checking). At any rate, safer to start this fairly late in the anim process.
		+	*(related) Animators can accidentally sabotage lighters by doing invasive things.

@@ Line 1: / Line 1: @@
 == Lighting pipeline choices ==
 If we have to start from before anim is locked down, we should be able to work in seperate files to enable a flexible pipelinish workflow. I've looked at the following:
-- linking anim scenes into lighting/comp scenes via background scenes:
+=== 1- linking anim scenes into lighting/comp scenes via background scenes: ===
--pros:
+====-pros:====
 *immune to addtions/changes in anims.
 *clean (one link)
 *allows full flexibility of animators while lighters are working.
--cons:
+====-cons:====
 *you get everything in the scene linked
 *animators can mess up lighters
@@ Line 15: / Line 14: @@
 *doesn't handle cameras.
-- linking animated assets into light scenes as groups.
+===2- linking animated assets into light scenes as groups.===
--pros:
+====-pros:====
 *immune to most changes in anim, provided new dependencies are added to the group.
 *clean: one link per group
@@ Line 22: / Line 21: @@
 *lighters can change layers for animated stuff, and have full control over non animated assets.
--cons:
+====-cons:====
 *blender has a showstopper bug where the proxy animation doesn't come through in the link
 *non animated stuff/rest of scene has to be rebuilt by hand/ some other method.
 *again, doesn't handle cameras.
 *animators need to add new objects involved in the animation into the group by hand.