I just had an idea for an improvement to the POV-Ray scene language:

Get rid of all the object keywords except blob, julia_fractal, and poly.

This would not prevent the use of the other types of shapes, as all of the
other shapes can be created from these basic types using only the
'intersection', 'union', and 'inverse' keywords.

Doing this has many advantages:

First, it will make learning the language much easier.  By reducing the
number of object type keywords from 23 to 4, plus the CSG keywords
intersection and union.  All the other objects can be constructed from these
basic objects.

Second, it will reduce the time spent by the computer parsing the scene
files.  With the reduced number of keywords, the POV-Ray parser will have a
smaller list of words to check against, resulting in faster parsing and
quicker detection of syntax errors.

Third, this would make writing utilities to convert to or, primarily, from
the POV-Ray format significantly easier, as the programmer would have fewer
object types to contend with.

With all the benefits that implementing this proposal would provide, I
strongly urge the POV-Team to pursue this course of action.

Mark

Post a reply to this message

On Wed, 30 Jun 1999 01:59:46 -0400, "Mark Wagner"
<mar### [at] gtenet> wrote:

>I just had an idea for an improvement to the POV-Ray scene language:
>
>Get rid of all the object keywords except blob, julia_fractal, and poly.
>
>This would not prevent the use of the other types of shapes, as all of the
>other shapes can be created from these basic types using only the
>'intersection', 'union', and 'inverse' keywords.

What about planes, triangles, and meshes? (Not to be confused with a
comedy staring Steve Martin and John Candy.) Can these really be
created with only the object types you mention?

Incidently, for a "modest" proposal, this sounds pretty radical to me.

Post a reply to this message

I'm pretty sure it was a joke - I was going to reply, but folks like Lance
Birch own all the rights to the responses I wanted to use.

Post a reply to this message

In article <3779c698@news.povray.org> , "Edward C." 
<edw### [at] hotmailcom> wrote:

> I'm pretty sure it was a joke - I was going to reply, but folks like Lance
> Birch own all the rights to the responses I wanted to use.

I agree, this most be a joke.


    Thorsten

Post a reply to this message

Um, you're an escapee from a mental institution???

You MUST be joking right?  Come on, seriously :)  You must be... are you?

haha, yeah...

he he he™

--
Lance.

(if that's modest I'd hate to see what you'd call revolutionary)

---
For the latest 3D Studio MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone
For a totally different experience, visit my Chroma Key Website:
Colorblind - http://listen.to/colorblind

Post a reply to this message

In povray.general Mark Wagner <mar### [at] gtenet> wrote:
: Second, it will reduce the time spent by the computer parsing the scene
: files.

  But it certainly will increase drastically the time spent tracing the
scene.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

And I thought everyone realised CSGs were slow ;-)

--
Lance.


---
For the latest 3D Studio MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone
For a totally different experience, visit my Chroma Key Website:
Colorblind - http://listen.to/colorblind
Nieminen Mika wrote in message <3779dc83@news.povray.org>...
>In povray.general Mark Wagner <mar### [at] gtenet> wrote:
>: Second, it will reduce the time spent by the computer parsing the scene
>: files.
>
>  But it certainly will increase drastically the time spent tracing the
>scene.
>
>--
>main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
>):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Perhaps this is a modest proposal after the model of Swift.  That, or
the author needs to cut back on the math classes a little bit.  If that
isn't possible, an algorithms class may be in order.  The elegant
solution is not necessarily the most efficient.

-- 
Mark Gordon
mtg### [at] povrayorg

Post a reply to this message

On Wed, 30 Jun 1999 07:01:26 GMT, Glen Berry wrote:
>On Wed, 30 Jun 1999 01:59:46 -0400, "Mark Wagner"
><mar### [at] gtenet> wrote:
>
>>I just had an idea for an improvement to the POV-Ray scene language:
>>
>>Get rid of all the object keywords except blob, julia_fractal, and poly.
>>
>>This would not prevent the use of the other types of shapes, as all of the
>>other shapes can be created from these basic types using only the
>>'intersection', 'union', and 'inverse' keywords.
>
>What about planes, triangles, and meshes? (Not to be confused with a
>comedy staring Steve Martin and John Candy.) Can these really be
>created with only the object types you mention?

