>>
>>It's the name of the book, by Mardsden and Troma.
>
>I think I have that book!  But isn't it Tromba?


Oops! Of course. (go to www.troma.com for something _completely_ different.)
Must have missed the 'b' there... :/

But the book is great! Why don't you go to
http://www.uio.no/~simenkv/ma105/index.htm and see for yourself? Compare
with figure 2.7.2 in the book and _behold_. I think it's quite similar, only
better... ;)

Simen.

Post a reply to this message

On Thu, 10 Feb 2000 21:46:10 +0100, Simen Kvaal wrote:
>But the book is great! Why don't you go to
>http://www.uio.no/~simenkv/ma105/index.htm and see for yourself? Compare
>with figure 2.7.2 in the book and _behold_. I think it's quite similar, only
>better... ;)

As I said, I have the book, so I just opened it to page 179 and
compared. :)  Yours is much nicer-looking, I agree.  Also, I see
that it's Marsden and Tromba, so you must have just flipped the
B over and stuck it in the other name. :)

Post a reply to this message

In article <chrishuff_99-773CAB.07034410022000@news.povray.org>, Chris
Huff <chr### [at] yahoocom> writes
>
>But POV isn't written in C++, it is written in C. :-)
>Although there are plans to rewrite it in C++ for version 4...
>
I no it has nothing to do with me but I do not like this rewrite in C++
idea. I like poking around in the source, never done anything useful.
Anyway, if they convert I will not be able to do so! I know C but have
absolutely no desire to learn C++, I will not go into reasons.
-- 
  David Parrott    E-mail: xam### [at] quayles1demoncouk
                      ICQ: 13313977
                  Website: On it's way

Post a reply to this message

In article <GK0E$BAF90o4Iwhs@quayles1.demon.co.uk>, David Parrott 
<Xam### [at] quayles1demoncouk> wrote:

> I no it has nothing to do with me but I do not like this rewrite in C++
> idea. I like poking around in the source, never done anything useful.
> Anyway, if they convert I will not be able to do so!

It shouldn't be too hard to understand, even if you only know C. And it 
should make life for patch-writers much easier.


> I know C but have absolutely no desire to learn C++, I will not go 
> into reasons.

Why not? :-)

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

David Parrott <Xam### [at] quayles1demoncouk> writes:

> In article <chrishuff_99-773CAB.07034410022000@news.povray.org>, Chris
> Huff <chr### [at] yahoocom> writes
> >
> >But POV isn't written in C++, it is written in C. :-)
> >Although there are plans to rewrite it in C++ for version 4...
> >
> I no it has nothing to do with me but I do not like this rewrite in C++
> idea. I like poking around in the source, never done anything useful.
> Anyway, if they convert I will not be able to do so! I know C but have
> absolutely no desire to learn C++, I will not go into reasons.

That's good. So, you won't object my propositions. :-)

You really don't know what you're missing. In C++ you have a lot of
features that aren't available in C. You have references, in particular
as parameters. You can protect yourself (and others) from modifying 
locally constant variables. You can declare variables where you really 
need them and not only at the beginning of a function. You have object 
orientation to encapsulate your modules. You can really define your own 
types and use them just like built-in types. Think of integers with 
arbitrary precision, dates, times, colors, vectors,... etc. With C++ 
you can add, multiply or print them like integers or doubles -- and 
you can (to some extent) use the compiler to check, whether it makes sense. 
You can encapsulate your memory management and avoid memory leaks or
using freed memory.
As the most important feature I consider generic programming. This leads 
to generic lists, sizable arrays, or trees -- with type safety. 
Finally it's possible to make faster code with expression templates.
(By "faster" I mean "faster than C or fortran".)

Thomas


-- 
http://thomas.willhalm.de/ (includes pgp key)

Post a reply to this message

Simen Kvaal <sim### [at] studentmatnatuiono> wrote:
: I know that it probably was possible to do with
: std. pov, but it's so much easier to write "2xy^2/(x^2+y^4) instead of a
: buch of zeroes and ones. ;-)

  Darn, why did you say that? Now I _HAD_ to do it with a poly. :)
  Well, here it is:

camera { location <8,20,-10>*.7 look_at x*.01 angle 35 }
light_source { <100,200,20> 1 }
background { rgb y }
poly
{ 5,
  <0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,-2,
  0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0>
  sturm
  clipped_by { box { <-4,-4,-1><4,4,1> } } bounded_by { clipped_by }
  pigment { rgb <1,.7,.3> } finish { specular .5 }
  rotate <0,90,-90>
}

Post a reply to this message

Attachments:
Download 'surface.jpg' (19 KB)

