Nicolas George wrote:
> One possible solution would be to generate a SVG file, with radial gradients
> to simulate lightning and specular light, sorting the spheres upon the
> distance to the camera. Then let Inkscape or anything similar rasterize it.

Another idea: Skip the gradients, and paint the spheres with solid 
colors based on distance from the camera (more distant spheres are 
darker). That should be faster to render, and might even be easier to 
interpret visually, even if it won't be as pretty.

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

    "Meanwhile we can't be having a constitution that says only 'don't 
change speed too fast.'"
     -- Kim Stanley Robinson, _Blue Mars_

Post a reply to this message

Nicolas Alvarez wrote:
> He tried +q2 and got no noticeable speedup. q2 disables shadows.

Duh, never mind then. :-P

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

    They laughed. Photons rained on their skin, most shooting right 
through them. Here they were, transparent to the world.
     -- Kim Stanley Robinson, _Blue Mars_

Post a reply to this message

William Tracy <wtr### [at] calpolyedu> wrote:

> Raytracing draws a screen one pixel at a time, regardless of how many
> shapes there are. Its speed is more complicated, but is usually limited
> by a combination of resolution (number of pixels it has to draw) and the
> number of recursive calls it has to make (shadows and reflections).

Thanks for that insight into raytracer performance William. I'll admit I was
pretty ignorant about these details before.

> BTW, random thought--have you tried making all the light sources shadowless?

Hmm...had never thought of that. But just checked. They are both shadow less.

-Rahul

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:


> SVG only supports 2D. But if you do your own 3D->2D projection,
> rendering that 2D image would probably be faster than raytracing.

Thanks Nicolas. I could do that. Or shift to VRML? Any thoughts about that one?
Seems to have markup and CSG primitives similar to povray. I just need to
benchmark the performance of the VRML players out there.  Any thoughts here
guys?

-Rahul

Post a reply to this message

William Tracy <wtr### [at] calpolyedu> wrote:


> Another idea: Skip the gradients, and paint the spheres with solid
> colors based on distance from the camera (more distant spheres are
> darker). That should be faster to render, and might even be easier to
> interpret visually, even if it won't be as pretty.

That might be a good idea William. Pretty isn't important to me right now. So
long as there is a reasonable degree of depth cue for the users to get a 3D
perspective and they can discriminate between the different sphere types
("colors") I'm good.

Thanks guys! So many great suggestions. I just need the time to try them out
now.
Some of them have potential to lead me off an interesting tangent too! eg. VRML
players might open up possibilities for actual real-time interaction and
manipulation of the images too. Only based on an optimistic assessment of their
performance potential.

-Rahul

Post a reply to this message

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

Post a reply to this message

If you are using a dual core (ore more) and  Pov-Ray 3.6, I would suggest 
3.7 beta. Maybe +rtr as well, but I don't know how that fits into your 
scenario.


-- 
-Nekar Xenos-

Post a reply to this message

Rahul nous apporta ses lumieres en ce 2008/03/16 16:19:
> I use povray to render molecules from co-ordinate files. Unfortunately the
> specifics of my problem demand that I write my own parser (rather than use VMD
> , rasmol etc.) that parses from my coordinates to a .pov.
> 
> 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?
> 
> I dont even need the full ammunition of a raytracer. But something that could
> act on  a similar-to-povray file would be ideal. (or something that a povray
> ...pov file could easily be parsed into)
> 
> The idea is to allow users to adjust molecular positions in an editor (vi or
> emacs) and have a second window display these changes dynamically. So I need
> something fast. I know I can probably code it in OpenGL or something but I was
> just checking if there are other easier alternatives?
> 
> 
> Any suggestions are, of course, greatly appreciated!
> 
> -Rahul
> 
> 
> 
Try puting all spheres representing the same element in an union, and assigh the 
pigment to that union. That mean about 4 unions for most organic molecules: 
carbon, hydrogen, oxygen and nitrogen.
If all, or most, spheres use the same finish, set that finish as the default 
finish. Do the same for the proeminent pigment like:
#default texture{pigment{Carbon}finish{Your_finish}}

This can make the scene file smaller, saving some parsing time. It will also 
take less RAM once parsed.

Try adding +q2 to the command line.
q0 and q1 ambient light only, plain pigments as texture.
q2 and q3 simple point light only, no transparency, no reflections, no shadows.
q4 add shadows.
q5 add area_light.
q6 and q7 add textures, support photons.
q8 add reflections, transparency and refraction. Still no media.
q9, 10, 11 all features enabled.

Turn off antialiasing.

Use a lower resolution, and use a lower screen resolution.

Does it need to access the swap file? (LOTS of disk activity) Add more RAM.

Get a faster computer, with a powerfull CPU, lots of RAM, video card unimportent.

-- 
Alain
-------------------------------------------------
Either write something worth reading or do something worth writing.
Benjamin Franklin

Post a reply to this message

Nekar Xenos nous apporta ses lumieres en ce 2008/03/17 16:14:
> If you are using a dual core (ore more) and  Pov-Ray 3.6, I would suggest 
> 3.7 beta. Maybe +rtr as well, but I don't know how that fits into your 
> scenario.
> 
> 
+rtr is good if your model don't change and only the camera is moving around.


-- 
Alain
-------------------------------------------------
When you don’t know what to do, walk fast and look worried.

Post a reply to this message

>> Are there other codes out there that can operate on a "scene definition
>> language" and render a scene albeit with a "shortcut" visualization 
>> method.
> 
> You should see if this (old) POV-Ray OpenGL Patch does what you need, at 
> an acceptable speed:
> 
> http://www.daylongraphics.com/other/povray/patches/
> 
> It supports wireframe for a bunch of objects, and solid rendering only 
> for spheres (with *no* textures, spheres always show in gray).
> 
> http://www.daylongraphics.com/other/povray/patches/#solid

*bump*

Post a reply to this message