A plane is a simple poly. A triangle is (sort of) an intersection of planes, 
though to get it right I think you'd still need clipped_by.  A mesh is just a 
union of a bunch of triangles.  But I'd like to see the code that replaces a 
text object (it is possible, though insanely ugly, and it only requires polys 
of degree 3 and lower.)

Oh, and you don't need inverse for anything but blobs or julias, either,  as 
flipping the sign of the poly accomplishes the same thing.

And while we're at it, let's get rid of area_light, since you can fake it with 
a grid of point light sources.  And we can get rid of either the matrix keyword 
or the rotate, translate, and scale keywords.  And we don't need color_map 
because you can do that with a pigment_map, but we don't need pigment_map 
because you can do THAT with a texture_map.  We don't need the checker, bricks, 
or hexagons patterns, because they can be synthesized with various gradients 
and the repeat warp.  I believe the repeat warp itself can be synthesized with 
various gradients, so long as you only use rational offsets (and all numbers 
are rational in a computer, so...)  We don't need marble, because it's just a 
texture_map of a couple of gradients.

I'm sure there's more stuff we can eliminate in our quest for syntactic purity
and orthogonality.  I mean, what's the point in doing this if you're only going 
to go halfway?  I say Mark's idea would only be good for slackers.

Oh, and pretend there's a HUGE smiley face at the end of this post, just as 
y'all should have at the end of Mark's post.

Post a reply to this message

Mark Wagner wrote:
> 
> I just had an idea for an improvement to the POV-Ray scene language:
> 
> Get rid of all the object keywords except blob, julia_fractal, and poly.

Why complicate things with such slow primitives. Each of your chosen objects
are difficult to compute and are slow to render. I propose instead reverting
to a simple phong shaded triangle rendering system. This would make realtime
raytracing possible and the are no shapes that cannot be represented with
triangles.

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

Glen Berry wrote:

> On Wed, 30 Jun 1999 01:59:46 -0400, "Mark Wagner"
> <mar### [at] gtenet> wrote:
>
> >I just had an idea for an improvement to the POV-Ray scene language:
> >
> >Get rid of all the object keywords except blob, julia_fractal, and poly.
> >
> >This would not prevent the use of the other types of shapes, as all of the
> >other shapes can be created from these basic types using only the
> >'intersection', 'union', and 'inverse' keywords.
>
> What about planes, triangles, and meshes? (Not to be confused with a
> comedy staring Steve Martin and John Candy.) Can these really be
> created with only the object types you mention?
>
> Incidently, for a "modest" proposal, this sounds pretty radical to me.

YHBT. YHL. HAND.

Simon
http://home.istar.ca/~sdevet

PS. For all you non Kibologists out there, this stands for "You have been
trolled. You have lost. Have a nice day."

PPS. Everyone is a Kibologist.

Post a reply to this message

Mark Wagner wrote:
> I just had an idea for an improvement to the POV-Ray scene language:
>
> Get rid of all the object keywords except blob, julia_fractal, and poly.
>
> This would not prevent the use of the other types of shapes, as all of the
> other shapes can be created from these basic types using only the
> 'intersection', 'union', and 'inverse' keywords.

What ever you are smoking you should quit using it...

/Anders

Post a reply to this message

7no### [at] ezwvcom (Glen Berry) wrote:
> <mar### [at] gtenet> wrote:
>
>>I just had an idea for an improvement to the POV-Ray scene language:
>
> Incidently, for a "modest" proposal, this sounds pretty radical to me.

It's an allusion to Jonathan Swift's 1729 treatise, the full title of
which was "A Modest Proposal for Preventing the Children of Poor People
from Being a Burden to their Parents or the Country".

Swift's proposal was also satire.


-- 
Jeff Lee         shi### [at] gatenet         http://www.gate.net/~shipbrk/

Post a reply to this message

On Wed, 30 Jun 1999 01:59:46 -0400, "Mark Wagner"
<mar### [at] gtenet> wrote:

Pretty Swift-styled, no? :)


Peter Popov
ICQ: 15002700

Post a reply to this message

