"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

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