Christopher James Huff wrote:
> 
> It isn't hard, just a bunch of spheres and cylinders in a loop and some
> transformations. Basically, rotate for the twisting, translate out by
> the diameter of the ring, and rotate to the position on the ring.
> 
> --
> Christopher James Huff <chr### [at] maccom>
> POV-Ray TAG e-mail: chr### [at] tagpovrayorg
> TAG web site: http://tag.povray.org/

Oh, I thought maybe it was a general macro for DNA following a curve. I
was gonna use it in my IRTC entry, but I've changed my subject now, on
advice from my brother. Which reminds me; I have a lot of work to do!
(and less than a month to do it in!)
Thanks anyways!

-- 
signature{
  "Grey Knight" contact{ email "gre### [at] yahoocom" }
  site_of_week{ url "http://digilander.iol.it/jrgpov" }
}

Post a reply to this message

Damn, I score between a 20 and a 25. Some questions I give myself half
points for.

Post a reply to this message

3c5ec2d2$1@news.povray.org...
> ... couldn't you just replace 'em with "you are Gilles Tran" 10 times?

Well, I had to make up my own questions so that I could get at least few
points AND brag  like other people ;-)

G.

--

**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

OK, so I admit I'm not anywhere near advanced status, but out of interest
why isn't "difference" a primitive CSG operation (simple answer please!!!)

Is there a Beginner/Intermediate Povrayer Test?

Reuben
doo### [at] breathemailnet

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3c5977ae@news.povray.org...
>   Some years ago I made a "Hardcore Povrayer Test" just for fun. Here it
is
> again, with small updates.
>
>   For each statement which you feel is true in your case (be sincere),
take
> one point. The number of points you get is your score. The maximum number
> of points is 65.
>   (My personal score is "only" 37, so it *is* a tough test.)
>
>
> * You have participated in the IRTC and got to the top 20 best images.
> * You have won a price in the IRTC.
> * You have made bicubic patches by hand (and they worked as you expected).
> * You have made a pov-script that creates a smooth surface with bicubic
patches
>   using some algorithm.
> * You have made triangle meshes by hand.
> * You have made a pov-script which generates triangle meshes using some
>   algorithm.
> * You have used the quadric, cubic, quartic or poly primitives.
> * You have used poly objects bigger than 4th degree.
> * You have calculated the polynomial for that poly object by yourself
>   (instead of looking at the formula somwhere or just trying random
values).
> * You know the format of a PCM file.
> * You have made one by hand.
> * You have made a program which outputs a df3 file and used it in a scene.
> * You know what a df3 file is and what's its format.
> * You have made a patch for povray.
> * Your patch is included in MegaPov or at least it's popular.
> * Your patch was included in POV-Ray 3.5.
> * You have made a popular tool for povray.
> * You have used every object type, every camera type, every light source
>   type, every media type, etc. and know how to use them.
> * You could write a torus-shaped isosurface by memory, without needing
>   to look anywhere for the function.
> * Even if you don't remember the torus function, you could deduce it by
>   yourself, without looking it anywhere.
> * You know what is the "sturmian root solver" thing which is used with the
>   'sturm' keyword in some objects (ie. you know the algorithm it uses).
> * The intensity multiplier curves and light fading functions in the light
>   source section of the povray manual are very clear and you understand
>   them perfectly (and you might use them to choose your light source
>   types).
> * You understand how photon mapping works (at algorithm level).
> * You have found the 'average normal bug' by yourself in a povray version
>   previous than 3.1e.
> * You know exactly what was causing it.
> * You never include the povray include libraries (like colors.inc) because
>   they slow parsing, but always define your colors, textures, etc by
>   yourself.
> * You only use the png format when working with povray.
> * You always use it with alpha channel.
> * It's very easy to you to make slope maps and actually you often use
>   them to make your textures.
> * You know what the 'use_index' keyword is used for without looking at
>   the manual.
> * You understand the matrix transformation and you can write them by hand.
> * You know how to calculate the matrix from any number of consecutive
>   transformations (translate, scale, rotate).
> * For any given identifier name you can tell by heart if it's a reserved
>   keyword (ie. an illegal identifier name) or not (of course without
having
>   syntax highlighting to help you).
> * You could make any of the Chris Colefax's includes or macros by yourself
>   if you wanted.
> * You use frequency, phase, octaves, omega and lambda without problems
>   when creating your own textures.
> * You can tell what does each one of them do (without looking at the
>   documentation).
> * You understand the scattering function pictures in the media section of
>   the documentation.
> * You remember all the keywords that can be put in a global_settings block
and
>   you know what do they mean and how to use them.
> * Making good-looking radiosity images is not a problem to you.
> * You remember all the built-in float and vector identifiers.
> * You use all the vector and string functions without problem.
> * You know if some special feature is already implemented in the POV-Ray
3.5
>   standard include files (and thus you know you don't have to implement it
>   yourself).
> * Functions, macros, arrays, loops and file-IO directives are a piece of
cake.
> * You never get the "camera is inside non-hollow object" warning. If you
>   ever get it, it's absolutely intentional.
> * You have made a modeller for povray.
> * You often debug your povray code using the text message streams.
> * You can easily calculate the camera parameters when you want to put a
>   box right in front of the camera so that it completely and exactly fills
>   the viewing area.
> * You know which .c and .h files you must change to add a keyword to the
>   parser.
> * You can add a keyword and get it right the first time.
> * You know which .c file contains the functionality for each aspect of
>   the renderer.
> * You can find a bug in the renderer source code given just a description
>   of the symptoms and without using a debugger.
> * You know BOTH reasons why a mesh can't be used in CSG.
> * You know why refraction and media do work with meshes, even though CSG
>   doesn't.
> * You know that 'merge' doesn't have to be a primitive CSG operation
>   and can recite the equivalent sequence of intersections, unions, and
>   inverses.
> * You know that 'difference' isn't a primitive CSG operation and you
>   know how POV represents one internally.
> * You understand how 'bounded_by' _really_ works.
> * You know that a height_field has an inside and how it is defined.
> * You've written your own include file and distributed it on the net. It
has
>   got some popularity.
> * You understand all the options to 'media' without having to look in
>   the manual.
> * You know, without looking at the docs, how antialiasing methods 1 and 2
work
>   and what's their difference.
> * You have made yourself an obfuscated signature in POV-Ray SDL in 4 lines
>   or less, and you use it by default when posting to the POV-Ray news
server.
> * You didn't know the answer to one of the above questions so you tried
>   to find it in the manual.
> * You didn't know the answer to one of the above questions so you tried
>   to find it in the source code.
> * You didn't know that 'merge' wasn't a primitive but now that you do
>   you have worked it out for yourself.
> * You are a member of the POV-Team.
>
>
>
> --
> #macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb
M()}}
> N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
> N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  -
Warp -

