POV-Ray : Newsgroups : povray.general : quicker render alternatives to povray Server Time
31 Jul 2024 02:31:14 EDT (-0400)
  quicker render alternatives to povray (Message 41 to 50 of 50)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: Rahul
Subject: Re: quicker render alternatives to povray
Date: 18 Mar 2008 13:25:00
Message: <web.47e008e772535d7259eba08c0@news.povray.org>
"Paul Bourke" <pau### [at] uwaeduau> wrote:

> Have you tried Tachyon ... it is supplied with VMD but is a stand along
> raytracer, is very fast, can handle very large numbers of objects (without the
> slow scene parsing times of PovRay), if you have a cluster or HPC facility or
> multiple cores it will make full use of those (threads or MPI based for
> multiple cpus), etc etc. Designed I imagine for exactly what you are talking
> about, fast, a raytracer, perhaps not the same quality of larger more involved
> packages. It is also built as just an library so you can incorporate it into
> your own code. Oh and yes, easy to write an exporter/parser for the scene file.

Thanks! Another great lead. I was just reading the docs and looks very
promising. I'm giving Tachyon a try.

-Rahul


Post a reply to this message

From: Alain
Subject: Re: quicker render alternatives to povray
Date: 18 Mar 2008 21:50:58
Message: <47e07f92@news.povray.org>
See my comments in the code

Rahul nous apporta ses lumieres en ce 2008/03/18 01:33:

> *****************************************************************************
> 
> #include "colors.inc"
> #include "textures.inc"
> 
> #declare ATM_FINISH = finish {specular 0.9 roughness 0.001 ambient rgb
> <0.3,0.3,0.3> metallic}
> #declare RIBBON_FINISH = finish {specular 0.9 roughness 0.001 ambient rgb
> <0.3,0.3,0.3>}
> #declare SURF_FINISH = finish {specular 0.9 roughness 0.001 ambient rgb
> <0.3,0.3,0.3>}
3 identical finish declarations.
Change to:
#declare ATM_FINISH = finish{specular 0.9 roughness 0.001 ambient 0.3 metallic}
#declare RIBBON_FINISH = ATM_FINISH
#declare SURF_FINISH = ATM_FINISH

> #declare N_tex = texture { pigment { colour red 0.231 green 0.318 blue 1.000 }
> finish{ ATM_FINISH }}
The pigments can be changed to: pigment{rgb<0.231, 0.318, 1>}
> #declare C_tex = texture { pigment { colour red 0.100 green 0.100 blue 0.100 }
> finish{ ATM_FINISH }}
This can be changed to: pigment{ rgb 0.1}
> #declare O_tex = texture { pigment { colour red 0.700 green 0.000 blue 0.000 }
> finish{ ATM_FINISH }}
No effect on the render time, and only miliseconds on the parse time = totaly 
negligeable. Only shorter code and, in my view, easier to read.
> ....
> [snip]
> ....
> //************ CAMERA *********
> 
> #declare zoom = 15;
> 
> // Define Camera Positions
> #declare xtopview = camera {orthographic direction <1, 0, 0> sky <0, 0, 1> up
> <0, 0, zoom> right<zoom*4/3,0,0> rotate <0,0,180> loca
> tion <0, 0, 20> look_at <0, 0, 0>}
> #declare xfrontview = camera {orthographic location  <0, -20, 0> direction <1,
> 0, 0> sky <0, 0, 1> up <0, 0, zoom> right<zoom*4/3,0>
>  look_at <0, 0,0>}
> 
You may want to use a normal perspective camera. orthographic greatly reduce the 
depth feel.
> .....
> [snip]
> .....
> 
> //************ LIGHTS *********
> 
> #declare Intensity = 1.7;
> 
> light_source
> {
>   0*z // light's position (translated below)
>   color rgb 1.7  // light's color
>   // <widthVector> <heightVector> nLightsWide mLightsHigh
>   area_light
>   <12, 0, 0> <0, 0, 12> // lights spread out across this distance (x * z)
>   4, 4                // total number of lights in grid (4x*4z = 16 lights)
>   adaptive 0          // 0,1,2,3...
>   jitter              // adds random softening of light
>   translate <30, -60, 40>   // <x y z> position of light
>   shadowless
> }
> light_source
> {
>   0*z // light's position (translated below)
>   color rgb 1  // light's color
>   // <widthVector> <heightVector> nLightsWide mLightsHigh
>   area_light
>   <12, 0, 0> <0, 12, 0> // lights spread out across this distance (x * z)
>   6, 6                // total number of lights in grid (4x*4z = 16 lights)
>   adaptive 0          // 0,1,2,3...
>   jitter              // adds random softening of light
>   translate <7.5, 4, 20>   // <x y z> position of light
>   shadowless
> }
Those are area_lights. Even with adaptive 0 and no_shadow, it take longer to 
render. Here, the use of area_light is totaly useless.

