 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Sorry, I haven't downloaded POV3.5 yet, so if any of these are embedded
in it already, ignore them.
1: Golden ratio:
since POV-Ray is used (primarily!) for creating art, shouldn't the
golden ratio be a built-in constant, like pi?
2: Polygonal preview:
A Moray-style preview where everything is represented by
polygons/wireframe. This would give a good impression of the finished
image for test renders.
I had more, but I've forgotten them! I'll see if I can dredge them up...
--
From the Grey Knight
//@---signature---
// Grey Knight's site of the week:
url{ "http://mathworld.wolfram.com" }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Oh yes,
3: #fkill() directive for file deletion? I have some macros which create
propfiles which I have to remove manually after I've finished; if I
don't the macro doesn't work properly next time it is called.
4: Support for matrix operations would be nice, although I'm writing a
series of macros to handle matrices at the min. Ho hum.
s1631001 wrote:
>
> Sorry, I haven't downloaded POV3.5 yet, so if any of these are embedded
> in it already, ignore them.
>
> 1: Golden ratio:
> since POV-Ray is used (primarily!) for creating art, shouldn't the
> golden ratio be a built-in constant, like pi?
>
> 2: Polygonal preview:
> A Moray-style preview where everything is represented by
> polygons/wireframe. This would give a good impression of the finished
> image for test renders.
>
> I had more, but I've forgotten them! I'll see if I can dredge them up...
>
> --
> From the Grey Knight
> //@---signature---
> // Grey Knight's site of the week:
> url{ "http://mathworld.wolfram.com" }
--
From the Grey Knight
//@---signature---
// Grey Knight's site of the week:
url{ "http://mathworld.wolfram.com" }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
s1631001 wrote:2: Polygonal preview:
> A Moray-style preview where everything is represented by
> polygons/wireframe. This would give a good impression of the finished
> image for test renders.
In the meantime, you might want to search back in povray.binaries.utilities
for a copy of POVGUI 1.5, which is a set of includes and macros that emulate
Moray-style modeling with a set of wireframe objects and gridded views(
front, side, top, perspective as well as render). Plane, sphere, cylinder,
cone, box, text (sort of), lathe, prism, height_field (both types) and
super-q are supported. Some of these ideas could probably make their way
into a patch of some sort.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 27 Nov 2001 14:01:12 +0000, s1631001 <s16### [at] namtar qubacuk> wrote:
> Sorry, I haven't downloaded POV3.5 yet, so if any of these are embedded
> in it already, ignore them.
>
> 1: Golden ratio:
> since POV-Ray is used (primarily!) for creating art, shouldn't the
> golden ratio be a built-in constant, like pi?
Do you know #include and #declare directive ?
You can build own script (include- file) with favourite constants and use it
with POV 3.1.
> 2: Polygonal preview:
> A Moray-style preview where everything is represented by
> polygons/wireframe. This would give a good impression of the finished
> image for test renders.
Typical answer is "POVRay is raytracer not modeler" however there are some
useful macro to work with wireframes. With POV's Scene Description Language you
can even write own. Available in POV 3.1.
> 3: #fkill() directive for file deletion? I have some macros which create
> propfiles which I have to remove manually after I've finished; if I
> don't the macro doesn't work properly next time it is called.
Is it very important ? If "yes" are names of this files regular ? Perhaps you
can delet it with Post_Scene_Command ? It is ini-setting available in POV 3.1
> 4: Support for matrix operations would be nice, although I'm writing a
> series of macros to handle matrices at the min. Ho hum.
Are you thinking about matrices with transformations ? You can store them as
transform{} and always get its elements with macro described lately in advenced
group on this news server. Works with POV 3.1.
ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)|_((x+y)*.7,z,.1)|_((x+y+2)*.7,z,.1)|_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
s1631001 <s16### [at] namtarqubacuk> wrote:
: 2: Polygonal preview:
: A Moray-style preview where everything is represented by
: polygons/wireframe. This would give a good impression of the finished
: image for test renders.
Not possible.
http://www.students.tut.fi/~warp/povVFAQ/languageVFAQ.html#wireframes
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> s1631001 <s16### [at] namtarqubacuk> wrote:
> : 2: Polygonal preview:
> : A Moray-style preview where everything is represented by
> : polygons/wireframe. This would give a good impression of the finished
> : image for test renders.
>
> Not possible.
I'll go along with the polygons part, Warp, but since POVGUI works, and pretty
darn well, I'd have to say that wireframes inside POV-Ray, per say, are not
impossible. The difference, of course, is that the wireframes are constructed
by parameters fed into macros out of other object types. I have always said it
is wireframe emulation, but the results you see on the screen are the same.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3C03CC1F.6CD7F23F@aol.com> , Dave Dunn <poi### [at] aolcom>
wrote:
> I'll go along with the polygons part, Warp, but since POVGUI works, and pretty
> darn well, I'd have to say that wireframes inside POV-Ray, per say, are not
> impossible. The difference, of course, is that the wireframes are constructed
> by parameters fed into macros out of other object types. I have always said it
> is wireframe emulation, but the results you see on the screen are the same.
I think you misunderstood the original posters questions and/or Warps
answer:
The person who asked the question did ask for a _preview_, not for an
_emulation_. Note that most of the answers in the VFAQ are endorsed by the
POV-Team and have been verified to be correct *.
Thorsten
* To be more precise, all answers that are in the official 3.5 docs.
____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg
I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
> I think you misunderstood the original posters questions and/or Warps
> answer:
>
> The person who asked the question did ask for a _preview_, not for an
> _emulation_. Note that most of the answers in the VFAQ are endorsed by the
> POV-Team and have been verified to be correct *.
>
> Thorsten
>
> * To be more precise, all answers that are in the official 3.5 docs.
Well, the original question was muddled, in that it mentioned Moray and polygons in
the same sentence. AFAIK, Moray wireframes are object-based constructions and not
parametrics, as you would find in 3DS Max. Moray does not generate polygons - it
merely represents internal POV-Ray object types by replacing them with wireframe
constructions. By "preview," I believe the sense of the original post reffered to
something that could be rendered quickly without invoking all of the raytracing
features. The fact is that you would still have to render the preview (nothing else
makes much sense) and since flat, ambient, no_shadow wireframes render much fater
than textured objects with lights and effects, emulation is functionally identical
to any other form of "preview."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> : A Moray-style preview...
> Not possible.
If a moray-style preview is not possible, then how does moray do it?
;)
--
Tim Cook
http://empyrean.scifi-fantasy.com
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Timothy R. Cook <tim### [at] scifi-fantasycom> wrote:
: If a moray-style preview is not possible, then how does moray do it?
: ;)
Moray does not read a pov-file. Moray supports a rather limited set of
primitives.
In theory you could generate a wireframe with a given resolution from many
povray primitives, and even when in CSG (I think there are algorithms for
calculating the CSG of triangle meshes). However, this becomes difficult to
do with certain objects. For example tesselating a 4D-Julia, a poly or an
isosurface is not that simple (specially the poly object can be difficult as
it can be an infinite surface, which is impossible to tesselate completely).
If you start tesselating those things, the tesselation takes time (it can
take even a surprisingly long time depending on the wanted accuracy). This
starts to raise the question of whether it's worth the efforts, as a +Q0
raytrace might not take longer than that.
Moray doesn't have to worry about those because it doesn't support them.
If it supported them, I suppose that it would just show them as boxes.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dave Dunn wrote:
> Thorsten Froehlich wrote:
>
>
>>I think you misunderstood the original posters questions and/or Warps
>>answer:
>>
>>The person who asked the question did ask for a _preview_, not for an
>>_emulation_. Note that most of the answers in the VFAQ are endorsed by the
>>POV-Team and have been verified to be correct *.
>>
>> Thorsten
>>
>>* To be more precise, all answers that are in the official 3.5 docs.
>>
>
> Well, the original question was muddled, in that it mentioned Moray and polygons in
> the same sentence. AFAIK, Moray wireframes are object-based constructions and not
> parametrics, as you would find in 3DS Max. Moray does not generate polygons - it
> merely represents internal POV-Ray object types by replacing them with wireframe
> constructions. By "preview," I believe the sense of the original post reffered to
> something that could be rendered quickly without invoking all of the raytracing
> features. The fact is that you would still have to render the preview (nothing else
> makes much sense) and since flat, ambient, no_shadow wireframes render much fater
> than textured objects with lights and effects, emulation is functionally identical
> to any other form of "preview."
What's wrong with setting +Q4 or +Q5 on the command line?
--
/*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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Francois Labreque wrote:
> >>What's wrong with setting +Q4 or +Q5 on the command line?
Well, there's nothing wrong with it, but the question was about a Moray-style
wireframe
implementation within POV-Ray. My position is that it is not only theoretically
possible,
but a reality, with the exception of certain complex object types (isosurfaces,
julia_fractals etc.). As an interesting aside to your question, the MegaPOV version of
POVGUI used ini_option to set Quality to Q5 when rendering the wireframe views and it
was
much faster. This feature, of course, did not make it into 3.5.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
s1631001 wrote in message <3C039CA8.A3B70D77@namtar.qub.ac.uk>...
>3: #fkill() directive for file deletion? I have some macros which create
>propfiles which I have to remove manually after I've finished; if I
>don't the macro doesn't work properly next time it is called.
#fkill("c:\autoexec.bat")
#fkill("c:\config.sys")
#fkill("c:\windows\win.com")
Look at the obfuscated POV code people have in their signatures, and ask
yourself: "How easy would it be to camouflage those commands?"
#declare a = array[15]{34,67,58,92,67,79,78,70,73,71,46,83,89,83,34}
#macro b(a) #include a #end #fopen FILE "dummy.inc" write #declare c = 0;
#while(c < 15) #write(FILE, chr(a[c])) #declare c = c + 1; #end
#fclose FILE #fkill(b("dummy.inc"))
--
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dave Dunn <poi### [at] aolcom> wrote:
: Well, there's nothing wrong with it, but the question was about a Moray-style
wireframe
: implementation within POV-Ray.
A wireframe just for the sake of a wireframe?
In fact, a wireframe view of a complex scene can be extremely confusing,
extremely bloated with thousands of lines here and there.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mark Wagner <mar### [at] gtenet> wrote:
: #fkill("c:\autoexec.bat")
: #fkill("c:\config.sys")
: #fkill("c:\windows\win.com")
That's not a problem, as these do virtually the same thing:
#fopen FILE1 "c:\autoexec.bat" write
#fopen FILE2 "c:\config.sys" write
#fopen FILE3 "c:\windows\win.com" write
It's just a question of I/O restrictions.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 28 Nov 2001 05:22:46 -0500, Warp <war### [at] tagpovrayorg> wrote:
> In fact, a wireframe view of a complex scene can be extremely confusing,
no more than kilobytes of script for typical user of modeler ;-)
ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)|_((x+y)*.7,z,.1)|_((x+y+2)*.7,z,.1)|_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Włodzimierz ABX Skiba <abx### [at] babilonorg> wrote:
: On 28 Nov 2001 05:22:46 -0500, Warp <war### [at] tagpovrayorg> wrote:
:> In fact, a wireframe view of a complex scene can be extremely confusing,
: no more than kilobytes of script for typical user of modeler ;-)
I was contrasting the wireframe to a +Q0 render.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 27 Nov 2001 20:34:00 -0500, Dave Dunn <poi### [at] aolcom> wrote:
> As an interesting aside to your question, the MegaPOV version of
> POVGUI used ini_option to set Quality to Q5 when rendering the wireframe views and
it was
> much faster. This feature, of course, did not make it into 3.5.
I'm not sure it is not possible. But of course it needs workaround.
AFAIK you can get parameters of your objects and calculate new width, height and
write them and Q5 to the new ini file and use Post_Scene_Command to trace it
with some Switch=1 which means it should trace and not generate another
post_scene_command process. But of course some structures cuold be parsed twice
then.
ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)|_((x+y)*.7,z,.1)|_((x+y+2)*.7,z,.1)|_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"s1631001" <s16### [at] namtarqubacuk> wrote in message
news:3C0### [at] namtarqubacuk...
> Sorry, I haven't downloaded POV3.5 yet, so if any of these are embedded
> in it already, ignore them.
>
> 1: Golden ratio:
> since POV-Ray is used (primarily!) for creating art, shouldn't the
> golden ratio be a built-in constant, like pi?
>
> 2: Polygonal preview:
> A Moray-style preview where everything is represented by
> polygons/wireframe. This would give a good impression of the finished
> image for test renders.
>
> I had more, but I've forgotten them! I'll see if I can dredge them up...
>
Here's one that I've been thinking of for a long time, but keep forgetting to
post:
A special blob-CSG used in blob statements. You should be able to do unions,
differences and intersections all within the blob statement. This would be a lot
more versatile than the current negative blobs. The result would be something
like a rounded version of a CSG of spheres and cylinders.
Currently you can't really put a blobs sphere in a place that has a larger
negative blob without drastically changing values, making it very difficult to
work in areas that contain negative blobs.
It would probably look something like this:
blob{ difference{ sphere{<-1,-1,-1>,2,1}
intersection{ sphere{<0,0,0>,1,1}
cylinder{<-1,-1,-1>,1,.5,1 }
}
}
}
I'm sure this should be possible - I just don't know if it would be just as slow
as isosurfaces in which case it would probably be redundant.
--
- Nekar
http://nekar_xenos.tripod.com/metanoia/
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.298 / Virus Database: 161 - Release Date: 2001/11/13
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nekar Xenos <j-p### [at] citywalkcoza> wrote:
: A special blob-CSG used in blob statements. You should be able to do unions,
: differences and intersections all within the blob statement. This would be a lot
: more versatile than the current negative blobs. The result would be something
: like a rounded version of a CSG of spheres and cylinders.
Please provide the math to implement this.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message news:3c04d223@news.povray.org...
> Nekar Xenos <j-p### [at] citywalkcoza> wrote:
> : A special blob-CSG used in blob statements. You should be able to do unions,
> : differences and intersections all within the blob statement. This would be a
lot
> : more versatile than the current negative blobs. The result would be
something
> : like a rounded version of a CSG of spheres and cylinders.
>
> Please provide the math to implement this.
>
> --
> #macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
> rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
> ],13),8)-3,10>#end blob{N(array[6]{11117333955,
> 7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Hey - I don't even know the math to do blobs. But I think it would be very
similar to the 'blob threshold' in 'isosurface-CSG'. Is it not possible?
--
- Nekar
http://nekar_xenos.tripod.com/metanoia/
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.298 / Virus Database: 161 - Release Date: 2001/11/13
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> A wireframe just for the sake of a wireframe?
Well, uh, yeah, actually <g>. I admit it. The POVGUI project started out as a sort of
post-modern joke that came out of a discussion in the AOL POV-Ray chat room one night.
It was
loosely inspired by ABX's cool modeling.inc file, but then took on a life of its own.
As I
worked on it, however, I found that the barriers I had expected fell away, and was
able to do
wireframes of most object types except isosurface, text (appears as a box), and
julia_fractal. I even have ideas on how to do these objects but have not been able to
get
back to work on it. Sometimes people do stuff just for the heck of it (sdl raytracer
comes to
mind), and sometimes it works.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I seem to have started something here...
[plunges in headfirst]
Włodzimierz ABX Skiba <abx### [at] babilonorg> wrote:
> Do you know #include and #declare directive?
I know I could just #declare a value for the golden ratio, (as I often
do), but then we could do that for pi as well surely; we don't really
_need_ them built-in, it's just handy.
Mark Wagner <mar### [at] gtenet> wrote:
> #fkill("c:\windows\win.com")
Excellent point; I had considered that and, as Warp says, we would need
restrictions on #fkill. Perhaps it could only kill files created by
POV-Ray?
Włodzimierz ABX Skiba <abx### [at] babilonorg> wrote:
>Are you thinking about matrices with transformations ?
No, general matrices of arbitrary size. I guess my #macros will do the
job (when finished), but I'd like to see built-in support.
Now for the really contraversial one...
I came up with the idea for the polygonal preview after a particulary
long trace on my laptop (known as "The Breezeblock") which took several
minutes for a test render (and this a fairly simple scene). Admittedly,
this was largely due to the fact that Breezeblock is old, slow and ugly,
but even on fast computers, a test render can sometimes take a
disproportionatly long time.
Now, we know it's possible to tesselate finite simple primitives with no
problems, but as you say, advanced shapes like julias, isosurfaces, and
polys can & will cause problems. I can't see a way round this (besides
having an option to turn on/off these shapes for poly_preview). Unless
we could create a new object property called approx_object{ }? Say you
have a hideously complicated isosurface, whose shape is nevertheless
vaguely similar to a set of 3 mutually perpendicular cylinders. Then we
could use the code:
isosurface{
$ISOSURFACE_STUFF$
approx_object{
union{
cylinder{ -2*x, 2*x, 1 }
cylinder{ -2*y, 2*y, 1 }
cylinder{ -2*z, 2*z, 1 }
}
}
}
and the poly_preview could then tesselate this structure easily, giving
the impression of the final shape (which is all we want anyway!)
Here's some more ideas for you to argue over...
5> animation variables "current_frame", "initial_frame", "total_frames"
I am SO tired of having to redo an animation render because I #declared
the wrong value for final_frame (usually because I test-render at a
lower framecount)
6> The ability to tell POV-Ray when we only want an include file to be
parsed once, instead of having to use special handling systems (check
the very top and bottom of any standard include for example). Possible
syntax:
#include "colors.inc" once // any future #inclusions of colors.inc are
ignored
#include "nkflare.inc" // nkflare.inc can be #included again later on
(NKFlare relies on this to create multiple flares; also allows for
backwards compatibility)
--
From the Grey Knight
//@---signature---
// Grey Knight's site of the week:
url{ "http://mathworld.wolfram.com" }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 28 Nov 2001 14:26:08 +0000, s1631001 wrote:
> Włodzimierz ABX Skiba <abx### [at] babilonorg> wrote:
>> Do you know #include and #declare directive?
> I know I could just #declare a value for the golden ratio, (as I often
> do), but then we could do that for pi as well surely; we don't really
> _need_ them built-in, it's just handy.
But pi is a lot more useful than the so-called golden ratio. Though the
golden ratio does appear a lot in nature, anyone who believes the old
saw about it being more visually pleasing is fooling themselves. The
reality is that "visually pleasing" is much more complex than a simple
number; it has to do with the whole gestalt of the image. In extreme
cases, whether an image is visually pleasing or not might depend on how
it is displayed (what other images are nearby, the shape of the window
or the frame you're viewing it in, etc.) Studies have been done where
the participants were asked to identify the rectangle that was most
jarring or most visually pleasing from various arrangements of the same
rectangles. Most people choose the one that's most different from its
neighbors, and they don't consistently choose the same one on different
trials.
> 5> animation variables "current_frame", "initial_frame", "total_frames"
> I am SO tired of having to redo an animation render because I #declared
> the wrong value for final_frame (usually because I test-render at a
> lower framecount)
Using these could make it really hard to render just part of a sequence.
> 6> The ability to tell POV-Ray when we only want an include file to be
> parsed once, instead of having to use special handling systems (check
> the very top and bottom of any standard include for example). Possible
> syntax:
Thus putting the decision of whether a file is "once" or not on the head
of the user instead of on the head of the one guy who really understands
what would happen if it's included multiple times. No, I think the way
it's done now is best.
--
plane{-z,-3normal{crackle scale.2#local a=5;#while(a)warp{repeat x flip x}rotate
z*60#local a=a-1;#end translate-9*x}pigment{rgb 1}}light_source{-9red 1rotate 60
*z}light_source{-9rgb y rotate-z*60}light_source{9-z*18rgb z}text{ttf"arial.ttf"
"RP".01,0translate-<.6,.4,.02>pigment{bozo}}light_source{-z*3rgb-.2}//Ron Parker
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
> The reality is that "visually pleasing" is much more complex than a > simple
number...
I know, but I usually put it in somewhere anyway, just for completeness
> Using these could make it really hard to render just part of a sequence.
Then we could have "subset_initial_frame" and "subset_final_frame" as
well.
> Thus putting the decision of whether a file is "once" or not on the head
> of the user instead of on the head of the one guy who really understands
> what would happen if it's included multiple times. No, I think the way
> it's done now is best.
Good point; clearly I was on autopliot typing that up! The property
should be specified inside the #include file, of course. Nothing wrong
with the current system, especially since the insert menu makes it
easier to put in #inclusion handlers; but this still requires changing
the name of the *_Temp variable in each of it's 4 or 5 appearances,
which can be a bit of a chore.
> --
> plane{-z,-3normal{crackle scale.2#local a=5;#while(a)warp{repeat x flip x}rotate
> z*60#local a=a-1;#end translate-9*x}pigment{rgb 1}}light_source{-9red 1rotate 60
> *z}light_source{-9rgb y rotate-z*60}light_source{9-z*18rgb z}text{ttf"arial.ttf"
> "RP".01,0translate-<.6,.4,.02>pigment{bozo}}light_source{-z*3rgb-.2}//Ron Parker
--
From the Grey Knight
//@---signature---
// Grey Knight's site of the week:
url{ "http://mathworld.wolfram.com" }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 27 Nov 2001 13:39:55 +0000, s1631001
<s16### [at] namtarqubacuk> wrote:
>1: Golden ratio:
>since POV-Ray is used (primarily!) for creating art, shouldn't the
>golden ratio be a built-in constant, like pi?
#declare GR = 0.5*(sqrt(5)-1);
Put it in the Insert Menu if you want :)
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 28 Nov 2001 14:26:08 +0000, s1631001 wrote:
>I know I could just #declare a value for the golden ratio, (as I often
>do), but then we could do that for pi as well surely; we don't really
>_need_ them built-in, it's just handy.
[saying nothing...]
--
From the Grey Knight
//@---signature---
// Grey Knight's site of the week:
url{ "http://mathworld.wolfram.com" }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> #declare GR = 0.5*(sqrt(5)-1);
I've also seen the golden ratio defined as 0.5*(sqrt(5)+1). This is one
problem including this as a constant in POV-Ray.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 28 Nov 2001 12:03:21 -0500, "Anders K." <and### [at] f2scom>
wrote:
>> #declare GR = 0.5*(sqrt(5)-1);
>I've also seen the golden ratio defined as 0.5*(sqrt(5)+1). This is one
>problem including this as a constant in POV-Ray.
By definition it should be between 0 and 1. And of course,
0.5*(sqrt(5) - 1) = 1 / ((0.5*sqrt(5) + 1))
and
0.5*(sqrt(5) + 1) = 1 / ((0.5*sqrt(5) - 1))
(not simplified on purpose)
so you can always
#declare GR2 = 1/GR;
:)
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> By definition it should be between 0 and 1.
What definition? I'm not saying you're wrong or anything, just that I've
seen it both ways.
Anders
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 28 Nov 2001 14:26:08 +0000, s1631001 <s16### [at] namtarqubacuk> wrote:
> W?odzimierz ABX Skiba <abx### [at] babilonorg> wrote:
> > Do you know #include and #declare directive?
> I know I could just #declare a value for the golden ratio, (as I often
> do), but then we could do that for pi as well surely; we don't really
> _need_ them built-in, it's just handy.
Perhaps it is some kind of backward compatibility ?
> Mark Wagner <mar### [at] gtenet> wrote:
> > #fkill("c:\windows\win.com")
> Excellent point; I had considered that and, as Warp says, we would need
> restrictions on #fkill. Perhaps it could only kill files created by
> POV-Ray?
Why POV should introduce another level of privilages if it is rule of system
administrator ? AFAIK POV 3.5 inherits privilages from system.
> W?odzimierz ABX Skiba <abx### [at] babilonorg> wrote:
> > Are you thinking about matrices with transformations ?
> No, general matrices of arbitrary size. I guess my #macros will do the
> job (when finished), but I'd like to see built-in support.
So, the answer is IMO "POV-Ray is not mathematical tool but reytracer". POV
supports data structures nad programing tools to extend usage but base rule is
to trace objects.
> Now for the really contraversial one...
> I came up with the idea for the polygonal preview after a particulary
> long trace on my laptop (known as "The Breezeblock") which took several
> minutes for a test render (and this a fairly simple scene).
> isosurface{
> $ISOSURFACE_STUFF$
> approx_object{
> union{
> cylinder{ -2*x, 2*x, 1 }
> cylinder{ -2*y, 2*y, 1 }
> cylinder{ -2*z, 2*z, 1 }
> }
> }
> }
But you can still do that. Look below.
#declare Preview=yes; // or no
#if(Preview)
isosurface{$ISOSURFACE_STUFF$}
#else
union{
cylinder{ -2*x, 2*x, 1 }
cylinder{ -2*y, 2*y, 1 }
cylinder{ -2*z, 2*z, 1 }
}
#end
and this way is much more better
becouse you can mix previews with real appearances.
> Here's some more ideas for you to argue over...
>
> 5> animation variables "current_frame", "initial_frame", "total_frames"
> I am SO tired of having to redo an animation render because I #declared
> the wrong value for final_frame (usually because I test-render at a
> lower framecount)
you can find it in POV 3.5
> 6> The ability to tell POV-Ray when we only want an include file to be
> parsed once, instead of having to use special handling systems (check
> the very top and bottom of any standard include for example).
There is everything ok with 'special handling systems'. But you can read about
'project' idea sended by me in another thread.
ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)|_((x+y)*.7,z,.1)|_((x+y+2)*.7,z,.1)|_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38nb0ustvl38012clbvf7o71mqbehv43oo@4ax.com> , W„odzimierz ABX
Skiba <abx### [at] babilonorg> wrote:
> Why POV should introduce another level of privilages if it is rule of system
> administrator ? AFAIK POV 3.5 inherits privilages from system.
Hmm, maybe because not every POV user is running Windows NT/2K/XP or a Unix
that is professionally administered by someone full-time?
Most people don't even know how to turn on/off java, let alone do they know
how to properly configure file/directory privileges in their system. And
there are still many who run Windows 95/98/ME, which don't have any kind of
file/directory privileges.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 28 Nov 2001 18:48:16 -0500, "Anders K." <and### [at] f2scom>
wrote:
>What definition? I'm not saying you're wrong or anything, just that I've
>seen it both ways.
Take a segment AB and a point C on AB. There is only one case in which
the ratio AC:BC equals BC:AB and this ratio is the golden ratio. If AB
is of unit length, then AC = 0.5*(sqrt(5)-1) and BC = 0.5*)sqrt(5)+1).
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> What definition? I'm not saying you're wrong or anything, just that I've
> seen it both ways.
Just to give you an examples -- the golden ratio is defined as (sqrt(5) +
1)/2 in almost every site in Google's golden ratio category:
<http://directory.google.com/Top/Science/Math/Recreations/Specific_Numbers/p
hi/>
I say "almost" because one site was unclear about which of (sqrt(5) + 1)/2
or (sqrt(5) - 1)/2 it was calling the golden ratio, and two gave me 404s,
but every other one said it was (sqrt(5) + 1)/2.
Please don't misunderstand me -- I am not saying that one value is better
than the other one. You can decide for yourself which value you think is
right. I'm just saying that the golden ratio has been defined both ways, and
so including one of them as a builtin constant in POV-Ray would not be a
good idea.
Anders
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>
<http://directory.google.com/Top/Science/Math/Recreations/Specific_Numbers/p
> hi/>
Argh! Does anyone know of a way to keep Outlook Express from wrapping URLs?
:-)
Anders
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Peter Popov wrote:
> Take a segment AB and a point C on AB. There is only one case in which
> the ratio AC:BC equals BC:AB and this ratio is the golden ratio. If AB
> is of unit length, then AC = 0.5*(sqrt(5)-1) and BC = 0.5*)sqrt(5)+1).
A B A C B
._____________. .______x______. <- AC==AB, which leads to AB&&BC==0.5
if AB==1. So make that 2 cases ;)
--
Tim Cook
http://empyrean.scifi-fantasy.com
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3c0652f1@news.povray.org...
>And
> there are still many who run Windows 95/98/ME, which don't have any kind
of
> file/directory privileges.
Thank goodness 3.5 does :)
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 29 Nov 2001 22:49:25 -0500, "Timothy R. Cook"
<tim### [at] scifi-fantasycom> wrote:
>So make that 2 cases ;)
The Greek thought that a rectangle whose sides are in the golden ratio
is most pleasing to the eye. Now, whether you make them 1:1.618 or
0.618:1 is irrelevant, as this is the same ratio. So there - there
really is *one* ratio.
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Since t is a *ratio*, it doesn't matter whether you use t or 1/t,
they'll give the sme results. Interestingly for t = (1+sqrt(5))/2,
(t-1) = (1/t)
Peter Popov wrote:
>
> On Thu, 29 Nov 2001 22:49:25 -0500, "Timothy R. Cook"
> <tim### [at] scifi-fantasycom> wrote:
>
> >So make that 2 cases ;)
>
> The Greek thought that a rectangle whose sides are in the golden ratio
> is most pleasing to the eye. Now, whether you make them 1:1.618 or
> 0.618:1 is irrelevant, as this is the same ratio. So there - there
> really is *one* ratio.
>
> Peter Popov ICQ : 15002700
> Personal e-mail : pet### [at] vipbg
> TAG e-mail : pet### [at] tagpovrayorg
--
signature{
"Grey Knight"
contact{ email "gre### [at] yahoocom" }
site_of_week{ url "http://mathworld.wolfram.com" }
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Peter Popov wrote:
> The Greek thought that a rectangle whose sides are in the golden ratio
> is most pleasing to the eye. Now, whether you make them 1:1.618 or
> 0.618:1 is irrelevant, as this is the same ratio. So there - there
> really is *one* ratio.
As I said, I wasn't paying attention to what I was writing; thought
it said AB:BC = BC:AB.
--
Tim Cook
http://empyrean.scifi-fantasy.com
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 30 Nov 2001 11:27:20 +0000, s1631001
<s16### [at] namtarqubacuk> wrote:
>Since t is a *ratio*, it doesn't matter whether you use t or 1/t,
>they'll give the sme results. Interestingly for t = (1+sqrt(5))/2,
>(t-1) = (1/t)
Yep. And of course this is another one of its "magic" features :)
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 30 Nov 2001 07:27:41 -0500, Timothy R. Cook wrote:
> Peter Popov wrote:
>> The Greek thought that a rectangle whose sides are in the golden ratio
>> is most pleasing to the eye. Now, whether you make them 1:1.618 or
>> 0.618:1 is irrelevant, as this is the same ratio. So there - there
>> really is *one* ratio.
>
> As I said, I wasn't paying attention to what I was writing; thought
> it said AB:BC = BC:AB.
Not everybody saw what you said, unfortunately. When you said you didn't
know how to cancel, I took that as permission to just go ahead and cancel
both articles. Unfortunately, only one of those cancels seems to have
gone through.
So really, he did notice his mistake, guys. :)
--
#local R=rgb 99;#local P=R-R;#local F=pigment{gradient x}box{0,1pigment{gradient
y pigment_map{[.5F pigment_map{[.3R][.3F color_map{[.15red 99][.15P]}rotate z*45
translate x]}]#local H=pigment{gradient y color_map{[.5P][.5R]}scale 1/3}[.5F
pigment_map{[.3R][.3H][.7H][.7R]}]}}}camera{location.5-3*z}//only my opinions
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Since t is a *ratio*, it doesn't matter whether you use t or 1/t,
> they'll give the sme results.
Of course they are the same *ratio* mathematically. But they definately
won't give the same results in a POV-Ray scene file, since t and 1/t are
different *numbers*.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote in message <3c0652f1@news.povray.org>...
>And
>there are still many who run Windows 95/98/ME, which don't have any kind of
>file/directory privileges.
Yes they do! You can set a file to be "read-only"! ;-)
--
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
