 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Often I need to center text on an object or align it in certain ways, but
it proves difficult because of the variable length in most text fonts.. a
monofont would solve my problem, but so would a way to compute the length
of a text object, which I could throw into a variable and use from there.
Is this making sense to anyone? :) Please help..
- lv
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ooops, I spoke too soon. Here is the answer for those wondering:
http://www2.fwi.com/~parkerr/traces.html
Now does anyone know if something like this will be included in future
versions of povray?
- lv
Laszlo Vecsey <mas### [at] internexus net> wrote:
> Often I need to center text on an object or align it in certain ways, but
> it proves difficult because of the variable length in most text fonts.. a
> monofont would solve my problem, but so would a way to compute the length
> of a text object, which I could throw into a variable and use from there.
> Is this making sense to anyone? :) Please help..
> - lv
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Laszlo Vecsey wrote:
>
> Ooops, I spoke too soon. Here is the answer for those wondering:
>
> http://www2.fwi.com/~parkerr/traces.html
>
> Now does anyone know if something like this will be included in future
> versions of povray?
This is a good question. http://www.twysted.net/PatchStation/ is
full of quite useful patches -- angle-dependent reflection,
spherical sweeps, slope-dependent textures, blurred reflections,
bounding boxes, text justification, isofunction objects, uv mapping....
Clearly, though, the POV team takes a conservative approach in
including these things in the core code. And with good reason --
it's very easy to whip together a patch and test it on a few
simple cases. But new features must be supported, which adds
substantially to the burden.
So I wouldn't get too hopeful. I just wish, though, they would
back off on the povlegal.doc to allow the innovation which
so enriched the selection of 3.0 options to continue with
3.1 . The current document basically makes all patches
impractical to implement legally. All that remains is the
independent development of GUI extensions.
Dan
--
http://www.flash.net/~djconnel/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi !
it's a trick but you can create a image including yor text in black over a
white background, next in pov make a heightfield, remove the base using a
cgs operation an later apply the apropiate scale and other tansformation
needed...
Sorry for my very bad english, my natural language is spanish : )
good lock
Ricardo
riperey@geocitiesDOTcom or pereyrag@imagen-netDOTcomDOTar
replace DOT for . if you want reply this.
>Often I need to center text on an object or align it in certain ways, but
>it proves difficult because of the variable length in most text fonts.. a
>monofont would solve my problem, but so would a way to compute the length
>of a text object, which I could throw into a variable and use from there.
>
>Is this making sense to anyone? :) Please help..
>
>- lv
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The keyword water_level for heigh_fields can revmove the back
ground without having to use a csg operation.
Ken
Ricardo Miguel Pereyra wrote:
> Hi !
>
> it's a trick but you can create a image including yor text in black over a
> white background, next in pov make a heightfield, remove the base using a
> cgs operation an later apply the apropiate scale and other tansformation
> needed...
>
> Sorry for my very bad english, my natural language is spanish : )
>
> good lock
>
> Ricardo
>
> riperey@geocitiesDOTcom or pereyrag@imagen-netDOTcomDOTar
>
> replace DOT for . if you want reply this.
>
> >Often I need to center text on an object or align it in certain ways, but
> >it proves difficult because of the variable length in most text fonts.. a
> >monofont would solve my problem, but so would a way to compute the length
> >of a text object, which I could throw into a variable and use from there.
> >
> >Is this making sense to anyone? :) Please help..
> >
> >- lv
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
pssst come here watch for the super patch
--
Have a good one, Maleko
_______________________________________________________
" If you wanna have fun, and don't need a reason,
all you need is a gun, it's TOURIST season!"
Bugs Bunny (modified)
>> Now does anyone know if something like this will be included in future
>> versions of povray?
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 14 Sep 1998 19:04:27 -0500, Dan Connelly <djc### [at] flashnet> wrote:
>Laszlo Vecsey wrote:
>>
>> Ooops, I spoke too soon. Here is the answer for those wondering:
>>
>> http://www2.fwi.com/~parkerr/traces.html
>>
>> Now does anyone know if something like this will be included in future
>> versions of povray?
I wrote it, and I haven't submitted it for consideration by the POV Team, so I
would say offhand that they have no idea that it even exists. But even if
they had such an idea, it has enough bugs that I wouldn't bet much on its
chances to be included. In particular, it relies on auto-bounding, so objects
that are not auto-bounded probably cause hard-to-find errors.
>This is a good question. http://www.twysted.net/PatchStation/ is
>full of quite useful patches -- angle-dependent reflection,
>spherical sweeps, slope-dependent textures, blurred reflections,
>bounding boxes, text justification, isofunction objects, uv mapping....
Many of which have been added to what I like to call the "superpatch," along
with some other patches that haven't been released anywhere yet (for examples
of what you can do with my new crackle textures, see
http://www2.fwi.com/~parkerr/crackle.html). Keep your eyes open for the
superpatch; I have about three or four more things I want to add, and I've
recently gotten some help with the documentation, so I hope to have it out
sometime soon. I also hope it won't be too hard to apply to the 3.1 source
when it is released.
>Clearly, though, the POV team takes a conservative approach in
>including these things in the core code. And with good reason --
>it's very easy to whip together a patch and test it on a few
>simple cases. But new features must be supported, which adds
>substantially to the burden.
True. I posted at length recently on this topic, but other reasons why
patches don't get included are: (1) The POV Team doesn't know about them.
(2) The authors haven't given the Team permission to use them. (3) They
aren't high enough quality or general-purpose enough to include. See my
earlier posting for some quotes from Chris Young, POV Team coordinator,
on this matter.
>So I wouldn't get too hopeful. I just wish, though, they would
>back off on the povlegal.doc to allow the innovation which
>so enriched the selection of 3.0 options to continue with
>3.1 . The current document basically makes all patches
>impractical to implement legally. All that remains is the
>independent development of GUI extensions.
Not true at all, and if I contributed to that impression, I apologize. The
current POVLegal adds only one new restriction to development, and for very
good reason. That restriction is that you can't develop new _interfaces_ to
POV. That shoots down some development projects that might be helpful to
the POV community at large, such as my plugin proposal, but it doesn't affect
anything else that I know about. And I'm still free to develop plugins; I
just can't distribute them without getting them into the official version.
At least that's how I read the rules. And this is far from a dead issue;
Chris Young has promised me that the POV Team will revive the plugin debate
after 3.1 is on the shelves. (In return, I've promised him not to rouse
the rabble about plugins, so keep those cards and letters, folks!)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> >So I wouldn't get too hopeful. I just wish, though, they would
> >back off on the povlegal.doc to allow the innovation which
> >so enriched the selection of 3.0 options to continue with
> >3.1 . The current document basically makes all patches
> >impractical to implement legally. All that remains is the
> >independent development of GUI extensions.
>
> Not true at all, and if I contributed to that impression, I apologize. The
> current POVLegal adds only one new restriction to development, and for very
> good reason. That restriction is that you can't develop new _interfaces_ to
> POV. That shoots down some development projects that might be helpful to
> the POV community at large, such as my plugin proposal, but it doesn't affect
> anything else that I know about. And I'm still free to develop plugins; I
> just can't distribute them without getting them into the official version.
> At least that's how I read the rules. And this is far from a dead issue;
> Chris Young has promised me that the POV Team will revive the plugin debate
> after 3.1 is on the shelves. (In return, I've promised him not to rouse
> the rabble about plugins, so keep those cards and letters, folks!)
From POVLEGAL.doc :
A "custom version" is defined as a fully functional version of POV-
Ray with all existing features intact. ANY OTHER USE OF ANY POV-
Ray SOURCE CODE IS EXPRESSLY PROHIBITED. The POV-Team does not
license source code for any use outside POV-Ray. No portion of the
POV-Ray source code may be incorporated into another program
unless it is clearly a custom version of POV-Ray that includes all
of the basic functions of POV-Ray.
"all the basic functions of POV-Ray"? What does that mean?
Functionality is difficult to analyze. In a strict sense,
it represents the set of outputs from a set of inputs.
Yet if this isn't changed, the patch does nothing. In a legal
sense, error function generation could be considered "functionality",
for example, so any new keywords could be violations, as they replace
these error messages with some other behavior. Or, changing the
function of any current keywords would almost certainly violate
this.
You must provide all POV-Ray support for all users who use your
custom version. You must provide information so that user may
contact you for support for your custom version. The POV-Ray Team
is not obligated to provide you or your users any technical
support.
I would prefer legal clarification of what "all POV-Ray support"
means. If it means that all support which will be provided is
provided by me, and thus if none is provided at some point that
is okay (100% of zero is zero), then I have no problem. But this
is too vague for my comfort level if I had any fear this would be
pursued.
--
http://www.flash.net/~djconnel/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 15 Sep 1998 21:38:01 -0500, Dan Connelly <djc### [at] flashnet> wrote:
>From POVLEGAL.doc :
>
> A "custom version" is defined as a fully functional version of POV-
> Ray with all existing features intact. ANY OTHER USE OF ANY POV-
> Ray SOURCE CODE IS EXPRESSLY PROHIBITED. The POV-Team does not
> license source code for any use outside POV-Ray. No portion of the
> POV-Ray source code may be incorporated into another program
> unless it is clearly a custom version of POV-Ray that includes all
> of the basic functions of POV-Ray.
>
>"all the basic functions of POV-Ray"? What does that mean?
>Functionality is difficult to analyze. In a strict sense,
>it represents the set of outputs from a set of inputs.
>Yet if this isn't changed, the patch does nothing. In a legal
>sense, error function generation could be considered "functionality",
>for example, so any new keywords could be violations, as they replace
>these error messages with some other behavior. Or, changing the
>function of any current keywords would almost certainly violate
>this.
This has been there since the beginning. "The basic functions of POV-Ray"
has always been interpreted to mean "everything the official version does"
in the sense of what language features it supports. So, it's okay to add
features, and it's okay to extend features, but it's not okay to remove
features. The goal of this paragraph is to prevent people from using the
POV code in other applications. For example, you can't yank out the parser
and use it in a conversion app, a modeling app, or a competing non-free
raytracer.
> You must provide all POV-Ray support for all users who use your
> custom version. You must provide information so that user may
> contact you for support for your custom version. The POV-Ray Team
> is not obligated to provide you or your users any technical
> support.
This has been there forever, too. The intent is to make it clear to you
that you need to make it clear to your consumers that the POV-Team doesn't
know anything about your patch or what bugs it might have introduced into
the base POV functionality, so contacting them for support is both futile
and irritating.
>I would prefer legal clarification of what "all POV-Ray support"
>means. If it means that all support which will be provided is
>provided by me, and thus if none is provided at some point that
>is okay (100% of zero is zero), then I have no problem. But this
>is too vague for my comfort level if I had any fear this would be
>pursued.
I suspect this is okay, so long as you make an attempt to provide support
to those who need it while you're still around. If at some point you
experience net-death and the custom version becomes unsupported, it probably
isn't a big deal so long as your documentation and your custom build itself
have made it sufficiently clear that the POV-Team is not responsible for
support. There are a lot of custom patches for POV 2.2 that are no longer
supported.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> There are a lot of custom patches for POV 2.2 that are no longer
> supported.
Let's sue :).
Just kidding. I really appreciate the reply.
I hate legal documents. Written English, especially in paragraph
form, is too loose to be immune from hostile interpretation.
--
http://www.flash.net/~djconnel/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
