[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GPL on rendered images

On Wed, Dec 15, 2004 at 01:09:25AM +0100, Ingo Ruhnke wrote:
> The case is different here, as with most games, the 3d models are
> created by a artists who then sends the rendered images over to some
> programmer/maintainer who integrates them into the game, the
> programmer/maintainer almost never touches the original 3d models or
> even the 2d images, since all that is needed for the game are the
> rendered 2d images. Beside from that, the programmer/maintainer may
> lack the tools and knowledge to make any use of the 3d models, thats
> why in most cases there is little care taken to archive them. In
> general artwork is very seldomly touched by other people than the
> original creator and even by them seldomly if at all once it is good
> enough to be used in a game, thats why seldomly care is taken to
> archive the intermediate steps.

Which kinda sucks, but ...

Let's say that you could find a programmer who was good at dealing with
3d imagery.  This programmer could, in principle, take those 2d views
and "factor" them into a 3d model and some textures.  The procedure I'm
envisioning would be somewhat analogous to curve fitting.

Probably, this programmer would start with a basically similar 3d model,
and iterate until the derived model + derived textures could project
into the same sprites.

And, at that point, you'd have something where you could [in principle]
replace the textures with something better, and replace the 3d model
with something better.  [And you'd probably want to put some work into
them because a purely mechanical translation probably wouldn't look
particularly great for angles other than those that match the previously
rendered images.]

This would take a fair bit of skill, and these are to some degree
hypothetical, but conceptually it's doable.

For the most part, though, none of this is a GPL issue -- the GPL tries
to make sure that you have the freedom to do this kind of thing, but it
doesn't concern itself with the details of the manipulations that people
engage in.

Drawing an analogy to regular programs, I'd be talking about the
underlying math behind a program, and possibly about things that could
be patented -- conceptual things that go into the writing of a program.

[Now... if there wasn't an artist involved -- if those 3d models were
a viable part of the game, and the rendered images were an efficiency
tradeoff, then the source/object analogy might make sense.]

Flipping back into the realm of 3d models...  Imagine taking motion
capture information using that to calibrate a physics ragdoll model that
ultimately allows more flexibility than simply playing back the motion
capture animation with different starting positions and directions.
If there were some kind of GPL requirement for strict "no information
loss in manipulating data" then the GPL would forbid distribution of
those hypothetical ragdoll parameters because the raw motion capture
would be the "preferred form" for that information.  I just don't think
that the GPL tries to limit freedom in this way.

> The artist itself will however without a doubt cared about the 3d
> models, but since there weren't usefull to run the game, they weren't
> included in the main source tree. Since in this case the game was
> first planed to being developed commercially and the development team
> as split-up long time ago the original files are now lost and all that
> is left are the images and datafiles that are needed to run the game +
> the actually C++ source code.

Yep, but the artist isn't anything like a c compiler.

The rendered images produced by the artist are, typically, independent

If there was a copyright on the 3dmodel, and that copyright was extended
to the rendered images, then you'd have good grounds for treating them
as alternate forms of the same program.  But I don't think that's been
the case for the examples you've presented so far.

> > Right now, you're just talking about different editor formats.
> > ("layers" vs. "flat image" is roughly equivalent to the distinction
> > between a word processor format and a text editor format -- the
> > source is the source in both formats. 3d models vs. sprites, without
> > a robust and standardized environment to do the rendering, is like
> > the distinction between manual pages and source code.)
> Am I understanding you correctly that since there currently isn't a
> standard form of source for different kinds of media it is safe to
> assume that the media itself is to be considered the source as long as
> it provides a minimum form of editablity (ie. flat png is ok, even so
> a multilayered might be more usefull for editing purpose)?

I think that's oversimplified -- I can imagine cases which could be
described by this same outline where the decision would go the opposite

But where the rendered image is not treated in some copyright license
as a translation of the 3d model, and where there's some human who did
some significant work to render that image, I think it's safe to treat
the image as a work independent from the 3d model.

And, once again, I think that if the 3d modeling environment were more
"turing complete" that it would make a lot more sense to treat the
original model as a program and the rendered images (or whatever) as
executable forms of that program.

> > I'm not saying that the cases you're talking about are never going
> > to be significant, but right now they all seem fairly trivial.
> Practically its indeed today not much of an issue, since artwork/media
> in general is seldomly 'forked'. However I am pretty unsure on what I
> have to actually distribute with my games source, if the game as a
> whole is released under the GPL.

In the long run, I think projects which include good models, and use
good tools to render them, and so on will be superior to projects which
toss the models once they've gotten some adequate set of rendered images.
But I think you can do both kinds of projects legally -- even with the GPL
-- at least in the context of today's rather labor intensive techniques
for creating rendered images.


Reply to: