> 1. Everyone knows pov is slow as molasses. Lets just throw out the old
> deprecated C and convert the whole program to ASM. Everyone has Pentiums
now
> anyway.

Thank you for your ideas. Even if we don't like all of them, we can answer
your questions and get a fresh input, as Rune said. There are 2 reasons why
Povray is not written in assembly code:

1)  Pov is meant to be timeless and platform independant. The past has
proven that writing big programs for specific hardware is dangerous because
we don't know what is on the market tomorrow, so the code needs constant
adjustment. Otherwise it needs a full rewrite in just a few years when a new
processor appears. Some commercial developers have the power to handle this,
but Povray is written by many people in their sparetime, over the years. New
coders appear and contribute with something. Some old coders loose interest.
Besides assembly code is harder to understand than C, so new coders will
easily get lost while digging around exsisting code, trying to contribute.

2)  C is not much slower than assembly code these days. The windows version
of POV has been optimised for Pentium / AMD with Intel's compiler.


> 3. I don't know about you guys but this typing crap is hard. It's the new
> millennium and time for a GUI. Lets mimic a proven formula for
productivity
> and intuitiveness. A system that is both easy to use and feature rich. All
> you real CG experts of course know I'm talking about the interface found
in
> Bryce! I mean those arrows are so pretty! How come pov doesn't have pretty
> arrows?

I consider the power of Povray to be the concept of typing graphics, instead
of using the mouse. It's not a limitation but a unique approch to modelling.
It's a dream that comes true for some people, while other people hate it..
Some people don't even give it a chance, and that's a shame.. If you think
it's hard ... well perhaps it's true, but it's not harder than using
graphical modellers.. It's just different.


> 5. Speaking of winamp, isn't about time that pov's UI was skinnable?!

I think that's a good idea.


> 6. CSG would be a lot easier if we had more primitives to work with. Cubes
> and spheres were great in preschool but the world is a complex place and
we
> need complex shapes to describe it. Here are my suggestions for some new
> primitives: Dodecahedron, Buckyball, Leggo brick, Shreck

These shapes can be coded with exsisting primitives and put into a macro.
After this you can easily call them, exactly as if they were "new"
primitives. If you search the Povray newsgroups for Dodecahedron you will
find a cool macro by Uwe Zimmerman. It can make all these kind of 'hedrons
with any number of faces.


> I hope the dev team will take these suggestions to heart when considering
> what features to add to pov4. Thanks for hearing me out!

I'm not one of the developers, but I liked to hear you out! You're right
that Povray can be improved.

Regards,
Hugo

Post a reply to this message

On Sun, 17 Mar 2002 18:28:15 -0500, "Corey Woodworth" <cdw### [at] mpinetnet>
wrote:
> I know that I'm still a newbie here

I know that too, but probably I can help you pointing you some interesting
features of latest 3.5.

> 1. Everyone knows pov is slow as molasses. Lets just throw out the old
> deprecated C and convert the whole program to ASM. Everyone has Pentiums now
> anyway.

It is already converted by the team. They even use two different converters:
Visual C (to convert GUI) and INTEL C (to convert engine for processor).

> 2. With the speed afforded to us from improvement number one we can now
> throw out all the old hacks that give us refection and refraction in favor
> for a much better system: Forward ray tracing.

Personally I've always looked forward while tracing. You mean the reason why
it took 335 hours to render 365 lines in my failed shortest code contest entry
is that is is done backward ? Why I didn't stopped this render at begining!!!
Doh, I could save my image.

> 3. I don't know about you guys but this typing crap is hard. It's the new
> millennium and time for a GUI. Lets mimic a proven formula for productivity
> and intuitiveness. A system that is both easy to use and feature rich. All
> you real CG experts of course know I'm talking about the interface found in
> Bryce! I mean those arrows are so pretty! How come pov doesn't have pretty
> arrows?

Newest 3.5 has pretty smart gui. Last time when I used this I achived pretty
nice render of bluish submarine with mines. Name Wizard even choosed name for
this submarine. It was ABYSS or something. I heard there is also teapot wizard
builded in.

> 4. I like listening to music when I'm modeling, but it's such a pain to
> alt-tab back and forth between pov and winamp, why don't we make pov a
> winamp plug-in?

Again I advice you to download 3.5. Check the Editor menu. There is entry
"Play Macro". Everything you need now is to click (as I said in GUI you can't
type now, only click) on "Inser Menu", then click on "Statements" and click on
"Noise generator". Did you hear some noise. It's sound of string.

> 5. Speaking of winamp, isn't about time that pov's UI was skinnable?!