Ron Parker wrote:
> 
> 
> And while we're at it, let's get rid of area_light, since you can fake it with
> a grid of point light sources.  
No, you can't. Using area_light affects only the way, how shadows are
calculated, object's illumination is same as with one light source. I
didn't knew it before and I wanted to use area_light for rendering
lightning from computer screen. No matter how many lights I specified
for grid, object's illumination was still same. Only RTFM helped me out
and I created grid of point lights instead.

Post a reply to this message

On Thu, 01 Jul 1999 14:39:54 +0300, Vahur Krouverk wrote:
>Ron Parker wrote:
>> 
>> 
>> And while we're at it, let's get rid of area_light, since you can fake it with
>> a grid of point light sources.  
>No, you can't. Using area_light affects only the way, how shadows are
>calculated, object's illumination is same as with one light source.

I actually knew that when I wrote it, but since I consider that "feature"
of area lights to be broken, I ignored it. :)

Post a reply to this message

Mark Wagner wrote:

> Doing this has many advantages:
> 
> First, it will make learning the language much easier.  By reducing the
> number of object type keywords from 23 to 4, plus the CSG keywords
> intersection and union.  All the other objects can be constructed from these
> basic objects.

Do you really think so? I think using the box keyword is much easier,
and
much easier to learn than using a poly with all its parameters.
 
> Second, it will reduce the time spent by the computer parsing the scene
> files.  With the reduced number of keywords, the POV-Ray parser will have a
> smaller list of words to check against, resulting in faster parsing and
> quicker detection of syntax errors.

Well, parsing time is not very often the longer time, when tracing an
image.
 
> Third, this would make writing utilities to convert to or, primarily, from
> the POV-Ray format significantly easier, as the programmer would have fewer
> object types to contend with.

If you have problems with that, why dont you have tools like yacc or
bison
doing this job for you? They come free with every Linux distribution and
make
creating a parser an much easyer job.

Perhaps the language would be easier to be read by computers, but IMHO
it
would never be human readable.

> With all the benefits that implementing this proposal would provide, I
> strongly urge the POV-Team to pursue this course of action.
> 
> Mark

Jojo

Post a reply to this message

You are a very sad man.  I suggest you find help.

H.E. Day

Post a reply to this message

Ken wrote:

> Why complicate things with such slow primitives. Each of your chosen objects
> are difficult to compute and are slow to render. I propose instead reverting
> to a simple phong shaded triangle rendering system. This would make realtime
> raytracing possible and the are no shapes that cannot be represented with
> triangles.
>
> --
> Ken Tyler

Please, don't let POV be a triangle-based renderer!!! That's a big reason I
choose pov over over such raytracers as RayDream!!!

Post a reply to this message

Attachments:
Download 'us-ascii' (1 KB)

"SamuelT." wrote:

> Please, don't let POV be a triangle-based renderer!!! That's a big reason I
> choose pov over over such raytracers as RayDream!!!

  I was jesting. Making a joke. I was not serious. I was lying. I don't
want Pov to revert to a phong shaded triangle rendering system. I was
pulling your leg. Do not believe my sincerity. Ain't gonna happen. Never
had it never will. Hades will freeze over first. Don't worry be happy :)
I withdraw my suggestion. Long live all primitve types and may even more
be added in the future. A rolling stone gathers no moss.

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

Mark Wagner wrote:
> 
> I just had an idea for an improvement to the POV-Ray scene language:
> 
> Get rid of all the object keywords except blob, julia_fractal, and poly.

Mark,

  I have yet to see a single rebuttal on your part concerning some of the
responses to this thread that you started. Were you simply bored and
thought you would stir people up or were you in fact serious about this
wild unorthodox proposal of yours ?

Stand and be heard by your peers !

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

> Get rid of all the object keywords except blob, julia_fractal, and poly.

