In article <2dko8v0n8gi53kla520aca3au0ltl163a8@4ax.com>,
 ABX <abx### [at] abxartpl> wrote:

> > You seem to miss the point completely. I'm not talking about a post 
> > process feature, isn't that obvious?
> 
> No. You have described some functionality you dream about and I showed you 
> how it could be possible with my patch.

I used this specific example to describe some functionality I've long 
wanted and done some work on implementing, and you gave a completely 
different way to do the same thing. It still has nothing to do with the 
features I described, which is a way to specify some code for POV to run 
to do something that would normally be hard-coded.


> So do you want me to remove it from from MegaPOV 1.1 ?

I think you should definitely consider it. I'm pretty sure a public vote 
would be in favor of its inclusion, but keep in mind the changes you 
would have to make later to the patch and the support of people whose 
scene files no longer work.


> Do you prefer the previous much more limited post_processing ?

I prefer its syntax, though not its limitations.


> Or do you want to deliver vector functions within a month ? I do not 
> understand your intentions. I do not think community want to wait 
> years for post processing.

I posted an early version of my G patch in povray.binaries.programming. 
It is not fully working and the VM isn't as sophisticated as Thorsten's, 
but would be of great help in any programmable features.
Within a month? Probably not, I'll be busy with the end of the semester. 
If someone had asked, I might have put more work into it. But it would 
be easy to prepare for them.


> > Wrong. My script only handled all channels at once because that was all 
> > that was needed. It could easily handle channels separately.
> 
> Can you deliver sources for inclusion in compilation ?

Of course not. As I said, that was just an example of a possible syntax, 
the patch does not exist yet.


> I completly understand your point here but the problem is that I do not have
> vector functions available. And I can hardly see when they will be available.
> But once the sources will be available you can improve it, I will be happy 
> about that.

Vector functions are available, in the form of pigment functions. Code 
that uses pigment functions will be compatible with future vector 
function additions. A more robust solution might be to use vector 
functions and make a triple-function pigment or vector function (so 
people don't have to mess around with averaging multiple pigments).

BTW, will the next MegaPOV fix the name of the solid pattern?

-- 
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

In article <cja### [at] netplexaussieorg> , 
Christopher James Huff <cja### [at] earthlinknet>  wrote:

> A better idea might be some group label.
>
> sphere { ... object_groups "mask A", "mask B" }
> box { ... object_groups "high AA" }

For suggesting this syntax you deserve to be shot! ;-)

    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 <3e8dcf10$1@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

> > sphere { ... object_groups "mask A", "mask B" }
> > box { ... object_groups "high AA" }
> 
> For suggesting this syntax you deserve to be shot! ;-)

That wasn't really a fully-formed feature suggestion, just a quick, 
half-baked example of how it might look.
Anyway, what exactly is your objection? The string group IDs? Since a 
group isn't really a thing, I wasn't sure about giving it an actual 
identifier. It could be done and might look cleaner, it just might 
unexpectedly clash with variable or macro names.
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?

-- 
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

In article <cja### [at] netplexaussieorg> , 
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