Preview of image 'surface.jpg'

In article <qqm### [at] schlattfmiuni-konstanzde>, Thomas
Willhalm <tho### [at] willhalmde> writes
>
>That's good. So, you won't object my propositions. :-)
>
>You really don't know what you're missing. In C++ you have a lot of
>features that aren't available in C. You have references, in particular
>as parameters. You can protect yourself (and others) from modifying 
>locally constant variables. You can declare variables where you really 
>need them and not only at the beginning of a function. You have object 
>orientation to encapsulate your modules. You can really define your own 
>types and use them just like built-in types. Think of integers with 
>arbitrary precision, dates, times, colors, vectors,... etc. With C++ 
>you can add, multiply or print them like integers or doubles -- and 
>you can (to some extent) use the compiler to check, whether it makes sense. 
>You can encapsulate your memory management and avoid memory leaks or
>using freed memory.
>As the most important feature I consider generic programming. This leads 
>to generic lists, sizable arrays, or trees -- with type safety. 
>Finally it's possible to make faster code with expression templates.
>(By "faster" I mean "faster than C or fortran".)
>
>Thomas

OK, after reading that I like practically everything that I see except
one thing. I do not like this declare variables anywhere business. I
feel that this would lead to scrappy and difficult to follow code, when
declared at the beginning of a block you can see which variables are
declared easily. I feel that a code block is then easier to follow.
-- 
  David Parrott    E-mail: xam### [at] quayles1demoncouk
                      ICQ: 13313977
                  Website: On it's way

Post a reply to this message

Looks good, man! What was the render time for it? (Just comparing.)

Simen

>  Darn, why did you say that? Now I _HAD_ to do it with a poly. :)

Post a reply to this message

Simen Kvaal <sim### [at] studentmatnatuiono> wrote:
: Looks good, man! What was the render time for it? (Just comparing.)

  I made a modified version of my scene for the comparison:

//=========================================================================
#declare UseIso = no;

camera { location <8,20,-10>*.7 look_at x*.01 angle 35 }
light_source { <100,200,20> 1 }
background { rgb y }
#if(UseIso)
  #version unofficial MegaPOV 0.4;
  isosurface
  { function { 2*x*sqr(y)/(sqr(x)+sqr(y*y))-z }
    contained_by { box { <-4,-4,-1><4,4,1> } }
    open
#else
  poly
  { 5,
    <0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,-2,
    0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0>
    sturm
    clipped_by { box { <-4,-4,-1><4,4,1> } } bounded_by { clipped_by }
#end
    pigment { rgb <1,.7,.3> } finish { specular .5 }
    rotate <0,90,-90>
  }
//=========================================================================

  Changing the first line will choose the type of surface (poly or iso).
Choosing "no" will make the scene renderable with the official povray.
The images generated look quite identical. The rendering times in this
UltraSparc5 using "-w512 -h385 +a0.1" were:

Poly (with povray 3.1g):
    Total Time:    0 hours  0 minutes  53.0 seconds (53 seconds)

Poly (with megapov 0.4):
    Total Time:    0 hours  0 minutes  57.0 seconds (57 seconds)

Iso (with megapov 0.4):
    Total Time:    0 hours  0 minutes  40.0 seconds (40 seconds)

  Surprisingly enough, the isosurface is faster than the poly.
  Oddly enough, the poly is slightly slower in megapov than in the official
pov.

  Question: Should the poly be optimized to be at least as fast as the
isosurface?

-- 
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

David Parrott <Xam### [at] quayles1demoncouk> writes:
> 
> OK, after reading that I like practically everything that I see except
> one thing. I do not like this declare variables anywhere business. I
> feel that this would lead to scrappy and difficult to follow code, when
> declared at the beginning of a block you can see which variables are
> declared easily. I feel that a code block is then easier to follow.

When I switched from (Turbo) Pascal to C++, I had the same feelings.
That's why I can completely understand you. However, time and practice 
have changed my opinion on this matter. 

There is no need to see variables that are only used inside of loops or if- 
statements. If you can declare them inside that block, you can distinguish
between variables that are visible inside the whole function and those
that are only visible inside parts of it. This may save you from some 
trouble and reminds you to remove the variable declaration if the block is 
removed.

Another possible usage is that you can now always initialize a variable
when it is declared. This prevents using uninitialized values.
If you have to declare all variables at the top of the function, it isn't
always possible to initialize them with meaningful values.

But of course you aren't forced to declare variables in the middle of the
code. If you like it, you can still declare them in C-style manner.

Thomas

-- 
http://thomas.willhalm.de/ (includes pgp key)

Post a reply to this message