This is certainly a start.  However, as has already been mentioned, this is
simply not enough simplification.  My modest proposal is as follows:
Remove all primitives and replace them with a single 'line' primitive, in the
form of:
line {
  <x1,y1,z1>,<x2,y2,z2>
}
Lines have huge amounts of versatility, far more than even triangles.  What is
more, they simplify and speed up renders by astronomical proportions!  There are
only two conditions; either a ray hits the line, or it doesn't.  Gone is all of
the fussing with normals or even textures.  As a line is infinitely thin, the
chance of a ray hitting it is infinitely small, and thus the number of ray
intersections will be _drastically_ reduced.  This will in turn increase the
rendering speed, dare I say *PAST* the speed of real-time rendering!  With LORT,
(Line-Only Ray Tracing) and LO-Ray (Line-Only Raytracer) it would be
theoretically possible to raytrace faster than the speed of light, making time
travel possible.  The masterpieces that could be created can only be begun to be
imagined.
-Alex Vandiver

/--------------------------------------------\
|    Join the LO-Ray (Line-Only Raytracer)   |
| project today by pressing the power button |
| on your monitor, or look on the web at the |
|    amazing graphics possible, at http://   |
\--------------------------------------------/

Post a reply to this message

Thank goodness!!!

Ken wrote:

> "SamuelT." wrote:
>
> > Please, don't let POV be a triangle-based renderer!!! That's a big reason I
> > choose pov over over such raytracers as RayDream!!!
>
>   I was jesting. Making a joke. I was not serious. I was lying. I don't
> want Pov to revert to a phong shaded triangle rendering system. I was
> pulling your leg. Do not believe my sincerity. Ain't gonna happen. Never
> had it never will. Hades will freeze over first. Don't worry be happy :)
> I withdraw my suggestion. Long live all primitve types and may even more
> be added in the future. A rolling stone gathers no moss.
>
> --
> Ken Tyler
>
> mailto://tylereng@pacbell.net

Post a reply to this message

Attachments:
Download 'us-ascii' (1 KB)

Ken wrote in message <377A2299.8056D310@pacbell.net>...
>
>Mark Wagner wrote:
>>
>> I just had an idea for an improvement to the POV-Ray scene language:
>>
>> Get rid of all the object keywords except blob, julia_fractal, and poly.
>I propose instead reverting
>to a simple phong shaded triangle rendering system. This would make
realtime
>raytracing possible and the are no shapes that cannot be represented with
>triangles.


Phong-shaded triangles - isn't that what AutoCad release 12 uses?  It looks
truly awful.

Mark

Post a reply to this message

Mark Wagner <mar### [at] gtenet> wrote in message
news:3779b282@news.povray.org...
> I just had an idea for an improvement to the POV-Ray scene language:
>
> Get rid of all the object keywords except blob, julia_fractal, and poly.

Another (more serious) suggestion would be to eliminate all the internal
object types in favor of a single highly optimized primitive (say
triangles).  You can still have the higher level primitives at the level of
the input language, but convert them (lazily, and perhaps with caching) into
triangles for the purpose of tracing.   Having a single underlying geometric
representation allows you to concentrate your effort on producing a highly
optimized set of routines that benefit all scenes.

Mark

Post a reply to this message

Egad man! All triangles?! No way! I'd have to put POV-Ray on the shelf
if it were done that way. The non-meshed primitives in POV-Ray are my
favorite things. And please, no one tell me that is how they really are
done, you know, internally within the render engine, okay? I'd hate to
hear it if so.

Bob

Mark VandeWettering wrote:
> 
> Another (more serious) suggestion would be to eliminate all the internal
> object types in favor of a single highly optimized primitive (say
> triangles).  You can still have the higher level primitives at the level of
> the input language, but convert them (lazily, and perhaps with caching) into
> triangles for the purpose of tracing.   Having a single underlying geometric
> representation allows you to concentrate your effort on producing a highly
> optimized set of routines that benefit all scenes.
> 
> Mark

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/homepage.htm
 mailto://inversez@aol.com?Subject=PoV-News

Post a reply to this message

Bob Hughes wrote in message <379A68AA.E643AC11@aol.com>...
>Egad man! All triangles?! No way! I'd have to put POV-Ray on the shelf
>if it were done that way. The non-meshed primitives in POV-Ray are my
>favorite things. And please, no one tell me that is how they really are
>done, you know, internally within the render engine, okay? I'd hate to
>hear it if so.


It is NOT.

Mark

Post a reply to this message

Insert sigh of relief here =>


