On Fri, 11 Jan 2002 23:33:45 -0000, "Rick [Kitty5]" <ric### [at] kitty5com> wrote:
> > have you checked this?
>
> I have spent hours doing conversions

what exactly was a problem ?

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 ?).


#macro appeared in 3.1.

But anyway, I think Eugene said he didn't want to have to use temporary 
files to achieve this.

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   videotron.ca  */}camera{location<6,1.25,-6>look_at a orthographic}

Post a reply to this message

On Mon, 14 Jan 2002 07:44:28 -0500, Francois Labreque <fla### [at] videotronca>
wrote:
> > sure. you only need #include, #macro, #fopen and #write directives. So it should
> > work when those directives started in POV (3.0 ? 2.0 ?).
>
> #macro appeared in 3.1.

No problem with Parse_String as include file so #macro is not needed.

> But anyway, I think Eugene said he didn't want to have to use temporary 
> files to achieve this.

perhaps, but "They" said it is not a wish list also ;-)

ABX

Post a reply to this message

On Sun, 13 Jan 2002 12:20:20 +0200, Eugene Arenhaus 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?

That's a parser problem.  Implementing it requires us to give the parser 
more than one token of lookahead, and that's not as easy as it might 
appear.  There are many things wrong with the current parser, and the 
fact that unget is just a flag instead of some kind of expandable data 
structure is just one of them.

This and other parser issues are scheduled to be addressed in POV 4.0 in
one way or another.

-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbt 1}hollow interior{media{emission T}}finish{
reflection.1}}#end Z(-x-x.2y)Z(-x-x.4x)camera{location z*-10rotate x*90}

Post a reply to this message

On Sun, 13 Jan 2002 12:24:55 +0200, Eugene Arenhaus 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. 

Exactly how some very interesting Renderman shaders work.

-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbt 1}hollow interior{media{emission T}}finish{
reflection.1}}#end Z(-x-x.2y)Z(-x-x.4x)camera{location z*-10rotate x*90}

Post a reply to this message

In article <61l54ukl1i71rrrnq1i4ih3l5kndn2a3m1@4ax.com>,
 W?odzimierz ABX Skiba <abx### [at] babilonorg> wrote:

> No problem with Parse_String as include file so #macro is not needed.

Parse_String() is itself a macro, and uses a temporary file internally. 
And I don't think he said he didn't want to use a macro, but that he 
wanted to pass one macro to another. Parse_String() would allow him to 
pass the macro name, though it would be slower. A better alternative 
might be to write the temp file in the macro itself, and then just 
include it for each macro call, avoiding a bunch of redundant file 
writes, but that still requires use of a temp file.

The method I've always used was to use a "user definable" macro that the 
main macro will call (I think I provided an example in another message). 
Still slower in some situations, but it doesn't require temporary files.

-- 
 -- 
Christopher James Huff <chr### [at] maccom>

Post a reply to this message

In article <7h654usqsfq6ift9jn75vftm32jhtnt695@4ax.com>,
 W?odzimierz ABX Skiba <abx### [at] babilonorg> wrote:

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

What about bicubic patches, height fields, and isosurfaces?

Hmm, I wonder if a "deep copying" version of the mesh object could 
render faster in some scenes, at the cost of extra memory...probably not 
worth it.

-- 
 -- 
Christopher James Huff <chr### [at] maccom>

Post a reply to this message

Christopher James Huff wrote:
> 
> What about bicubic patches, height fields, and isosurfaces?
> 

height fields already work like meshes, i doubt there would be much sense
for isosurfaces since they don't use much memory.  

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

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

Like i presumed in the other thread.

Anyway i hope we get to see this patch in some unofficial version after
3.5, there would still be use for it in some situations.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

In article <3C434A75.3455BD71@gmx.de> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

> height fields already work like meshes, i doubt there would be much sense
> for isosurfaces since they don't use much memory.

If you copy an isosurface, the function will be shared.

    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