 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I did this to visualize my homework in "Vector Calculus" class today. Neat
feature, these isosurfaces. 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. ;-)
Notice the _nice_ discontinuities when you approach (0, 0, 0) along either
side of the x-axis.. *drool*
5k.
Post a reply to this message
Attachments:
Download 'surf01.jpg' (42 KB)
Preview of image 'surf01.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'll be doing this next term. Please share your code with me! Please?
I havne't figured out an easy way to use the right handed coordinate system the
book uses in POV-Ray, which is the same right handed system you display here,
but all the illustraions are from the other side
Simen Kvaal wrote:
> I did this to visualize my homework in "Vector Calculus" class today. Neat
> feature, these isosurfaces. 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. ;-)
>
> Notice the _nice_ discontinuities when you approach (0, 0, 0) along either
> side of the x-axis.. *drool*
>
> 5k.
>
> [Image]
--
Josh English
eng### [at] spiritone com
"May your hopes, dreams, and plans not be destroyed by a few zeros."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Simen Kvaal wrote:
> I did this to visualize my homework in "Vector Calculus" class today. Neat
> feature, these isosurfaces. 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. ;-)
"Vector calculus"--what grade are you in?
(Yeah! Finished all my homework for the week during class in math! Wish I
hadn't had two friggin' years of repeat in middle school...)
--
___ ______________________________________________________
| \ |_ <dav### [at] faricynet> <ICQ 55354965>
|_/avid |ontaine http://www.faricy.net/~davidf/
"Sitting on a cornflake, waiting for the van to come" -Beatles
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David Fontaine <dav### [at] faricynet> wrote in message
news:38A### [at] faricynet...
> Simen Kvaal wrote:
>
> > I did this to visualize my homework in "Vector Calculus" class today.
Neat
> > feature, these isosurfaces. 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. ;-)
>
> "Vector calculus"--what grade are you in?
> (Yeah! Finished all my homework for the week during class in math! Wish I
> hadn't had two friggin' years of repeat in middle school...)
>
>
Dah! Math!! I've been in college nearly four years. this is the first
quarter I havn't had a math class.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Josh English <eng### [at] spiritonecom> writes:
> I havne't figured out an easy way to use the right handed coordinate system
> the book uses in POV-Ray, which is the same right handed system you display
> here, but all the illustraions are from the other side
I have not tried this, but shouldn't
camera {
right -4/3*x
sky z
location <soandso>
look_at <anotherpoint>
}
work? Read the section "Placing the camera" in the POV-Ray reference
to learn more about these values.
Thomas
--
http://thomas.willhalm.de/ (includes pgp key)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>"Vector calculus"--what grade are you in?
It's the name of the book, by Mardsden and Troma. Second half of first year
in Univeristy of Oslo, Norway. We're learning analysis if functions with
several variables. You know, this is _the_ class for POV-ray users! After
three weeks, I know enough maths to write my own isosurface code! (I don't
mean to _use_ the isosurfaces, but to code the program itself... That is, If
I was any good at C++ ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38a28217@news.povray.org>, "Simen Kvaal"
<sim### [at] studentmatnatuiono> wrote:
> >"Vector calculus"--what grade are you in?
>
> It's the name of the book, by Mardsden and Troma. Second half of
> first year in Univeristy of Oslo, Norway. We're learning analysis if
> functions with several variables. You know, this is _the_ class for
> POV-ray users! After three weeks, I know enough maths to write my own
> isosurface code! (I don't mean to _use_ the isosurfaces, but to code
> the program itself... That is, If I was any good at C++ ;)
But POV isn't written in C++, it is written in C. :-)
Although there are plans to rewrite it in C++ for version 4...
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 10 Feb 2000 10:17:08 +0100, Simen Kvaal wrote:
>>"Vector calculus"--what grade are you in?
>
>It's the name of the book, by Mardsden and Troma.
I think I have that book! But isn't it Tromba?
--
These are my opinions. I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
What is this "Math" you speak of?
coo kook achew,
Peter W
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks, will all of the experimenting I've done with the camera I couldnt' get it
to work. Your code is just what I need.
Thanks
Thomas Willhalm wrote:
> Josh English <eng### [at] spiritonecom> writes:
>
> > I havne't figured out an easy way to use the right handed coordinate system
> > the book uses in POV-Ray, which is the same right handed system you display
> > here, but all the illustraions are from the other side
>
> I have not tried this, but shouldn't
>
> camera {
> right -4/3*x
> sky z
> location <soandso>
> look_at <anotherpoint>
> }
>
> work? Read the section "Placing the camera" in the POV-Ray reference
> to learn more about these values.
>
> Thomas
>
> --
> http://thomas.willhalm.de/ (includes pgp key)
--
Josh English
eng### [at] spiritonecom
"May your hopes, dreams, and plans not be destroyed by a few zeros."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>
>>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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
--
******************************* Jérôme M. BERGER
* Doctor Jekyll had something * mailto:ber### [at] inamecom
* to Hyde... * http://www.enst.fr/~jberger
*******************************
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