Mark Wagner wrote:
> 
> Bob Hughes wrote in message <379A68AA.E643AC11@aol.com>...
> >Egad man! All triangles?! No way! I'd have to put POV-Ray on the shelf
> >if it were done that way. The non-meshed primitives in POV-Ray are my
> >favorite things. And please, no one tell me that is how they really are
> >done, you know, internally within the render engine, okay? I'd hate to
> >hear it if so.
> 
> It is NOT.
> 
> Mark

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/homepage.htm
 mailto://inversez@aol.com?Subject=PoV-News

Post a reply to this message

Bob Hughes <inv### [at] aolcom> wrote in message
news:379A68AA.E643AC11@aol.com...
> Egad man! All triangles?! No way! I'd have to put POV-Ray on the shelf
> if it were done that way. The non-meshed primitives in POV-Ray are my
> favorite things.
<snip>

I agree with you there, Bob.

Andy

Post a reply to this message

On Sat, 24 Jul 1999 20:30:18 -0500, Bob Hughes <inv### [at] aolcom>
wrote:

>Egad man! All triangles?! No way! I'd have to put POV-Ray on the shelf
>if it were done that way. The non-meshed primitives in POV-Ray are my
>favorite things. And please, no one tell me that is how they really are
>done, you know, internally within the render engine, okay? I'd hate to
>hear it if so.

I have to say that for my part I at least partly agree with Mark.  POV
already decomposes at least some objects into triangles (bicubic
patches and heightfields)  It would be nice if it were possible to 
decompose every object into triangles to within specified tolerances
for the simple reason that implementing things like displacement 
mapping, OpenGL preview, and export to certain other formats (e.g.
3DS) would then be possible.  On the other hand, I'm not of the
opinion that POV should be made to ALWAYS use triangles.  For example,
it seems unlikely that you could render a sphere-of-triangles as
quickly as you can currently render the mathematical sphere.

And then there's the notion that we should just listen to whatever
Mark has to say just because he's the one saying it.  He is the man
responsible for the MTV raytracer, oh so long ago (has it really 
been over ten years?) and he currently works for Pixar, so he probably
knows what he's talking about.

Post a reply to this message

> 
> Another (more serious) suggestion would be to eliminate all the internal
> object types in favor of a single highly optimized primitive (say
> triangles).  You can still have the higher level primitives at the level of
> the input language, but convert them (lazily, and perhaps with caching) into
> triangles for the purpose of tracing.   Having a single underlying geometric
> representation allows you to concentrate your effort on producing a highly
> optimized set of routines that benefit all scenes.
> 
> Mark
Ahem... Ehh... Why does 3DS scream in my eyes when I read this? *sighs*
The basic idea of pov is a raytracer, not a cheap hack at a mesh
handler... 


//Spider
--Nothing matters anymore.

Post a reply to this message

In povray.general Ron Parker <par### [at] fwicom> wrote:
:   It would be nice if it were possible to 
: decompose every object into triangles to within specified tolerances

  Is it possible for any object type in povray?
  What about the infinite objects (planes, polys...)? How do you make an
infinite triangle?
  What about csg?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Nieminen Mika wrote:
> 
> In povray.general Ron Parker <par### [at] fwicom> wrote:
> :   It would be nice if it were possible to
> : decompose every object into triangles to within specified tolerances
> 
>   Is it possible for any object type in povray?
>   What about the infinite objects (planes, polys...)? How do you make an
> infinite triangle?
>   What about csg?

  Wouldn't it also add greatly to the memory overhead for the program. I
recall reading that the reason the developers of pov originally decided to
use the mathematically derived primitives unlike the triangle model is because
it is both faster and less memory intensive to create. 3ds max to create
an equivalent smooth sphere without using surface normal smoothing requires
1000's of triangles to represent. It would surely limit the number of
objects you could include in your scene if you had low memory on your system
and even those with more memory would max out rather quickly with only 10's
to a few hundred objects. I'm not saying you shouldn't or can't add this
feature though I wonder at it's usefulness.



-- 
Ken Tyler
  
