 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mark Wagner <mar### [at] gte net> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
: 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]
> 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?
>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:
>> 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
|
|
| |
| |
|
|
|
|
| |
|
|
