Hi,
	I've played with povray for a long time now and I realize that it's not
optimized for the kind of render I'm doing...  I mean povray takes forever to
parse a few millions of cylinders that have the same texture...  Yes, I know a
few Millions is a very huge number and should simply require more memory, but
povray crashed after filling my 128M of RAM and my 256M of swap...

Here I go...  I would like to make my own raytracer, not based on any point of
povray...  and optimize it for my own work...  but I never tried to make one and
I'm entering college for the first year this september,  what I was looking for
by posting this news is a list of books I should read in order to have a better
knowledge of this subject...  I prefer book over URL-documentation (unless
there's a .ps or .pdf i can print...)...

I already got a hand on Computer Graphics: Principles and Practice (Foley,
vanDam), but then, I would need some more!

Thanks a lot,
	Simon
-- 
+-------------------------+----------------------------------+
| Simon Lemieux           |         http://connect.to/666Mhz |
| lem### [at] yahoocom  | POV-Ray, OpenGL, C++ and more... |
+-------------------------+----------------------------------+

Post a reply to this message

i think the 'graphics gems' series covers all kinds of graphics
including raytracing.

Simon Lemieux wrote:
> 
> Hi,
>         I've played with povray for a long time now and I realize that it's not
> optimized for the kind of render I'm doing...  I mean povray takes forever to
> parse a few millions of cylinders that have the same texture...  Yes, I know a
> few Millions is a very huge number and should simply require more memory, but
> povray crashed after filling my 128M of RAM and my 256M of swap...
> 
> Here I go...  I would like to make my own raytracer, not based on any point of
> povray...  and optimize it for my own work...  but I never tried to make one and
> I'm entering college for the first year this september,  what I was looking for
> by posting this news is a list of books I should read in order to have a better
> knowledge of this subject...  I prefer book over URL-documentation (unless
> there's a .ps or .pdf i can print...)...
> 
> I already got a hand on Computer Graphics: Principles and Practice (Foley,
> vanDam), but then, I would need some more!
> 
> Thanks a lot,
>         Simon
> --
> +-------------------------+----------------------------------+
> | Simon Lemieux           |         http://connect.to/666Mhz |
> | lem### [at] yahoocom  | POV-Ray, OpenGL, C++ and more... |
> +-------------------------+----------------------------------+

Post a reply to this message

> i think the 'graphics gems' series covers all kinds of graphics
> including raytracing.

And where can I find that?

Thanks,
	Simon


-- 
+-------------------------+----------------------------------+
| Simon Lemieux           |         http://connect.to/666Mhz |
| lem### [at] yahoocom  | POV-Ray, OpenGL, C++ and more... |
+-------------------------+----------------------------------+

Post a reply to this message

Simon Lemieux wrote:
> 
> > i think the 'graphics gems' series covers all kinds of graphics
> > including raytracing.
> 
> And where can I find that?

http://www.acm.org/tog/GraphicsGems/

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

A friend just sent me a reviewer's copy of a book titled "Realistic Raytracing" by
Peter Shirley.  I am at best a novice POV user and know nothing of coding a
raytracer, but I read a few chapters of this book and I would say it should be worth
a look for you.  It lays out what you need to do in a very down-to-earth way,
step-by-step, or so it seems to my mostly uninformed eye.
/j

Simon Lemieux wrote:

> Hi,
>         I've played with povray for a long time now and I realize that it's not
> optimized for the kind of render I'm doing...  I mean povray takes forever to
> parse a few millions of cylinders that have the same texture...  Yes, I know a
> few Millions is a very huge number and should simply require more memory, but
> povray crashed after filling my 128M of RAM and my 256M of swap...
>
> Here I go...  I would like to make my own raytracer, not based on any point of
> povray...  and optimize it for my own work...  but I never tried to make one and
> I'm entering college for the first year this september,  what I was looking for
> by posting this news is a list of books I should read in order to have a better
> knowledge of this subject...  I prefer book over URL-documentation (unless
> there's a .ps or .pdf i can print...)...
>
> I already got a hand on Computer Graphics: Principles and Practice (Foley,
> vanDam), but then, I would need some more!
>
> Thanks a lot,
>         Simon
> --
> +-------------------------+----------------------------------+
> | Simon Lemieux           |         http://connect.to/666Mhz |
> | lem### [at] yahoocom  | POV-Ray, OpenGL, C++ and more... |
> +-------------------------+----------------------------------+

Post a reply to this message

ryan constantine wrote:
> 
> i think the 'graphics gems' series covers all kinds of graphics
> including raytracing.

I would agree (noting especially that Graphics Gems IV has an article on
line-cylinder intersection), and I'd add the following three books on
writing ray tracers:

Glassner, _An Introduction to Ray Tracing_
Wilt, _Object-Oriented Ray Tracing in C++_
Shirley, _Realistic Ray Tracing_

Also, since you're interested in textures:

Ebert et al., _Texturing and Modeling_

-Mark Gordon

Post a reply to this message

Perhaps instead of doing it the hard way (ie. program your own raytracer,
which probably won't be any better than povray), you could just try to
optimize your scene for povray.

  If povray spends ages calculating light buffers (and that's what is filling
up the memory), try turning them off. The rendering may be slower, but if
it was the actual problem, it will render, which is the goal. You can also
try with the vista buffers as well (although I don't know if it will be of
any help).

  If your scene has many identical groups of cylinders (the only difference
between the groups being the transformations (scale, rotate, translate)
applied to them) you could try replacing the cylinders of one of these group
with equivalent smooth triangle meshes (making a #declared identifier of them).
When you make copies of this mesh (and transform the copies) they will take
a lot less memory. The bigger the group of cylinders and the more the copies
of the group, the better (ie. more memory saved).

  If your texture doesn't have to be transformed with the cylinder (but is,
for example, just a plain color), don't texture each cylinder separately,
but make a union of all the cylinders in the scene and texture it just once.

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

Post a reply to this message

In article <399CADE9.1D14841A@mailbag.com> , Mark Gordon 
<mtg### [at] mailbagcom>  wrote:

> I would agree (noting especially that Graphics Gems IV has an article on
> line-cylinder intersection), and I'd add the following three books on
> writing ray tracers:
>
> Glassner, _An Introduction to Ray Tracing_
> Wilt, _Object-Oriented Ray Tracing in C++_
> Shirley, _Realistic Ray Tracing_
>
> Also, since you're interested in textures:
>
> Ebert et al., _Texturing and Modeling_

Not to mention the "Suggested Reading" section in the POV-Ray
documentation... :-)


       Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

>   Perhaps instead of doing it the hard way (ie. program your own raytracer,
> which probably won't be any better than povray), you could just try to
> optimize your scene for povray.
> 
>   If povray spends ages calculating light buffers (and that's what is filling
> up the memory), try turning them off. The rendering may be slower, but if
> it was the actual problem, it will render, which is the goal. You can also
> try with the vista buffers as well (although I don't know if it will be of
> any help).
> 
>   If your scene has many identical groups of cylinders (the only difference
> between the groups being the transformations (scale, rotate, translate)
> applied to them) you could try replacing the cylinders of one of these group
> with equivalent smooth triangle meshes (making a #declared identifier of them).
> When you make copies of this mesh (and transform the copies) they will take
> a lot less memory. The bigger the group of cylinders and the more the copies
> of the group, the better (ie. more memory saved).
> 
>   If your texture doesn't have to be transformed with the cylinder (but is,
> for example, just a plain color), don't texture each cylinder separately,
> but make a union of all the cylinders in the scene and texture it just once.

IMHO,
	POV-Ray is a complete general raytracing algorythm...  which will be fast for
almost anything...

	My scene has no light, nothing else than a few millions of cylinders all the
same texture...  how can I optimize that for povray? Reduce the number of
cylinders? Wrong!  That would also reduce the realism of my scene... what I need
is a raytracer that would handle very easily and very fast such a big number of
"Cylinder" and would be simply very slow when you would only have a cube... 
Optimized for a large number of cylinders, that is what I need!  Also that I got
a C++ program that calculate the position for all these cylinders and outputs
the result in a povray script...  ( cylinder { <x,y,z> texture { TheTex }})  and
then povray starts Parsing the scene and takes forever...  Would take a double
forever if I added lighting!...

	I am very interested in Povray, but sometimes I would need a specific tool...

Thanks,
	Simon

-- 
+-------------------------+----------------------------------+
| Simon Lemieux           |            http://www.666Mhz.net |
| lem### [at] yahoocom  | POV-Ray, OpenGL, C++ and more... |
+-------------------------+----------------------------------+

Post a reply to this message

Simon Lemieux wrote:

>         My scene has no light, nothing else than a few millions of cylinders all the
> same texture.

(snip)

>         I am very interested in Povray, but sometimes I would need a specific
tool...

Given that your scene has no light, I'm not convinced that the tool you
need is a ray tracer.  If you were doing ten million shiny cylinders on
a checkerboard, maybe.  I might suggest considering a different
algorithm if you're not going to be doing anything fancy with lighting.

-Mark Gordon

Post a reply to this message

why not have someone export a cylinder as a mesh for you from a program
that can and then use it as an include file?  i think meshes parse
faster and take less memory for your situation.  you could still use
your program to place them, you would just have to put the object name
in place of the cylinder.

Simon Lemieux wrote:
> 
> >   Perhaps instead of doing it the hard way (ie. program your own raytracer,
> > which probably won't be any better than povray), you could just try to
> > optimize your scene for povray.
> >
> >   If povray spends ages calculating light buffers (and that's what is filling
> > up the memory), try turning them off. The rendering may be slower, but if
> > it was the actual problem, it will render, which is the goal. You can also
> > try with the vista buffers as well (although I don't know if it will be of
> > any help).
> >
> >   If your scene has many identical groups of cylinders (the only difference
> > between the groups being the transformations (scale, rotate, translate)
> > applied to them) you could try replacing the cylinders of one of these group
> > with equivalent smooth triangle meshes (making a #declared identifier of them).
> > When you make copies of this mesh (and transform the copies) they will take
> > a lot less memory. The bigger the group of cylinders and the more the copies
> > of the group, the better (ie. more memory saved).
> >
> >   If your texture doesn't have to be transformed with the cylinder (but is,
> > for example, just a plain color), don't texture each cylinder separately,
> > but make a union of all the cylinders in the scene and texture it just once.
> 
> IMHO,
>         POV-Ray is a complete general raytracing algorythm...  which will be fast
for
> almost anything...
> 
>         My scene has no light, nothing else than a few millions of cylinders all the
> same texture...  how can I optimize that for povray? Reduce the number of
> cylinders? Wrong!  That would also reduce the realism of my scene... what I need
> is a raytracer that would handle very easily and very fast such a big number of
> "Cylinder" and would be simply very slow when you would only have a cube...
> Optimized for a large number of cylinders, that is what I need!  Also that I got
> a C++ program that calculate the position for all these cylinders and outputs
> the result in a povray script...  ( cylinder { <x,y,z> texture { TheTex }})  and
> then povray starts Parsing the scene and takes forever...  Would take a double
> forever if I added lighting!...
> 
>         I am very interested in Povray, but sometimes I would need a specific
tool...
> 
> Thanks,
>         Simon
> 
> --
> +-------------------------+----------------------------------+
> | Simon Lemieux           |            http://www.666Mhz.net |
> | lem### [at] yahoocom  | POV-Ray, OpenGL, C++ and more... |
> +-------------------------+----------------------------------+

Post a reply to this message

Simon Lemieux <lem### [at] yahoocom> wrote:

> My scene has no light, nothing else than a few millions of cylinders
> all the same texture...  how can I optimize that for povray? Reduce the
> number of cylinders? Wrong!  That would also reduce the realism of my
> scene... what I need is a raytracer that would handle very easily and
> very fast such a big number of "Cylinder" and would be simply very slow
> when you would only have a cube...  Optimized for a large number of
> cylinders, that is what I need!  Also that I got a C++ program that
> calculate the position for all these cylinders and outputs the result
> in a povray script...  ( cylinder { <x,y,z> texture { TheTex }})  and

If all cylinder objects have the same texture why do you apply this
texture to each object? I would rather make a union and apply the
texture to the whole union object.

bye,
  Chris
-- 
Christian Perle              E-mail:        chr### [at] tu-clausthalde
Am Galgensberg 4             WWW:        http://home.tu-clausthal.de/~incp/
38678 Clausthal/Germany      ComputerGuitarKitesBicyclesBeerPizzaRaytracing

Post a reply to this message

> If all cylinder objects have the same texture why do you apply this
> texture to each object? I would rather make a union and apply the
> texture to the whole union object.

I tried that...  the only thing it helped was to reduce the size of the file a
few kbytes... big deal... didn't speed anything up...

BTW, I could use something like opengl... but one day... my cylinders might
become glass cylinder and then I would like to be able to do some refraction... 
impossible with opengl... only possible with a raytracer... and then again I
talked about Millions of cylinder...  one day I might need Billions and so
on...  Adding hardware to help the process isn't a solution, I must change the
process itself...

Thank you all for your suggestions, but what I need is documentation about
"creating a raytracer"...  

Thanks,
	Simon

-- 
+-------------------------+----------------------------------+
| Simon Lemieux           |            http://www.666Mhz.net |
| lem### [at] yahoocom  | POV-Ray, OpenGL, C++ and more... |
+-------------------------+----------------------------------+

Post a reply to this message

again, why not use a mesh?  in megapov they are solid and could be
glass.

Simon Lemieux wrote:
> 
> > If all cylinder objects have the same texture why do you apply this
> > texture to each object? I would rather make a union and apply the
> > texture to the whole union object.
> 
> I tried that...  the only thing it helped was to reduce the size of the file a
> few kbytes... big deal... didn't speed anything up...
> 
> BTW, I could use something like opengl... but one day... my cylinders might
> become glass cylinder and then I would like to be able to do some refraction...
> impossible with opengl... only possible with a raytracer... and then again I
> talked about Millions of cylinder...  one day I might need Billions and so
> on...  Adding hardware to help the process isn't a solution, I must change the
> process itself...
> 
> Thank you all for your suggestions, but what I need is documentation about
> "creating a raytracer"...
> 
> Thanks,
>         Simon
> 
> --
> +-------------------------+----------------------------------+
> | Simon Lemieux           |            http://www.666Mhz.net |
> | lem### [at] yahoocom  | POV-Ray, OpenGL, C++ and more... |
> +-------------------------+----------------------------------+

Post a reply to this message

I told you many ways of optimizing the scene. Did you read my article
completely?

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

Post a reply to this message

Simon Lemieux <lem### [at] yahoocom> wrote:
: BTW, I could use something like opengl... but one day... my cylinders might
: become glass cylinder and then I would like to be able to do some refraction... 
: impossible with opengl... only possible with a raytracer... and then again I
: talked about Millions of cylinder...  one day I might need Billions and so
: on...  Adding hardware to help the process isn't a solution, I must change the
: process itself...

  Billions of glass cylinders? Stop dreaming :)

  Well, perhaps if you have a render farm consisting of hundreds of Cray T3E
computers with 2048 processors each and gigabytes of memory and running a
multithreaded patch of povray...

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

Post a reply to this message

Hi,

>nothing else than a few millions of cylinders

On my whole screen there is not even one single million of individual
pixels and I don't think there are many around with "a few million"
pixels, let alone enough to show a few million instances of anything
larger than a single pixel.

Ciao, MM
-- 
Marian Aldenhövel, Hainstraße 8, 53121 Bonn, Germany
http://www.marian-aldenhoevel.de
Opinions expressed here are my own AND those of my employer

Post a reply to this message

"Marian Aldenhövel" wrote:
> 
> Hi,
> 
> >nothing else than a few millions of cylinders
> 
> On my whole screen there is not even one single million of individual
> pixels and I don't think there are many around with "a few million"
> pixels, let alone enough to show a few million instances of anything
> larger than a single pixel.

Good point.  Simon: beware of aliasing.

-Mark Gordon

Post a reply to this message

In article <399EA958.52093EC9@yahoo.com>, lem### [at] yahoocom says...

> impossible with opengl... only possible with a raytracer... and then again I
> talked about Millions of cylinder...  one day I might need Billions and so
What is the point of using so much objects? Unless you 're wanting to 
render it at VERY high resolutions, they simply can't show up in your 
scene, as there is more than one object per pixel... And probably the 
objects in the front hide an enoumous amount of objects in the back.
You should really reduce the amount of objects. If you optimize it the 
right way it should show no difference at all in the resulting image.

Post a reply to this message

On Sat, 19 Aug 2000 13:24:16 -0700, ryan constantine wrote:
>again, why not use a mesh?  in megapov they are solid and could be
>glass.

There's a common misconception here.  An object need not be solid to be
made of glass.  I've made glass boxes from meshes and even bicubic patches.
The trick is to make sure every transparent face of the object is associated
with the same interior{ } block.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

>   Billions of glass cylinders? Stop dreaming :)
> 
>   Well, perhaps if you have a render farm consisting of hundreds of Cray T3E
> computers with 2048 processors each and gigabytes of memory and running a
> multithreaded patch of povray...

Yes it seems impossible (with povray), but here come the Optimisation (might
need bachelor degree in computer science to achieve this...)  it will ONLY
render glass cylinders!  It won't be annoyed by anything else that would slow
the render...

IMHO,
	Sin

-- 
+-------------------------+----------------------------------+
| Simon Lemieux           |            http://www.666Mhz.net |
| lem### [at] yahoocom  | POV-Ray, OpenGL, C++ and more... |
+-------------------------+----------------------------------+

Post a reply to this message

Simon Lemieux <lem### [at] yahoocom> wrote:
: Yes it seems impossible (with povray), but here come the Optimisation (might
: need bachelor degree in computer science to achieve this...)  it will ONLY
: render glass cylinders!  It won't be annoyed by anything else that would slow
: the render...

  If you really want to raytrace billions of glass cylinders, it will take
ages, no matter how optimized it is.
  If you want it faster, you have to use some other algorithm than raytracing.
(I don't know if there's any.)

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

Post a reply to this message

>   If you want it faster, you have to use some other algorithm than raytracing.
> (I don't know if there's any.)

I would suggest photography, but then you would need billions of glass cylinders
;-)

Post a reply to this message

> I would suggest photography, but then you would need billions of glass cylinders
> ;-)

Yeah I thought about this.... but the problem here is not much the money...  but
the cash, to buy the lens for my camera, etc...

;)