mailto://tylereng@pacbell.net
http://home.pacbell.net/tylereng/links.htm

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote in message
news:379C02D6.1A51296D@pacbell.net...
>   Wouldn't it also add greatly to the memory overhead for the program. I
> recall reading that the reason the developers of pov originally decided to
> use the mathematically derived primitives unlike the triangle model is
because
> it is both faster and less memory intensive to create. 3ds max to create
> an equivalent smooth sphere without using surface normal smoothing
requires
> 1000's of triangles to represent. It would surely limit the number of
> objects you could include in your scene if you had low memory on your
system
> and even those with more memory would max out rather quickly with only
10's
> to a few hundred objects. I'm not saying you shouldn't or can't add this
> feature though I wonder at it's usefulness.
>

I agree with you Ken. I often use POV to create scenes with many tens of
thousands of spheres (using Biowin) , and from my experience there's *no
way* that I'd be able to use more than a few hundred spheres in a mesh based
program. As far as I'm concerned, it's the use of mathematically defined
primitives, along with the procedural textures that make POV so great.

Andy

Post a reply to this message

In povray.programming Andrew Cocker <and### [at] acockerfreeservecouk> wrote:
: I agree with you Ken. I often use POV to create scenes with many tens of
: thousands of spheres (using Biowin) , and from my experience there's *no
: way* that I'd be able to use more than a few hundred spheres in a mesh based
: program. As far as I'm concerned, it's the use of mathematically defined
: primitives, along with the procedural textures that make POV so great.

  Actually, if you had defined one mesh object, which is the sphere, and
then spread tens of thousands of copies of that declared mesh (scaling,
rotating, translating and texturing them), memory consumption would not be
very high.
  If each one of the spheres had to be a _different_ mesh (like having
different number of spikes all of them), then the memory consumption would
be prohibitive.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On 26 Jul 1999 02:26:48 -0400, Nieminen Mika wrote:
>In povray.general Ron Parker <par### [at] fwicom> wrote:
>:   It would be nice if it were possible to 
>: decompose every object into triangles to within specified tolerances
>
>  Is it possible for any object type in povray?
>  What about the infinite objects (planes, polys...)? How do you make an
>infinite triangle?

Well, you're right there.  Other finite objects would be tough, too.  
Ferinstance, I don't want to think about the Julia object.  But it'd
be nice for the objects people actually tend to use. 

>  What about csg?

CSG probably isn't a problem.  It can be done, it's just a Simple
Matter of Programming.  Lots of programming, that is.

Post a reply to this message

On 26 Jul 1999 09:46:56 -0400, par### [at] fwicom (Ron Parker) wrote:

>Well, you're right there.  Other finite objects would be tough, too.  
>Ferinstance, I don't want to think about the Julia object.  But it'd
>be nice for the objects people actually tend to use. 

Ahem, just what are you trying to imply, Ron? For Pete's sake, I've
rendered more Julias than anything else (even spheres). Then again, I
might be nuts :)

Seriously, Pascal Massimino's page is hosted on povray.org . I think I
saw something about tesselating a Julia object there.

>>  What about csg?
>
>CSG probably isn't a problem.  It can be done, it's just a Simple
>Matter of Programming.  Lots of programming, that is.

