In article <457e602e$1@news.povray.org>, chr### [at] gmxde says...
> Patrick Elliott schrieb:
> > 
> > This one does bug me a tad. If you completely redid POV-Ray to make it
 
> > an includable library, which had its "own" render window that "must" be
 
> > used as the installed component, "can't" be hidden by the developer and
 
> > which, as part of its initialization, automatically displayed a test 
> > render and a scrollable disclaimer, including a statement that this is
 
> > not an original, etc., etc., would that "cover" the requirement?
> 
> I don't really see your point here.  The POV-Ray license requires a 
> custom version to be a fully functional version of POV-Ray.  The reason
 
> for this is to prevent anyone from crippling POV-Ray to just perform a 
> certain limited task.  The user who gets a custom version of POV-Ray 
> should always be able to do everything possible with the official 
> version as well.  For the same reason the license does not allow to 
> disguise the fact that POV-Ray is used in a program system.
> 
> As far as practical problems of using POV-Ray in combination with other
 
> programs is concerned - you seem to be very focussed on the GUI versions
 
> of POV-Ray.  The license no way requires a distributed POV-Ray 
> executable to have a GUI and in the Unix frontend the GUI/render window
 
> has always been optional.
> 
Well, there was some level of confusion at one point when either I or 
someone else mentioned it. So.. If someone made an ActiveX enabled one, 
which can run stand alone or as a library, then as long as some method, 
like I mentioned, is employed to make sure people know its POV-Ray, then 
that is OK?

In other words, if it functioned exactly as it does now under Windows, 
but you could also call it with:

a = createobject("application.povray")
b = a.renderwindow
b.parent = me.frame
b.render ("myscene.pov")

Then, and this is where I am suggesting the means of compliance, you 
code the interface so that:

1. "renderwindow" cannot be resized smaller than needed to display the 
required licencing elements.

2. "renderwindow" connot be "hidden" until after those are displayed.

3. "a.render" will not operate at all, unless you have at least one 
instance of "renderwindow" in operation.

4. Possibly set of the initial license info display as something you 
have to do an "decline" or "accept" type thing on, so they have to at 
least look at it.

See, the idea is to both comply with the requirements, but also 
integrate the engine closely enough with what is going to use it that it 
is nearly invisible. Currently the only method to do that tends to be a 
tad flaky and became broken between versions. The idea is to provide an 
alternate wrapper, that provides complience, less obtrusive operation 
and better integration.

I would also, for my use, consider an additional optional "sandbox.ini" 
file, which would let you disable certain features, like radiosity, 
which might create excessive render times if used, so that, for my use, 
the engine **seems** to be limited to faster operations that allow 
closer to real time operation. I.e., scenes that take a minute or less 
to generate, not 30 minutes to 30 days, etc. However, editing the 
sandbox or even deleting it would "re-enable" anything disabled. Using 
it in "stand alone" mode would simply ignore the sandbox settings.

Point is, finding a way to comply with the requirements without breaking 
the rendering engine (and the rules) or recoding it, while "still" 
getting what you want out of it for the specific task you need it for.

The last few times anyone even suggested some sort of closer integration 
the answer wasn't, "If you make sure they know what it is and it does 
everything it normally would.", it was, "No you absolutely cannot." I 
want to know how flexible the rules really are and if you can comply, 
how ever convoluted the solution, without throwing the whole thing out 
as totally unworkable and starting from scratch. What I propose above 
would "seem" to me to make sense. I want to know if it does to the 
people that coded it.

NOTE: In case you are wondering, the idea is to, maybe, allow small 
scene files, dependent on local libraries of some pre-made stuff, to be 
sent by text based games, so that some level of 3D stills or simple 
animations would be possible. This mandates a sandbox that can 
"disable" things which, while nice for real renders, are time hogs 
otherwise. It also mandates some level of usable integration, which is 
barely possible when it works with the current method and not entirely 
practical for some uses. At the least it has serious issues with initial 
startup of the engine, which causes different problems depending on 
which starts first, as well as issues with multiple copies, either of 
the engine or of applications trying to talk to it. The existing method 
to solve it only partly addresses the issue imho, while real instancing 
of it as an object solves most of the problems, except the memory issue 
that then crops up.. But, its possible to allow one "stand alone" 
instance and one "object" instance or other permutations too, just not 
with it as it stands.

Mind you, I am buried in doing some other things at the moment, so the 
issue is mostly mute, for right now, but eventually I am going to have 
to either find out "if" the idea of viable or start trying to figure out 
how the heck to code one myself, should I start working on it again in 
the future. lol

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message