 |
|
|
|
|
|
| |
| |
|
|
From: Thorsten Froehlich
Subject: Re: Some ideas about SDL enhancements
Date: 6 Apr 2003 13:13:41
Message: <3e906045@news.povray.org>
|
|
|
| |
| |
|
|
In article <cja### [at] netplex aussieorg> ,
Christopher James Huff <cja### [at] earthlinknet> wrote:
> Anyway, what exactly is your objection? The string group IDs?
Yes. Remember light groups? They implemented something similar alien to
the language.
> Or is your complaint with the group idea itself? It was suggested as an
> improvement to the "object ID" idea, and seems much better to me. Got a
> better idea?
Sure, but you would need to extend several parts of the language to do it
properly ... there are simply things you cannot do without ugly hacks in the
3.x implementation of POV-Ray. This is one of them. And rather than a
hack, not doing it is the responsible choice.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3e906045@news.povray.org>,
"Thorsten Froehlich" <tho### [at] trfde> wrote:
> Yes. Remember light groups? They implemented something similar alien to
> the language.
I vaguely remember. I haven't done much with either version of that
patch, but I recall the original one using string labels, and the new
one didn't, which I considered an improvement.
> Sure, but you would need to extend several parts of the language to do it
> properly ... there are simply things you cannot do without ugly hacks in the
> 3.x implementation of POV-Ray. This is one of them. And rather than a
> hack, not doing it is the responsible choice.
Out of curiousity, what hacks are you thinking of? I can't think of any
difficulties offhand, but I haven't tried to actually implement it.
One thing that might be worth considering is a standardized grouping
syntax, something that can be used for light groups, post process
filters, and anything else that could benefit. Is this the type of thing
you're talking about?
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 31 Mar 2003 19:44:23 -0500, Christopher James Huff quoth:
> In article <3e889ec9@news.povray.org>, Warp <war### [at] tagpovrayorg> wrote:
>> * Array operators for the string type.
>
> And splines. Unify splines with the ones used by shapes like lathe and
> prism too.
This is on my personal to-do list. Maybe one of these days I'll actually
get around to it.
--
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 08 Apr 2003 03:27:26 -0400, Mark Wagner <mar### [at] gtenet> wrote:
> > And splines. Unify splines with the ones used by shapes like lathe and
> > prism too.
>
> This is on my personal to-do list. Maybe one of these days I'll actually
> get around to it.
Have you some universal solution in mind or each new type will require set of
methods? Will be new spline types handled (magicaly) automatically? I made new
sor_spline available and I'm working on some other spline types.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ABX <abx### [at] abxartpl> wrote:
> Have you some universal solution in mind or each new type will require set of
> methods? Will be new spline types handled (magicaly) automatically? I made new
> sor_spline available and I'm working on some other spline types.
I suppose that the only solution for now is to allow only compatible
splines to be used in sors and lathes (and an error message would be issued
if an incompatible type is used).
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 08 Apr 2003 06:59:13 -0400, ABX quoth:
> On Tue, 08 Apr 2003 03:27:26 -0400, Mark Wagner <mar### [at] gtenet>
> wrote:
>> > And splines. Unify splines with the ones used by shapes like lathe
>> > and prism too.
>>
>> This is on my personal to-do list. Maybe one of these days I'll
>> actually get around to it.
>
> Have you some universal solution in mind or each new type will require
> set of methods? Will be new spline types handled (magicaly)
> automatically? I made new sor_spline available and I'm working on some
> other spline types.
To convert from a pure spline to a lathe or prism spline, you'd specify
which two coordinate axes you want, using the normal x/y/z r/g/b/f/t
symbols. Natural cubic splines would be converted to catmull-rom cubics,
and a warning message printed. I haven't figured out what the syntax for
going from objects to pure splines would be yet.
e.g. prism{ MyLinearSpline x,y linear_sweep 0, 1} uses the x and y
coordinates of the spline from MyLinearSpline as the shape of the prism.
--
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <pan### [at] gtenet>,
Mark Wagner <mar### [at] gtenet> wrote:
> I haven't figured out what the syntax for going from objects to pure
> splines would be yet.
If you mean taking an object like a lathe or prism and getting a spline
from it, I think that is unnecessary. If you can specify the object, you
can specify the spline and pass it to the object while keeping it for
later use.
The internal handling of splines could also use some work...I doubt any
major changes to internal structures would be in any future version
though. (Disclaimer: This is my personal judgement, not an official
statement...but everything that has been said indicates that the next
major update will be POV 4.)
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