:)
I second that. Most 3D packages (I'm talking scanline here) have some
sort of boolean operations.


Peter Popov
ICQ: 15002700

Post a reply to this message

Why testellate the Julia object? What do you want to do? Twist it? <g>

Margus

Peter Popov wrote:
> 
> On 26 Jul 1999 09:46:56 -0400, par### [at] fwicom (Ron Parker) wrote:
> 
> >Well, you're right there.  Other finite objects would be tough, too.
> >Ferinstance, I don't want to think about the Julia object.  But it'd
> >be nice for the objects people actually tend to use.
> 
> Ahem, just what are you trying to imply, Ron? For Pete's sake, I've
> rendered more Julias than anything else (even spheres). Then again, I
> might be nuts :)
> 
> Seriously, Pascal Massimino's page is hosted on povray.org . I think I
> saw something about tesselating a Julia object there.
> 
> >>  What about csg?
> >
> >CSG probably isn't a problem.  It can be done, it's just a Simple
> >Matter of Programming.  Lots of programming, that is.
> 
> :)
> I second that. Most 3D packages (I'm talking scanline here) have some
> sort of boolean operations.
> 
> Peter Popov
> ICQ: 15002700

Post a reply to this message

On Mon, 26 Jul 1999 20:55:45 +0300, Margus Ramst <mar### [at] peakeduee>
wrote:

>Why testellate the Julia object? What do you want to do? Twist it? <g>
>
>Margus

Implement it in Moray? <--G--> Export it to VRML and have a Realtime
Spinning Julia Frenzy party? Calculate the electrostatic field around
it? You name it...



Peter Popov
ICQ: 15002700

Post a reply to this message

Peter Popov wrote:
> 
> On Mon, 26 Jul 1999 20:55:45 +0300, Margus Ramst <mar### [at] peakeduee>
> wrote:
> 
> >Why testellate the Julia object? What do you want to do? Twist it? <g>
> >
> >Margus
> 
> Implement it in Moray? <--G--> Export it to VRML and have a Realtime
> Spinning Julia Frenzy party? Calculate the electrostatic field around
> it? You name it...

I would like to serve mine up with whip cream and strawberries...

-- 
Ken Tyler
  
mailto://tylereng@pacbell.net
http://home.pacbell.net/tylereng/links.htm

Post a reply to this message

A question:
  Is all this triangulation of objects worth the efforts? Ok, you get a
preview. So what? I think that there are many other things more important
for the povteam to do than worrying about previews. Making trianguation
code for _all_ the objects is not a trivial thing and the benefits are
questionable. If you want a preview, use a modeller.
  And besides, implementing an OpenGL or whatever preview would make povray
non-portable.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

haha, some of you just knew I was going to reply to this didn't you?  ;-)

>Ahem... Ehh... Why does 3DS scream in my eyes when I read this? *sighs*
>The basic idea of pov is a raytracer, not a cheap hack at a mesh
>handler...

Well, when it comes to 3DS, you're right, it SUCKS!  However, I must note
that there is a MASSIVE difference between 3D Studio and 3D Studio MAX.  3D
Studio isn't even considered a product any more (and it's not sold from
authorised dealers).

The fact is that meshes are extremely powerful and CAN produce perfect image
quality if the artist and the renderer are careful.  The introduction of
such techniques as NURBS and adaptive degradation make meshes perfectly
smooth (finally!!!).

So in conclusion, leave POV-Ray the way it is because as a raytracer it
ROCKS!  And second, please don't criticise renderers that you haven't used
the latest version of (for more than a month)  :)

hehe, OK, that's my 2 cents, feel free to flame me now.

--
Lance.


---
For the latest 3D Studio MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone
For a totally different experience, visit my Chroma Key Website:
Colorblind - http://listen.to/colorblind

Post a reply to this message

Once again, I must comment :)

>thousands of spheres (using Biowin) , and from my experience there's *no
>way* that I'd be able to use more than a few hundred spheres in a mesh
based
>program. As far as I'm concerned, it's the use of mathematically defined

Well actually I've done a scene with over 5 million triangles and it wasn't
that bad.  Actually just the other day I imported a protein model of 5000 or
so atoms and connections and it didn't really have a problem (took a few
minutes to load initially but after that there were no problems).

> it is both faster and less memory intensive to create. 3ds max to create
> an equivalent smooth sphere without using surface normal smoothing
> requires 1000's of triangles to represent

Very true for POV-Ray's architecture.  POV-Ray just wasn't meant to load
millions of triangles.  The number of triangles I usually use for a
geosphere (not a sphere, a geosphere, which is much more optimal) is about
200-800 or above if I need extra smoothness of the camera is particularly
close.  If it's a variable range thing, I just make the sphere a NURBS
surface and let the renderer figure it out :)

But of course once again, it depends on the program.  And once again, I must
say that I think POV-Ray should be left as it is.

--
Lance.


---
For the latest 3D Studio MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone
For a totally different experience, visit my Chroma Key Website:
Colorblind - http://listen.to/colorblind

Post a reply to this message

I AGREE!!!  :)

--
Lance.


