 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> The meaning of that is that you didn't know the answer to some question
> and thus you didn't take a point in that question, but it interested you
> so much that you tried to find the answer.
oh, yes, forgot about that :)
cu!
--
camera{location-z*3}#macro G(b,e)b+(e-b)*(C/50)#end#macro L(b,e,k,l)#local C=0
;#while(C<50)sphere{G(b,e),.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1
;#end#end L(y-x,y,x,x+y)L(y,-x-y,x+y,y)L(-x-y,-y,y,y+z)L(-y,y,y+z,x+y)L(0,x+y,
<.5,1,.5>,x)L(0,x-y,<.5,1,.5>,x) // ZK http://www.povplace.be.tf
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ok, I tried to make the test more rational and also divide it into more
readable sections. What do you think? What is your new score?
The maximum score (this time I think it's reachable) is 66.
I myself got a score of 48. (Ok, perhaps the test got a bit biased
torwards my own knowledge, but I tried to keep it as unbiased as possible;
judge by yourself :) )
POV-SDL:
-------
* Functions, macros, arrays, loops and file-IO directives are a piece of cake
to you.
* You don't like modellers because they don't allow you to create your
scenes algorithmically. It's a lot more interesting to find an algorithm
to create certain effect or surface than just doing it with the mouse.
* It's not unusual that the scene files you write take several minutes to
parse, even though the file itself only takes a few hundreds of lines.
* It sometimes happens that the scene you made takes a lot longer to parse
than to render, even at a very high resolution and lots of antialiasing.
* 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.
* 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 often debug your povray code using the text message streams.
* You've written your own include file and distributed it on the net. It has
got some popularity.
POV features:
------------
* You have made bicubic patches by hand, by writing plain coordinates (and
they worked as you expected).
* You have made a pov-script that creates a smooth surface with bicubic patches
using some algorithm.
* You know the principle behind joining several bicubic patches so that they
form a contiguous smooth surface (with no sharp edges).
* You know what is the relation between bicubic patches and bezier splines.
* You have made triangle meshes by hand, by writing plain coordinates.
* You have made a pov-script which generates triangle meshes using some
algorithm.
* These meshes you create usually use UV-mapping.
* You know the basic principle of smoothing a mesh, ie. make a mesh of
smooth triangles from a mesh of regular flat triangles.
* It's very easy to you to make slope maps and actually you often use
them to make your textures.
* 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.
* You understand the scattering function pictures in the media section of
the documentation.
* 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).
* Making good-looking radiosity images is not a problem to you.
* You could make any of the Chris Colefax's includes or macros by yourself
if you wanted.
* 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).
* You never get the "camera is inside non-hollow object" warning. If you
ever get it, it's absolutely intentional.
* You know that a height_field has an inside and how it is defined.
* You know, without looking at the docs, how antialiasing methods 1 and 2 work
and what's their difference. You know why method 2 gives usually a much
better result but is slower.
Math:
----
* 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).
* Making isosurfaces is not a problem to you. The only problem is just
figuring out the right function.
* 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 usually know when an isosurface function can be implemented as a
poly primitive, and you could convert the function to polynomial form and
construct the poly primitive from it (the torus function is one example
of this).
* 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) and
why it is needed sometimes.
* 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). (This means, for example,
that you could write a #macro which creates the matrix transformation from
any given set of other transformations.)
* You know how to use all the internal float, vector and string functions
without problem. You usually use them a lot.
* 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.
Raytracing algorithms:
---------------------
* You know the principles of raytracing. For example, you know how to calculate
the intersection of a segment and a simple primitive like a sphere, and
how to calculate basic lighting for this intersection point. You might even
have written a simple raytracer some time.
* You understand why hidden surface removal, shadow testing, reflections and
refractions are so easy to implement in raytracing and so difficult to
implement in other rendering techniques. You know how they are implemented
in raytracing.
* You understand why non-linear transformations are next to impossible to
implement for any given primitive. You understand why, regardless of this,
any type of transformation is possible for pigments and such.
* You know how CSG operations are implemented in raytracing.
* 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 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 understand how the stochastic radiosity algorithm used by POV-Ray
works at algorithmical level.
* You understand how photon mapping works at algorithmical level.
* You understand how dispersion works at algorithmical level.
Formats:
-------
* 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 know the format of a PCM file.
* You have made one by hand.
The IRTC:
--------
* You participate in almost every IRTC contest.
* You have got to the top 20 best still images.
* You have won a price in the IRTC.
POV-Ray programming:
-------------------
* 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 external tool for povray.
* You know which .cpp 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 .cpp 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 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 31 Jan 2002 18:39:34 -0500, Warp wrote:
54 this time.
--
#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] povray org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c59d5b6@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> Ok, I tried to make the test more rational and also divide it into more
> readable sections. What do you think? What is your new score?
>
> The maximum score (this time I think it's reachable) is 66.
> I myself got a score of 48. (Ok, perhaps the test got a bit biased
> torwards my own knowledge, but I tried to keep it as unbiased as possible;
> judge by yourself :) )
I also got 48, not counting the ones mentioned below.
> * You've written your own include file and distributed it on the net. It has
> got some popularity.
Well...I've done a lot of work on the scene and include file collections
for 3.5, and I once released a macro collection, though nobody ever used
it...
> * It's very easy to you to make slope maps and actually you often use
> them to make your textures.
No...if I need that much control of surface features, I generally use
isosurfaces. ;-)
> * 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).
I think I'll refrain from answering this one...
> * You have used the quadric, cubic, quartic or poly primitives.
Nope, I stick to isosurfaces. That count? I think it should...
> * You have used poly objects bigger than 4th degree.
I've used polynomials of greater than 4th degree in isosurfaces...
Hmm...you know how to do real blurred reflection, you can get the media
parameters right on the first try (or first few tries), you know the
difference between using a colored transparent texture and using
fade_color or media, you can explain why using a mesh is better than a
union of triangles, you've run into the "patterned textures in layered
textures" error, you've reached the depth limit in recursive macros, you
have used the POV-Ray scene description language for purposes which have
nothing to do with scene description...
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I got a 43.
--
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 01 Feb 2002 00:31:22 -0500, Christopher James Huff wrote:
> Hmm...you know how to do real blurred reflection, you can get the media
> parameters right on the first try (or first few tries), you know the
> difference between using a colored transparent texture and using
> fade_color or media, you can explain why using a mesh is better than a
> union of triangles, you've run into the "patterned textures in layered
> textures" error, you've reached the depth limit in recursive macros, you
> have used the POV-Ray scene description language for purposes which have
> nothing to do with scene description...
You had a hand in creating the current method used to do blurred reflection;
you've run into the "too many layers" error...
...you've gotten past it by creating a single-layered texture that looks just
like the one you couldn't get with layers...
...you've done that without using a texture_map;
you've used nested pigment_maps;
you understand what "form" and "metric" do in the 3.5 crackle pattern;
you understand why, given that A is #declared as a number, (A) and A aren't
always the same thing;
you've used 'radial' more than once in the same pigment;
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;
...at least one of those patterns does not appear to be made of rectilinear
regions;
you know how to force the media code to take more samples in an interesting
area of the scene;
you understand why a plane makes a bad media container;
you know how to use type 5 scattering media;
you know how to simulate distance-dependent reflection;
you know how to use .df3 files to create arbitrary full-color solid pigments;
you've used multiple text objects to achieve a desired text effect...
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
32
cu!
--
camera{location-z*3}#macro G(b,e)b+(e-b)*(C/50)#end#macro L(b,e,k,l)#local C=0
;#while(C<50)sphere{G(b,e),.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1
;#end#end L(y-x,y,x,x+y)L(y,-x-y,x+y,y)L(-x-y,-y,y,y+z)L(-y,y,y+z,x+y)L(0,x+y,
<.5,1,.5>,x)L(0,x-y,<.5,1,.5>,x) // ZK http://www.povplace.be.tf
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:3c59d5b6@news.povray.org...
> Ok, I tried to make the test more rational and also divide it into more
> readable sections. What do you think? What is your new score?
>
> The maximum score (this time I think it's reachable) is 66.
> I myself got a score of 48. (Ok, perhaps the test got a bit biased
> torwards my own knowledge, but I tried to keep it as unbiased as possible;
> judge by yourself :) )
>
8 :-< (10 if I take the questions about itrc literally since my best
placing pic was
created in Vue d'espirit)
Warp, I suggest for the questions about top 20 and prize in irtc add the
requirement that the pic must have been created in pov-ray
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Peter Popov wrote:
>
> For CSG, you'll need all intersections, and in 3.1, the
> All_Mesh_Intersections function returned just the closest one (for
> speed reasons I guess).
I think i understand what you mean, so it's clearly a 'Povray internals'
question and not a 'Raytracing in general' one, of course it's perfectly
valid for the list though.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
25 now for me (up 10 from 15).
including:
* You know BOTH reasons why a mesh can't be used in CSG.
(I do now)
--
Tom Bates
#macro T(B)#local m=mod(B,8);#local B=floor(B/8);m#end#local C=126981491245202;#
local D=115694168992822;sphere_sweep{b_spline 16#local i=0;#while(i<16)<T(C)-4,T
(D)-4,10-i/10>.1#local i=i+1;#end pigment{rgb 1}}light_source{-10,1} //Tom Bates
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