> ....
> [snip]
> ....
> //************ Simulation Box ******
> 
> background { color rgb < 1.000, 1.000, 1.000 >}
> 
> 
> //********** CAMERA *************
> 
> camera { xfrontview }
> 
> //********** ATOMS *************
> 
> declare atoms = union {
> sphere   { <1.34073,2.44067,2.09778>,  0.77 texture{C_tex}}
> sphere   { <0.22055,2.50846,2.75588>,  0.73 texture{O_tex}}
> sphere   { <2.20820,2.40215,2.77242>,  0.32 texture{H_tex}}
> sphere   { <-0.54093,2.52909,2.04946>,  0.32 texture{H_tex}}
> sphere   { <0.07183,-0.04000,-0.02136>,  1.3 texture{Pt_tex}}
> sphere   { <2.90433,-0.03858,-0.02034>,  1.3 texture{Pt_tex}}
> sphere   { <1.50770,2.40207,0.19218>,  1.3 texture{Pt_tex}}
> ....
> [around 100 spheres here]
> [snip]
You can do some optimisation here.
> 
> } // End atom union
> object {atoms rotate <0,0,0> translate <-7.50771, -4.47073, 2.07789> scale
> 0.775927395422}
This part have no effect on the render time.
> 
> 
> 
> 
Each atom is individualy textured. It would be much more effecient to group the 
atoms by element in unions and to apply the textures to those "elemental" 
unions. Then, you bind those unions in the "atoms" union to be able to 
manipulate them all as a single object.

-- 
Alain
-------------------------------------------------
EVERYTHING HAS A GENDER

You may not know this but many nonliving things have a gender...

A Hot Air Balloon is Male, because, to get it to go anywhere, you have to light 
a fire under it, and of course, there's the hot air part.


Post a reply to this message

From: Chambers
Subject: Re: quicker render alternatives to povray
Date: 19 Mar 2008 22:23:42
Message: <47e1d8be$1@news.povray.org>
Rahul wrote:
> Chambers <ben### [at] pacificwebguycom> wrote:
>> Rahul wrote:
>>> Any suggestions are, of course, greatly appreciated!
>> How many spheres are in a typical scene?
>>
>> --
>> ...Ben Chambers
>> www.pacificwebguy.com
> 
> 100 spheres are typical.
> 
> -Rahul

Something's not right here.  I can render a few thousand spheres on my 
Core 2 Duo running at 2.4gHz in <2s.  What hardware are you using, and 
do you have an example scene file?

-- 
...Ben Chambers
www.pacificwebguy.com


Post a reply to this message

