[Bf-codereview] Multi File Output Node (issue 5666047)

[lukas.toenne at googlemail.com]

On 2012/02/22 12:55:35, brechtvl wrote:
> You committed this now, but I still do not agree with the design
decisions.

Sorry, maybe that was a bit rushed :/

> File format per socket still seems overkill to me, I'd like to
understand the
> rationale for that. Of course it's most flexible and that is what
users will
> request, but I think they will regret it when they created dozes of
sockets and
> then have to go change all of them.

Main reason for this node was the ability to have a single base path
(that was Francesco's request anyway). If all sockets on a node _have_
to use the same format you would need a second, third, etc. node again
to occasionally store to different formats, and in turn have to deal
with changing paths. I cannot really say how important each of these
issues is in comparison. Would it be enough to use a per-node format
setting by default (instead of global render format), but keep the
optional per-socket format?

> I also still do not think it's a good idea to make this a new node
type. My
> point was that a single node type could do everything.

Fair enough, we can replace the old file output implementation with this
one. Would require a bit of do_versions and deprecate the new node type
again, but i don't mind.

> I also do not think that the sockets really should be color sockets,
exactly
> because it should be possible to save out colors/vectors/floats. For
EXR, you
> want to be able to output them as such, not all as color.

Ok, have been thinking about this a bit, but i still think we should not
add a new socket type for this purpose. The idea is that the sock->type
(i.e. data type) defines what kind of a data a socket accepts/generates.
The struct_type OTOH defines the RNA subclass, what additional info the
socket stores (sock->storage). We don't have multiple inheritance in
RNA, so the data subclass should be defined on top of the struct type. A
cleaner approach would be to define the input data as a separate pointer
property instead, though this is a more radical change of the API and
will likely break lots of scripts.

I would suggest that instead of making a new socket type, the file node
inputs change their type (sock->type) automatically according to what is
connected to them. This data type is what is then actually written into
the file. Might also allow users to set and explicit data type or make
this dependent on the selected file format. The sock->struct_type stays
the same all the time, only the data type changes. This is an additional
feature though (old output node doesn't support this either). This would
be very similar to the group interface output nodes i made recently:

http://www.youtube.com/watch?v=Jk_Kk5yOYvA#t=408

http://codereview.appspot.com/5666047/