Post a reply to this message

On Wed, 13 Feb 2002 21:17:27 -0000, Reuben Pearse wrote:
> OK, so I admit I'm not anywhere near advanced status, but out of interest
> why isn't "difference" a primitive CSG operation (simple answer please!!!)

Because it can be rewritten in terms of more primitive operations.

difference {object{A} object{B}} is the same as 
intersection{object{A} object{B inverse}}
 
In fact, that's how it's actually implemented inside POV.

To answer your next question, merge isn't primitive either.  

merge {object{A} object{B}} is the same as
intersection{object{A inverse} object{B inverse} inverse}

but it's not actually implemented that way, for historical reasons (there's
nothing to be gained by rewriting it, so nobody ever did.)

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

Ron Parker <ron### [at] povrayorg> wrote:
: Because it can be rewritten in terms of more primitive operations.

  Who says 'intersection' is more primitive than 'difference'?-)

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

On 13 Feb 2002 16:56:50 -0500, Warp wrote:
> Ron Parker <ron### [at] povrayorg> wrote:
>: Because it can be rewritten in terms of more primitive operations.
> 
>   Who says 'intersection' is more primitive than 'difference'?-)

Apparently, whoever wrote the code for difference. :)

merge {object{A inverse} object{B} inverse} works nicely too.

-- 
#local R=<7084844682857967,0787982,826975826580>;#macro L(P)concat(#while(P)chr(
mod(P,100)),#local P=P/100;#end"")#end background{rgb 1}text{ttf L(R.x)L(R.y)0,0
translate<-.8,0,-1>}text{ttf L(R.x)L(R.z)0,0translate<-1.6,-.75,-1>}sphere{z/9e3
4/26/2001finish{reflection 1}}//ron.parker@povray.org My opinions, nobody else's

Post a reply to this message

Wasn't it Ron Parker who wrote:

>To answer your next question, merge isn't primitive either.  
>
>merge {object{A} object{B}} is the same as
>intersection{object{A inverse} object{B inverse} inverse}
>
>but it's not actually implemented that way, for historical reasons (there's
>nothing to be gained by rewriting it, so nobody ever did.)

Not only is there nothing to be gained by rewriting it, but it would end
up being much less efficient in most cases. The bounding box of a merge
using the current code tends to be a good fit, but the bounding box of
the inverse intersection inverse is usually infinite.

I claim that merge{object{A} object{B}} is more like being the same as

#declare U = union{object{A} object{B}}
intersection{object{A inverse} object{B inverse} inverse
   bounded_by{box{min_extent(U),max_extent(U)}}
}

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

This sounds interesting - where is the test? (I can't see the original post
for this thread.)

/ Martin

Post a reply to this message

Oops, don't worry about that post - I found it...

/ Martin

Post a reply to this message