> Tony[B] has stated much more eloquently what I intended to convey. :)

:-D

Post a reply to this message

> Thank you, nevertheless.

You're welcome.

> Well... What "it"? Implementing these principles in software design? It
> can be done, if my current pet project, the Quill, is any indication.

Good, then show us how by making your own patch when 3.5 comes out and you
can get your hands on the source-code, OK?

> It's not about a "wish list". It's about having the same features but
> organized in a way that would enhance the whole.

"Suggestions" and "recommendations" without code are a wish-list in these
parts. This is the way you would like POV to be, is it not? Then your are
wishing, and by listing your wishes, you have created a wish-list.

> It seems that this is the most frequent misunderstanding so far:
> thinking that I was complaining on features.

If everybody understood what you wrote as such, then it's your own fault for
badly wording things. For example, this "we" can be taken as being quite
haughty on your part, and might be seen as implying "Behold, I am the wise
one, do what I say, because it is better than your meager toilings of the
past". Or something to that effect. :)

> Wouldn't a lubricated machine
> run better than dry gears?

Not if the dry gears were coated with teflon or something. ;)

Post a reply to this message

On Sun, 13 Jan 2002 12:24:55 +0200, Eugene Arenhaus <eug### [at] avalon-netcoil> wrote:
> How? Easy. You write a Trace routine for transparency shader that will
> create two more ray objects (passing and bouncing), cast them (by
> calling Scene's Trace routine), combine the result in its single ray and
> return that. 
> 
> Or, in short: You can cast a zillion rays if you want simply by
> recursively calling Trace.

Yeah, I can see that... But I have to wonder if POV is not already doing something
like this then
how is it doing it? I see no way of returning an accurate value for any single point
unless it
already impliments something of this sort. If it doesn't, then there is bound to be a
good reason
why it doesn't. As for my not thnking... Maybe, but then I could say the same, since
as I said
this time, I don't get how the current behaviour could differ significantly from what
you suggest
and still work, unless there is some very specific optimization or feature that
requires it be done
some other way. And in that case I can't even imagine what they did do instead of a
single
trace() routine. But then I haven't exactly looked at the code either. I have enough
problems
figuring out why I did something after leaving program code alone for a coupla years,
let
alone trying to figure out how or why someone elses (far larger and more complex) code
does
anything. lol

Post a reply to this message

> 'Write-ability' is an important issue too and most people here will
> probably agree that writing
> 
> sphere { 0, 1 }
> 
> is much easier and in this case IMO much faster to read too.


Only if you have some clue what the parameters do. For instance while
trying out the partical system and other features in MegaPOV+ I downloaded
some examples that where and older implimentation, One parameter didn't even
exist in the new version and the glow lights used a different syntax that literally
had one value sitting by itself with no explaination. Had I been using the patch
from the original author of that feature I may have had a file describing what it
was, but instead had to guess. I will take readability over write-ability any day. ;)
At least when I don't necessarilly have understandable documentation to work
with.

Post a reply to this message

In article <1104_1010963152@selliot> , Patrick Elliott <selliot@rraz.com> 
wrote:

> Only if you have some clue what the parameters do. For instance while trying
> out the partical system and other features in MegaPOV+ I downloaded some
> examples that where and older implimentation, One parameter didn't even exist
> in the new version and the glow lights used a different syntax that literally
> had one value sitting by itself with no explaination. Had I been using the
> patch from the original author of that feature I may have had a file
> describing what it was, but instead had to guess. I will take readability over
> write-ability any day. ;) At least when I don't necessarilly have
> understandable documentation to work with.

This is exactly why the POV-Team carefully evaluated each patch for addition
into the official version and made changes to syntax or behavior in order to
keep the language consistent.

    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

Eugene Arenhaus wrote in message <3C41628F.7B4132C1@avalon-net.co.il>...
>Can I make a macro that would calculate a macro that I would pass it in
>a parameter?


Do you mean you want to pass a macro name to a macro, and then have that
second macro evaluate the first macro?  Try something like this from my
implementation of a binary search tree ADT in POV:

#macro Parse_String(String)
    #fopen FOut "parse_string.tmp" write
    #write(FOut,String)
    #fclose FOut
    #include "parse_string.tmp"
#end

#macro Compare(Data, D, _BST_COMPFUNC) /* _BST_COMPFUNC is a string
containing the name of a macro or internal function with the same semantics
as the strcmp function */
    #local Comp = Parse_String(_BST_COMPFUNC) (Data, D); /* Evaluates the
macro with the parameters Data and D */
    Comp
#end

Post a reply to this message

On Sun, 13 Jan 2002 12:11:06 +0200, Eugene Arenhaus <eug### [at] avalon-netcoil>
wrote:
> > - 'instancing' (clone/refer patch) have been discussed and planned before
> > but it isn't as simple as it might seem.
>
> I never said it was simple - I only said it was more than worth making.

I say it is simple to code. I did such patch for my own. Clone is slower then
copy. The reason is another transformation for every intersection test. When
object is large CSG then it can save memory. But intersection test is so much
slower then (becouse of complex CSG). I found it not worth. It has sense only
for meshes.

ABX
--
disc{z,-z 5#macro O()asc(substr("-+((1*(,1,/.-,*/(,&.323/'1"e,1))*.1-4#declare
e=e-1;#end#local e=26;pigment{#local g=function(_){ceil(_)-_}function#local//X
k=function{pattern{object{sphere_sweep{linear_spline 13#while(e>0)<O(),O()//AB
>.01#end}}}}{k(g(atan2(x,y)),g(ln((y+x)^2+1e-5)),0)}}finish{ambient 1}}//POV35

Post a reply to this message

On Sun, 13 Jan 2002 12:20:20 +0200, Eugene Arenhaus <eug### [at] avalon-netcoil>
wrote:
> >   I didn't understand this paragraph at all. How do #macros and functions
> > "impede parametric generation of scenes and animation"?
>
> Try to pass a macro to a macro?

You can do it as string with name of the macro.
Check Parse_Macro macro in standard include files of POV 3.5

ABX
--
disc{z,-z 5#macro O()asc(substr("-+((1*(,1,/.-,*/(,&.323/'1"e,1))*.1-4#declare
e=e-1;#end#local e=26;pigment{#local g=function(_){ceil(_)-_}function#local//X
k=function{pattern{object{sphere_sweep{linear_spline 13#while(e>0)<O(),O()//AB
>.01#end}}}}{k(g(atan2(x,y)),g(ln((y+x)^2+1e-5)),0)}}finish{ambient 1}}//POV35

Post a reply to this message

On Sun, 13 Jan 2002 12:33:51 +0200, Eugene Arenhaus <eug### [at] avalon-netcoil>
wrote:
> Can I make a macro that would calculate a macro that I would pass it in
> a parameter?

sure. you only need #include, #macro, #fopen and #write directives. So it should
work when those directives started in POV (3.0 ? 2.0 ?).

ABX
--
disc{z,-z 5#macro O()asc(substr("-+((1*(,1,/.-,*/(,&.323/'1"e,1))*.1-4#declare
e=e-1;#end#local e=26;pigment{#local g=function(_){ceil(_)-_}function#local//X
k=function{pattern{object{sphere_sweep{linear_spline 13#while(e>0)<O(),O()//AB
>.01#end}}}}{k(g(atan2(x,y)),g(ln((y+x)^2+1e-5)),0)}}finish{ambient 1}}//POV35

Post a reply to this message

wrote:

> I found it not worth. It has sense only
> for meshes.

How about blobs? I think it was mentioned in the past a few times.

Ingo

Post a reply to this message