 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <chrishuff_99-773CAB.07034410022000@news.povray.org>, Chris
Huff <chr### [at] yahoo com> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Well, the Isosurfaces surprise me all the time! It's just on hell of a good
object, and IMHO it deserves a good implementation in an official release.
(That's not my business, though.) I often expect strange results, as I find
the Iso somewhat unreliable, but it turns out it renders quickly and good!
Results of comparision (My p2 400 MHz with some sonloading in the
background.) All with 640x480, 0.3 anitaliasing.
Note that the isosurface was quite a bit faster, but it returned different
stats, for example no parse time. A bug?
Simen.
**** stats ****
Poly version:
Pixels: 307840 Samples: 335720 Smpls/Pxl: 1.09
Rays: 335720 Saved: 0 Max Level: 1/5
----------------------------------------------------------------------------
Ray->Shape Intersection Tests Succeeded Percentage
----------------------------------------------------------------------------
Box 554686 471041 84.92
Quartic/Poly 471112 362128 76.87
Bounding Object 554686 471112 84.93
Clipping Object 263395 233111 88.50
----------------------------------------------------------------------------
Roots tested: 471112 eliminated: 218965
Calls to Noise: 0 Calls to DNoise: 10
----------------------------------------------------------------------------
Shadow Ray Tests: 218966 Succeeded: 1477
----------------------------------------------------------------------------
Smallest Alloc: 28 bytes Largest: 17624
Peak memory used: 97452 bytes
----------------------------------------------------------------------------
Time For Parse: 0 hours 0 minutes 1.0 seconds (1 seconds)
Time For Trace: 0 hours 1 minutes 13.0 seconds (73 seconds)
Total Time: 0 hours 1 minutes 14.0 seconds (74 seconds)
Iso version:
Ray->Shape Intersection Tests Succeeded Percentage
----------------------------------------------------------------------------
Isosurface Bound 554567 468511 84.48
Isosurface 463825 223339 48.15
----------------------------------------------------------------------------
Calls to Noise: 0 Calls to DNoise: 10
----------------------------------------------------------------------------
Shadow Ray Tests: 218855 Succeeded: 1517
----------------------------------------------------------------------------
Smallest Alloc: 28 bytes Largest: 17624
Peak memory used: 97133 bytes
----------------------------------------------------------------------------
Time For Trace: 0 hours 0 minutes 48.0 seconds (48 seconds)
Total Time: 0 hours 0 minutes 48.0 seconds (48 seconds)
Simen.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Simen Kvaal wrote:
>
> Note that the isosurface was quite a bit faster, but it returned different
> stats, for example no parse time. A bug?
>
No, simply a parse time shorter than 1s...
Jerome
--
* Doctor Jekyll had something * mailto:ber### [at] inamecom
* to Hyde... * http://www.enst.fr/~jberger
*******************************
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