From: Kenneth
Subject: Re: quicker render alternatives to povray
Date: 23 Mar 2008 22:55:01
Message: <web.47e724fc72535d7278dcad930@news.povray.org>
Warp <war### [at] tagpovrayorg> wrote:
> Rahul <nomail@nomail> wrote:
> > BTW, I'm pleasantly surprised to see that many other posters actually thought
> > raytracing might be the *fastest* option around!
>
>   This should actually be so when the number of spheres grows (at least when
> there's no reflection nor refraction, ie. basically we are using raycasting),
> especially compared to alternatives like OpenGL.
>
>   This is because as the number of spheres grows, the rendering time of
> OpenGL grows linearly while the rendering time of POV-Ray grows slower
> (I'm not exactly sure how much slower, but probably by O(sqrt(n)) or
> O(log(n)).) This means that at some point POV-Ray indeed becomes faster
> than OpenGL.
>
> --
>                                                           - Warp

That's fascinating; I had no idea. I had *always* thought--in a rather
simple-minded way  :-( --that OpenGL was definitely and always faster than
raytracing. What a surprise!  Thanks. (And thanks to Willaim Tracy also, for
the succinct description of raytracing vs. scanline rendering.) This single
newsgroup post has *really* opened my eyes.

Ken W.


Post a reply to this message

From: William Tracy
Subject: Re: quicker render alternatives to povray
Date: 26 Mar 2008 19:46:40
Message: <47eaee70$1@news.povray.org>
Kenneth wrote:
> --that OpenGL was definitely and always faster than
> raytracing. What a surprise!

Here's possibly an even easier way to think of it.

Scanline rendering renders every object in the scene one at a time, 
whether it needs to or not. If several spheres are stacked on top of 
each other, it will waste time rendering the spheres that are hiding in 
the background.

A raytracer will go to that pixel, and only render the closest object 
for that pixel.

So, if your image has lots of empty space, a scanline renderer won't 
waste time working on that empty space. On the other hand, if you have a 
cluttered scene with object stacked on top of each other, a raytracer 
won't waste time on the objects you can't see anyway.



-- 
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu

The flavor of Redcode used in this guide is (mostly) the current de 
facto standard, the ICWS '94 Standard Draft with pMARS 0.8 extensions. 
(Sort of like the Netscape extensions to HTML... Hmm... Luckily we still 
don't have a Microsoft Corewar Simulator. Maybe they think the market's 
too small.)
     -- Ilmari Karonen, http://vyznev.net/corewar/guide.html


Post a reply to this message

From: Nicolas George
Subject: Re: quicker render alternatives to povray
Date: 27 Mar 2008 03:10:02
Message: <47eb565a$1@news.povray.org>
William Tracy  wrote in message <47eaee70$1@news.povray.org>:
> A raytracer will go to that pixel, and only render the closest object 
> for that pixel.

Tu find the closest object for a pixel, it is necessary to compute the
intersection of the light ray with all objects in the scene, so raw
ray-tracing will definitely not gain time with that regard. To gain time, it
is necessary to use techniques of elimination, using some sort of
hierarchical bounding boxes for example.

I would not be surprised if modern implementations of OpenGL also had
techniques to prune irrelevant objects.


Post a reply to this message

From: Warp
Subject: Re: quicker render alternatives to povray
Date: 27 Mar 2008 05:03:07
Message: <47eb70db@news.povray.org>
William Tracy <wtr### [at] calpolyedu> wrote:
> Scanline rendering renders every object in the scene one at a time,

  Most high-end renderers probably have bounding box optimizations not
asimilar to what POV-Ray uses and thus are faster then a naive scanline
rendering implementation. However, I was mostly comparing POV-Ray to
OpenGL which has no such thing (at least not builtin).

-- 
                                                          - Warp


Post a reply to this message

From: Warp
Subject: Re: quicker render alternatives to povray
Date: 27 Mar 2008 05:05:46
Message: <47eb717a@news.povray.org>
Nicolas George <nicolas$george@salle-s.org> wrote:
> Tu find the closest object for a pixel, it is necessary to compute the
> intersection of the light ray with all objects in the scene, so raw
> ray-tracing will definitely not gain time with that regard. To gain time, it
> is necessary to use techniques of elimination, using some sort of
> hierarchical bounding boxes for example.

  I was comparing POV-Ray to OpenGL, not some naive 100-line raytracer
to OpenGL.

> I would not be surprised if modern implementations of OpenGL also had
> techniques to prune irrelevant objects.

  Nope. It's too difficult of a task.

  Some game engines try to reduce the number of polygons to render with
techniques like portal polygons etc, but OpenGL itself doesn't have anything
like that. And even those techniques used by game engines are of no help
if all you have is a big bunch of spheres (inside the field of view) and
nothing else.

-- 
                                                          - Warp


Post a reply to this message

From: scott
Subject: Re: quicker render alternatives to povray
Date: 27 Mar 2008 13:50:04
Message: <47ebec5c$1@news.povray.org>
>> Write it in OpenGL or DirectX.  A modern machine should be able to draw
>> 10000 spheres in real-time (ie at least 30fps), with per-pixel specular 
>> and
>> diffuse lighting.
>
>  Are you sure about that?

Yes.

>  How many triangles do you need to make a triangle mesh to look even
> remotely as a sphere?

6, with a clever pixel shader it will look perfectly like a sphere :-)  If 
not, then I guess you'd need an average or 100 or so.

> Multiply that by 10000.

1e6 per frame

or 30e6 per second.

Modern cards (eg GeForce 8800) can do 10e9 per second...  Even a several 
year old card can easily handle 30e6 per second.


Post a reply to this message

From: scott
Subject: Re: quicker render alternatives to povray
Date: 27 Mar 2008 13:51:01
Message: <47ebec95@news.povray.org>
> My scene is basically nothing more than a large number of spheres(of 
> different
> sizes and colors) Povray works great for me for rendering an excellent 
> high
> quality final output.
>
> Unfortunately there are parts in my development cycle where I need a 
> faster
> render. Low quality acceptable. Are there any options people would 
> recommend?

See my post in p.o-t.f.h.b.b.b, I wrote a DirectX app to render lots of high 
quality spheres very quickly.


Post a reply to this message

<<< Previous 10 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.