Simon

-- 
+-------------------------+----------------------------------+
| Simon Lemieux           |            http://www.666Mhz.net |
| lem### [at] yahoocom  | POV-Ray, OpenGL, C++ and more... |
+-------------------------+----------------------------------+

Post a reply to this message

I would suggest waiting for quantum computers to become more readily available
(I'm assuming that they already exist but not in the public domain yet).

It would be an interesting exercise to start coding a raytracer for a quantum
computer - I know that algorithms already exist for factoring large numbers which
is likely to be used for cracking so called unbreakable encryption.

Simon Lemieux wrote:

> >   Billions of glass cylinders? Stop dreaming :)
> >
> >   Well, perhaps if you have a render farm consisting of hundreds of Cray T3E
> > computers with 2048 processors each and gigabytes of memory and running a
> > multithreaded patch of povray...
>
> Yes it seems impossible (with povray), but here come the Optimisation (might
> need bachelor degree in computer science to achieve this...)  it will ONLY
> render glass cylinders!  It won't be annoyed by anything else that would slow
> the render...
>
> IMHO,
>         Sin
>
> --
> +-------------------------+----------------------------------+
> | Simon Lemieux           |            http://www.666Mhz.net |
> | lem### [at] yahoocom  | POV-Ray, OpenGL, C++ and more... |
> +-------------------------+----------------------------------+

Post a reply to this message

In article <39A55274.77E3CFDE@hotmail.removethisbit.com>, 
ric### [at] hotmailremovethisbitcom says...
> I would suggest waiting for quantum computers to become more readily available
> (I'm assuming that they already exist but not in the public domain yet).
Yes. The "biggest" they build so far was assembled of 3 atoms oder so ;-)
 
> computer - I know that algorithms already exist for factoring large numbers which
> is likely to be used for cracking so called unbreakable encryption.
Of course thay exists. They only have the small flaw that they would take 
at least a few centuries to decrypt a single message.

Post a reply to this message