 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"ingo" <ing### [at] home nl> a écrit dans le message de news:
Xns### [at] povrayorg...
> in news:slr### [at] fwicom Ron Parker wrote:
>
> > you ....
>
> After all this harcore stuff,
> you actually renderd a complete scene, posted it, somebody even liked it
> and publicly said he uses it as his desktop image.
>
> Ingo
And...
- you get paid to create povray scripts or images
- software vendors send you copies of their graphic software just for you to
tell them how well it compares to povray
- webmasters ask for your permission to use your povray images in
their pages
- webmasters don't ask, but use your povray work in their pages anyway
- your images appear in magazines (interior pages)
- your images appear on magazine or book covers
- you are interviewed about your povray work
- you give public conferences about your povray work
- your images/animations are shown/featured in public during art-related
shows
- your images/animations are shown/featured in public during non-art-related
shows
G.
--
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> POV-SDL:
y-y-n-n-n-y?-y-y, but not for the popularity part.
5
> POV features:
y-n-y-y-y-n-n-n, but I could figure it out-y-y-y-n-y-y-y, but just a very bad
copy-y-y-y-y
14
> Math:
n-n-n-y-y-y-n-n-y-y-y?-n, but give me a piece of paper...
6
> Raytracing algorithms:
-y? I've been reading Foley-Van Dam for a while now-y-n, but I guess it-n-didn't
know, but now I do-y-n, only the obvious one-y-n, but I guess it-y, thanks to
Nathan's paper-n
5
> Formats:
n-y-y-n
2
>
> The IRTC:
no, definitely I don't.-y-y
2.
>
> POV-Ray programming:
n-n-n-n-n-n-n, but I can read...-n-n.
0
So Total: 34.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <slr### [at] fwicom>,
Ron Parker <ron### [at] povrayorg> wrote:
> you've used nested pigment_maps;
Yep.
> you understand why, given that A is #declared as a number, (A) and A aren't
> always the same thing;
> you know all of the options to the repeat warp;
> you've used one or more repeat warps to create your own infinitely-tileable
> patterns;
Yes.
> you know how to force the media code to take more samples in an interesting
> area of the scene;
This sounds interesting...the only method I know of is to use completely
transparent hollow shapes to force new intervals, is this what you are
talking about or are you thinking of a better method?
> you understand why a plane makes a bad media container;
> you know how to use type 5 scattering media;
Yes.
> you know how to simulate distance-dependent reflection;
It isn't physically correct, but I still know how to do it.
> you know how to use .df3 files to create arbitrary full-color solid pigments;
Yes. I'm even working on a program to create the necessary files, and
automatically generate the POV code.
> you've used multiple text objects to achieve a desired text effect...
I think you need to define "desired text effect". I assume you are
referring to the circle text macro, but that could also describe using
multiple objects to get text of different sizes, or any time you use
multiple text objects.
Hmm...
You know how to make an arbitrary warp (such as the displace warp,
uneven scaling, or twisting) of any pattern in POV script.
You know how to directly specify the rgb color of pigment/media using
functions.
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3C5A7CFA.69A5EBEA@namtar.qub.ac.uk>,
Grey Knight <s16### [at] namtarqubacuk> wrote:
> Actually, I was just looking at your site and saw a picture of a DNA
> ring. If you still have the macro for generating that, I'd like it.
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/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Only 14... :(
-peter
Warp wrote:
> 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.)
>
--
Current obsession: "Ballet pour ma fille."
http://www.applesnake.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> 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.
Or animations... Yes
> * You have won a price in the IRTC.
A prize, yes.
> * You have made bicubic patches by hand (and they worked as you
> expected).
Yes.
> * You have made a pov-script that creates a smooth surface with
> bicubic patches using some algorithm.
It's how the Greb are done.
> * You have made triangle meshes by hand.
Yes.
> * You have made a pov-script which generates triangle meshes using
> some algorithm.
Yes.
> * You have used the quadric, cubic, quartic or poly primitives.
How many for using all but the poly?
> * You have used poly objects bigger than 4th degree.
Nope.
> * You have calculated the polynomial for that poly object by yourself
> (instead of looking at the formula somwhere or just trying random
> values).
No.
> * You know the format of a PCM file.
Yes (got to, my modeler imports and exports it).
> * You have made one by hand.
No.
> * You have made a program which outputs a df3 file and used it in a
> scene.
No.
> * You know what a df3 file is and what's its format.
No.
> * You have made a patch for povray.
Wrote some code.
> * Your patch is included in MegaPov or at least it's popular.
Yes.
> * Your patch was included in POV-Ray 3.5.
Yes.
> * You have made a popular tool for povray.
Dunno if it's popular...
> * You have used every object type, every camera type, every light
> source type, every media type, etc. and know how to use them.
I haven't tried all the camera types. Yes on the rest (for 3.1g).
> * You could write a torus-shaped isosurface by memory, without needing
> to look anywhere for the function.
No.
> * Even if you don't remember the torus function, you could deduce it
> by yourself, without looking it anywhere.
Yes.
> * 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).
No.
> * 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).
Yes.
> * You understand how photon mapping works (at algorithm level).
No.
> * You have found the 'average normal bug' by yourself in a povray
> version previous than 3.1e.
No.
> * You know exactly what was causing it.
No.
> * You never include the povray include libraries (like colors.inc)
> because they slow parsing, but always define your colors, textures,
> etc by yourself.
Yes.
> * You only use the png format when working with povray.
Yes.
> * You always use it with alpha channel.
No.
> * It's very easy to you to make slope maps and actually you often use
> them to make your textures.
Easy, but I rarely use them.
> * You know what the 'use_index' keyword is used for without looking at
> the manual.
Yes.
> * You understand the matrix transformation and you can write them by
> hand.
Yes.
> * You know how to calculate the matrix from any number of consecutive
> transformations (translate, scale, rotate).
Yes.
> * 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).
Probably.
> * You could make any of the Chris Colefax's includes or macros by
> yourself if you wanted.
Likely.
> * You use frequency, phase, octaves, omega and lambda without problems
> when creating your own textures.
Yes.
> * You can tell what does each one of them do (without looking at the
> documentation).
Yes.
> * You understand the scattering function pictures in the media section
> of the documentation.
Yes.
> * 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.
Rarely use them.
> * Making good-looking radiosity images is not a problem to you.
Never used it.
> * You remember all the built-in float and vector identifiers.
No.
> * You use all the vector and string functions without problem.
Yes.
> * 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).
Haven't tried 3.5 yet.
> * Functions, macros, arrays, loops and file-IO directives are a piece
> of cake.
Yes.
> * You never get the "camera is inside non-hollow object" warning. If
> you ever get it, it's absolutely intentional.
Only through typos...
> * You have made a modeller for povray.
Yes.
> * You often debug your povray code using the text message streams.
Yes.
> * 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.
I have a script to do that.
> * You know which .c and .h files you must change to add a keyword to
> the parser.
No.
> * You can add a keyword and get it right the first time.
No.
> * You know which .c file contains the functionality for each aspect of
> the renderer.
No.
> * You can find a bug in the renderer source code given just a
> description of the symptoms and without using a debugger.
No.
> * You know BOTH reasons why a mesh can't be used in CSG.
No.
> * You know why refraction and media do work with meshes, even though
> CSG doesn't.
No.
> * You know that 'merge' doesn't have to be a primitive CSG operation
> and can recite the equivalent sequence of intersections, unions, and
> inverses.
Yes.
> * You know that 'difference' isn't a primitive CSG operation and you
> know how POV represents one internally.
Yes.
> * You understand how 'bounded_by' _really_ works.
No.
> * You know that a height_field has an inside and how it is defined.
Yes.
> * You've written your own include file and distributed it on the net.
> It has got some popularity.
I dare say.
> * You understand all the options to 'media' without having to look in
> the manual.
Pretty much.
> * You know, without looking at the docs, how antialiasing methods 1
> and 2 work and what's their difference.
Yes.
> * 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.
Too busy working on Rusty...
> * You didn't know the answer to one of the above questions so you
> tried to find it in the manual.
Didn't go looking, no.
> * You didn't know the answer to one of the above questions so you
> tried to find it in the source code.
Didn't go looking.
> * You didn't know that 'merge' wasn't a primitive but now that you do
> you have worked it out for yourself.
Not applicable.
> * You are a member of the POV-Team.
No.
44
Regards,
John
--
ICQ: 46085459
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Snap!
Mick
"Tim Nikias" <tim### [at] gmxde> wrote in message news:3C59846D.AA650653@gmx.de...
> 14!
>
> Wow, I'm a genius!
>
> I agree with Ron Parker that many questions aren't realistic,
> those "know all about everything that is concerned with X"
> may be true in some cases, but in most, you'll have to be
> Einstein or Rain Man to do that...
>
> --
> Tim Nikias
> Homepage: http://www.digitaltwilight.de/no_lights/index.html
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Ron Parker" <ron### [at] povrayorg> wrote in message
news:slr### [at] fwicom...
> On Fri, 01 Feb 2002 00:31:22 -0500, Christopher James Huff wrote:
>
> you know all of the options to the repeat warp;
I do now, but only 'cause I'm writing a texture editor
> you know how to force the media code to take more samples in an
interesting
> area of the scene;
Ratio?
> you understand why a plane makes a bad media container;
cause it's infinite?
>
> you've used multiple text objects to achieve a desired text effect...
Yes
Gail
--
#macro G(H,S)disc{0z.4pigment{onion color_map{[0rgb<sin(H/pi)cos(S/pi)*(H<6)
cos(S/pi)*(H>6)>*18][.4rgb 0]}}translate<H-5S-3,9>}#end G(3,5)G(2,5.5)G(1,5)
G(.6,4)G(.5,3)G(.6,2)G(1,1)G(2,.5)G(3,.7)G(3.2,1.6)G(3.1,2.5)G(2.2,2.5)G(9,5
)G(8,5.5)G(7,5)G(7,4)G(7.7,3.3)G(8.3,2.7)G(9,2)G(9,1)G(8,.5)G(7,1)//GS
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"bob h" <omn### [at] charternet> wrote in message
news:3c5abfb0$1@news.povray.org...
> 18.5... maybe.... And I could add a point by opening the documentation up.
> Okay, so I'm no where near a "hardcore" POVer.
You did better than I did. I got 7 in the original
Gail
--
#macro G(H,S)disc{0z.4pigment{onion color_map{[0rgb<sin(H/pi)cos(S/pi)*(H<6)
cos(S/pi)*(H>6)>*18][.4rgb 0]}}translate<H-5S-3,9>}#end G(3,5)G(2,5.5)G(1,5)
G(.6,4)G(.5,3)G(.6,2)G(1,1)G(2,.5)G(3,.7)G(3.2,1.6)G(3.1,2.5)G(2.2,2.5)G(9,5
)G(8,5.5)G(7,5)G(7,4)G(7.7,3.3)G(8.3,2.7)G(9,2)G(9,1)G(8,.5)G(7,1)//GS
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > * Your patch was included in POV-Ray 3.5.
> Yes.
and yet:
> > * 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).
> Haven't tried 3.5 yet.
that's kinda strange...
cu!
--
ZK AKA SaD
http://www.povplace.be.tf
"It's my duty; my duty as a complete and utter bastard."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 01 Feb 2002 15:49:40 -0500, Christopher James Huff wrote:
>> you've used multiple text objects to achieve a desired text effect...
>
> I think you need to define "desired text effect". I assume you are
> referring to the circle text macro, but that could also describe using
> multiple objects to get text of different sizes, or any time you use
> multiple text objects.
Yes, I was aiming at that sort of generality. Putting bold text in the
middle of plain text counts too.
--
#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 Sat, 2 Feb 2002 11:45:42 +0200, Gail Shaw wrote:
>> you know how to force the media code to take more samples in an
> interesting
>> area of the scene;
>
> Ratio?
I was thinking of the "put a transparent hollow object around it" method.
--
#macro R(P)z+_(P)_(P)_(P+1)_(P+1)+z#end#macro Q(C,T)bicubic_patch{type 1u_steps
6v_steps 6R(1)R(3)R(5)R(7)pigment{rgb z}}#end#macro _(Y)#local X=asc(substr(C,Y
,1))-65;<T+mod(X,4)div(X,4)9>-2#end#macro O(T)Q("ABEFUQWS",T)Q("WSXTLOJN",T)#
end O(0)O(3)Q("JNKLCGCD",0)light_source{x 1}// ron### [at] povrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Gail Shaw" <gsh### [at] monotixcoza> wrote in message
news:3c5bb66a@news.povray.org...
>
> "bob h" <omn### [at] charternet> wrote in message
> news:3c5abfb0$1@news.povray.org...
> > 18.5... maybe.... And I could add a point by opening the documentation
up.
>
> You did better than I did. I got 7 in the original
Ha ha, well that was a big "maybe" I said there. Mostly because to really
know how well I answered I'd need to know more exactingly what is in POV-Ray
to be sure of my answers. 15 might be more accurate.
bob h
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Zeger Knaepen wrote:
>
> > > * Your patch was included in POV-Ray 3.5.
> > Yes.
>
> and yet:
>
> > > * 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).
> > Haven't tried 3.5 yet.
>
> that's kinda strange...
I'm waiting for the official (non-beta) release, although I might
use it for this round of the IRTC (for a media sampling feature).
--
ICQ: 46085459
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message news:3c59d5b6@news.povray.org...
Hmm, 9 for the first test, 16 for the second.... (and two points for something I
did for the first time last week).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Gilles Tran" <tra### [at] inapginrafr> wrote in message
news:3c5af113$1@news.povray.org...
<snip>
... couldn't you just replace 'em with "you are Gilles Tran" 10 times?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> Some years ago I made a "Hardcore Povrayer Test" just for fun.
> Question -
> * You are called "Uncle Ken".
Nuff said.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tom Melly" <tom### [at] tomandlucouk> a écrit dans le message de news:
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
|
|
| |
| |
|
|
|
|
| |
|
|