You mean Options->Message Window->Choose Background ?

> 6. CSG would be a lot easier if we had more primitives to work with. Cubes
> and spheres were great in preschool but the world is a complex place and we
> need complex shapes to describe it. Here are my suggestions for some new
> primitives: Dodecahedron, Buckyball, Leggo brick, Shreck.

As I heard the time for 3.5 feature requests is closed but I agree with you
that rendering of Mickey Mouse is difficult. Anyway I reached nice animation
of "Pluto on Mily Way - Daily Adventures" episode. The only problem.. it was
monotonous animation.

> 7. Its so much fun to return to the pov site after the beta expires to get
> the next one! It makes sure I visit regularly and I have the newest version.
> I think that the final version should expire as well, even if there aren't
> any new versions to download.

I don't agree with you. I only suggest to require in specification machines
without network cards. Only artwork cards should be allowed.

> 8. While I commend whoever wrote the tutorials, FAQs, and docs that come
> with pov we all know that nobody reads them. How about we convert them all
> to wav files? If pov becomes a winamp plugin then it would integrate nicely.

Or going further - why gui don't read scripts to the parser ? Perhaps to
avoid: "Parse Error: What did you say ?"

> I hope the dev team will take these suggestions to heart when considering
> what features to add to pov4.

Can I have my own suggestion ? Sell all useless bytes of code to Pixar and
save only important part. It should speed up renderings very much.

> Thanks for hearing me out!

Reciprocally

ABX

BTW: I could write ;-) after every sentence but becouse you couldn't ...

Post a reply to this message

"Timothy R. Cook" wrote:

> >Rounded Sphere (as companion to rounded box)

Now there's an idea whose time has come. I can never seem to get those spheres
round enough. They always end up with sharp edges. I am posting sample code.
What am I doing wrong?

box  {<-1,-1,-1>,<1,1,1> pigment {MyPigment}}

; }

Post a reply to this message

"Dave Dunn" <poi### [at] aolcom> wrote in message
news:3C95DD52.58BCC79C@aol.com...
>
> Now there's an idea whose time has come. I can never seem to get those spheres
> round enough. They always end up with sharp edges. I am posting sample code.
> What am I doing wrong?
>
> box  {<-1,-1,-1>,<1,1,1> pigment {MyPigment}}
>

A common beginner's mistake. Try:

// decrease step for higher quality
#local Step = 20;
intersection{
  box{0,1 translate -0.5}
  #local M = 0;
  #while(M <= 360)
    #local N = 0;
    #while(N <= 360)
      plane{x,1/2 rotate z*M rotate y*N}
      #local N = N + Step;
    #end
    #local M = M + Step;
  #end
  pigment{Red}
}

Post a reply to this message

In article <3c9592cb@news.povray.org>,
 "Mark Wagner" <mar### [at] gtenet> wrote:

> You're wrong there.  POV-Ray needs fewer primitives, not more.  See my post
> "A Modest Proposal" from June 30, 1999.

Seriously, I think there are a few places it could be simplified. The 
merge shape could be replaced with an option for the union shape, sor 
could be an option for lathes, the various polynomial shapes could be 
put in the poly shape. The prism and polygon primitives could be made 
into one primitive, or prism, sor, and lathe could be combined into a 
single sweep primitive. Smooth triangles could be made part of ordinary 
triangles. Triangles are really just a subset of polygons, but I guess 
they are different enough to deserve their own syntax.

Behind the scenes, the shapes would change intersection calculations to 
fit their parameters, but they appear so similar to the user that they 
could be combined.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

At least someone has sense of humor... ;)

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Mark Wagner <mar### [at] gtenet> wrote:
> POV-Ray needs fewer primitives, not more.

  Which is completely wrong.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Sir Charles W. Shults III <aic### [at] cflrrcom> wrote:
>     Personally, I think that simpler is better here.  Most of what I model I
> get done very nicely with boxes, cylinders, etc.  More complex shapes are
> fine, but you don't often really need them.  POVray should stick with the
> K.I.S.S. principle wherever possible.

  So let's take off the complex primitives from those who use them just
because *you* don't use them?

  No.
  The fact that you are S.S. doesn't mean everyone else is.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

It was just a joke. It wasn't meant to be taken seriously.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

"Corey Woodworth" <cdw### [at] mpinetnet> wrote in message
news:3c9523b7@news.povray.org...

<snip>

Heh-heh.

Hey, you forgot the smiley... Oh well, I doubt there's any chance anyone will
think you meant it....

Post a reply to this message