---
For the latest 3D Studio MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone
For a totally different experience, visit my Chroma Key Website:
Colorblind - http://listen.to/colorblind
Nieminen Mika wrote in message <379d50a0@news.povray.org>...
>  A question:
>  Is all this triangulation of objects worth the efforts? Ok, you get a
>preview. So what? I think that there are many other things more important
>for the povteam to do than worrying about previews. Making trianguation
>code for _all_ the objects is not a trivial thing and the benefits are
>questionable. If you want a preview, use a modeller.
>  And besides, implementing an OpenGL or whatever preview would make povray
>non-portable.
>
>--
>main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
>):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

>I second that. Most 3D packages (I'm talking scanline here) have some
>sort of boolean operations.

hehe, from my experiance they're not very good either :)  Sure, it can be
done, but there are LOTS of problems associated with it.  This was
particularly true with MAX 1.2 and 2.0 (2.5 fixed it to most extents and it
works very well now).  But have you ever taken a mesh of a text object and
tried to do an intersection of it with another text object at 90 degrees?
(in a mesh program?)

That's the main problem, booleaning with meshes doesn't always work very
well.

--
Lance.


---
For the latest 3D Studio MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone
For a totally different experience, visit my Chroma Key Website:
Colorblind - http://listen.to/colorblind

Post a reply to this message

The answer, I think, has been discussed for quite a while.
Non-linear transformations is the main benefit I see. And not a small one at
that.

Margus

Nieminen Mika wrote:
> 
>   A question:
>   Is all this triangulation of objects worth the efforts? Ok, you get a
> preview. So what? I think that there are many other things more important
> for the povteam to do than worrying about previews. Making trianguation
> code for _all_ the objects is not a trivial thing and the benefits are
> questionable. If you want a preview, use a modeller.
>   And besides, implementing an OpenGL or whatever preview would make povray
> non-portable.
> 
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In povray.general Margus Ramst <mar### [at] peakeduee> wrote:
: Non-linear transformations is the main benefit I see. And not a small one at
: that.

  Then make all your objects with spatch or whatever modeller.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On 27 Jul 1999 02:24:32 -0400, Nieminen Mika <war### [at] cctutfi> wrote:

>  A question:
>  Is all this triangulation of objects worth the efforts? Ok, you get a
>preview. So what? I think that there are many other things more important
>for the povteam to do than worrying about previews. Making trianguation
>code for _all_ the objects is not a trivial thing and the benefits are
>questionable. If you want a preview, use a modeller.

(been out of town for a while)

I wasn't talking about _all_ objects. Heaven forbid! I was only
replying to Ron who said Julias can't be triangulated and then to
Margus who didn't see the sense in doing it. So I mentioned the major
beneft of tesellating this particular object, mainly implementing it
in Moray and other modellers since it is a shape that's hard to
visualize by only knowing the numbers involved. And once you have it
as a mesh in a modeller you can export it to whatever format you like,
so that even Lance can have some fun of it with MAX :) Or, as I
(humorously?) suggested, you can export it to VRML, put a motherload
of colored lights around it and start spinning it realtime until you
get hypnotized (or throw up, or both :) ) 

>  And besides, implementing an OpenGL or whatever preview would make povray
>non-portable.

Actually OpenGL is quite portable. Well, Crays don't have it, but then
again, you'll see a raytraced preview on a Cray, so... :) But don't
get me wrong here, I agree that integrating an OpenGL preview system
for all objects from within POV would be hard, hard to port and
generally senseless work. I've never claimed the opposite.


Peter Popov
ICQ: 15002700

Post a reply to this message

In povray.general Peter Popov <pet### [at] usanet> wrote:
: Actually OpenGL is quite portable.

  It may be _quite_ portable, but not available for all the platforms povray
should be, for example DOS or this sparcstation 5.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Nieminen Mika wrote:
> 
> In povray.general Peter Popov <pet### [at] usanet> wrote:
> : Actually OpenGL is quite portable.
> 
>   It may be _quite_ portable, but not available for all the platforms povray
> should be, for example DOS or this sparcstation 5.

Of course it is (available).  Mesa (OpenGL clone) compiles quite happily
under DOS (and under Solaris).  Of course it doesn't do display stuff
under DOS, but it can generate a bitmap in memory that POV-Ray could
then write into the VGA buffers.

Xander

Post a reply to this message