I'm not happy with what I've seen so far in terms of rendering 3D graphs in
Python. I want to be able to draw many points in 3D, each with its own
coordinates and other attributes such as size and color, and render the scene
with optional dynamic parameters (such as rotating it around some axis).

But that would mean POV-Ray would have to take a scene file with thousands of
small objects (the dots), each point being a small opaque sphere. The file will
be machine-generated and fairly large. Should I be concerned with the
performance of the renderer?

The scene will otherwise be simple - I will draw a system of coordinates, and
optionally grids of coordinates. I'm not planning on using textures.

Post a reply to this message

"Florin Andrei" <nomail@nomail> wrote:
> I'm not happy with what I've seen so far in terms of rendering 3D graphs in
> Python. I want to be able to draw many points in 3D, each with its own
> coordinates and other attributes such as size and color, and render the scene
> with optional dynamic parameters (such as rotating it around some axis).
>
> But that would mean POV-Ray would have to take a scene file with thousands of
> small objects (the dots), each point being a small opaque sphere. The file will
> be machine-generated and fairly large. Should I be concerned with the
> performance of the renderer?
>
> The scene will otherwise be simple - I will draw a system of coordinates, and
> optionally grids of coordinates. I'm not planning on using textures.


I'm sometime using POV-Ray as you're describing and I'm satisfied with the
results. However it completely depends on your particular project. What machine
do you use for rendering, what time do you expect for rendering, how many frames
in your animation, how many objects and which rendering parameters, etc...
A short animation with basic rendering parameters and few thousands of sphere,
on a modern computer, doesn't look to me as a big deal.

Pascal

Post a reply to this message

> I'm not happy with what I've seen so far in terms of rendering 3D graphs in
> Python. I want to be able to draw many points in 3D, each with its own
> coordinates and other attributes such as size and color, and render the scene
> with optional dynamic parameters (such as rotating it around some axis).
> 
> But that would mean POV-Ray would have to take a scene file with thousands of
> small objects (the dots), each point being a small opaque sphere. The file will
> be machine-generated and fairly large. Should I be concerned with the
> performance of the renderer?
> 
> The scene will otherwise be simple - I will draw a system of coordinates, and
> optionally grids of coordinates. I'm not planning on using textures.
> 

There are scenes containing several millions of objects that render 
rather quickly. I recently rendered a scene containing over 50 000 000 
cones using high quality radiosity that rendered in about 12 hours. It 
was a fractal from an old IRTC contest where I increased recursion level 
by 3 and added radiosity.

As your objects are simple spheres (one of the faster shape to render), 
opaque, non-reflective, counting only in the thousands and plain 
texturing, POV-Ray should have no problem rendering it.
In the case of large files, simple shapes, parsing time is often 
affected more than render time.

On a modern computer, memory requirement is a non-issue for even 
millions of spheres. Those could even be individually textured with 
almost no effect on the performance.

I would suggest using +bm2 on the command line to use the octree 
partitioning feature. When you have thousands of objects, it usually 
improve the rendering performance.

Post a reply to this message

"Florin Andrei" <nomail@nomail> wrote:
> I'm not happy with what I've seen so far in terms of rendering 3D graphs in
> Python. I want to be able to draw many points in 3D, each with its own
> coordinates and other attributes such as size and color, and render the scene
> with optional dynamic parameters (such as rotating it around some axis).

Just something you may be interested in, from an aesthetics point of view:
http://scpovplot3d.sourceforge.net/

> But that would mean POV-Ray would have to take a scene file with thousands of
> small objects (the dots), each point being a small opaque sphere. The file will
> be machine-generated and fairly large. Should I be concerned with the
> performance of the renderer?

Absolutely not.  Thousands is trivial, millions is not a problem.

> The scene will otherwise be simple - I will draw a system of coordinates, and
> optionally grids of coordinates. I'm not planning on using textures.

I would say that if you are writing an include file with python, then all you'd
need to do is write it as an array of the centers of the spheres, and the radii.
 You may find that implementing your scene using blobs and not spheres could be
faster.

There's also the possibilities of writing your data as a df3 file and rendering
it as media, or using the df3 file to render it as an isosurface.  Just for
playing around.

But overall, what you're looking to do should even be challenging for POV-Ray to
handle and render in minutes, if not less.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:

> I would say that if you are writing an include file with python, then all you'd
> need to do is write it as an array of the centers of the spheres, and the radii.
>

That's a good idea-- to then let POV-ray create the objects themselves from the
very simple point data and radii; makes for a smaller #include file as well.

> You may find that implementing your scene using blobs and not spheres could be
> faster.

Blobs are faster to parse and render than simple spheres? I didn't know that!

Overall, it sounds like #read-ing the generated data file from disc as an
#include file would be the only time concern, re: parsing; Alain's extreme
example of 50 000 000 'things'--even as simple data points/radii-- might take a
fair amount of time to #read. But I've never used such a really huge .inc file,
so I don't know for sure.

Post a reply to this message

> 
> Blobs are faster to parse and render than simple spheres? I didn't know that!
> 

Not parse faster. The rendering can benefit from the internal bounding 
and hierarchy mechanism of the blob.

> Overall, it sounds like #read-ing the generated data file from disc as an
> #include file would be the only time concern, re: parsing; Alain's extreme
> example of 50 000 000 'things'--even as simple data points/radii-- might take a
> fair amount of time to #read. But I've never used such a really huge .inc file,
> so I don't know for sure.
> 
> 
> 

In my case, it was done using a recursive macro. The parsing time was a 
little over 10 minutes, the bounding time using +bm2 about 2 to 3 minutes.

Parsing of a sequential cluster of 75000 small spheres should not take 
more than about a minute. The bounding time only a few seconds.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

> Blobs are faster to parse and render than simple spheres? I didn't know that!

As Alain pointed out, it's a bounding thing - might be interesting to add some
time stamps and compare spheres vs blobs.

> Overall, it sounds like #read-ing the generated data file from disc as an
> #include file would be the only time concern, re: parsing; Alain's extreme
> example of 50 000 000 'things'--even as simple data points/radii-- might take a
> fair amount of time to #read. But I've never used such a really huge .inc file,
> so I don't know for sure.

No - don't use #read.  Write directly to an include file the text defining the
array.

#declare PointsAndRadii = array {
.....
}

Then just include that file.  Get the dimension_size of the array, then loop
through it to instantiate all of the spheres/blobs.

Post a reply to this message

On 12/09/2021 23:52, Florin Andrei wrote:
> I'm not happy with what I've seen so far in terms of rendering 3D graphs in
> Python. I want to be able to draw many points in 3D, each with its own
> coordinates and other attributes such as size and color, and render the scene
> with optional dynamic parameters (such as rotating it around some axis).
> 
> But that would mean POV-Ray would have to take a scene file with thousands of
> small objects (the dots), each point being a small opaque sphere. The file will
> be machine-generated and fairly large. Should I be concerned with the
> performance of the renderer?
> 
> The scene will otherwise be simple - I will draw a system of coordinates, and
> optionally grids of coordinates. I'm not planning on using textures.
> 

Very easy. POV-Ray is able to read data from file.
Look at this page.
<http://www.povray.org/documentation/view/3.6.2/238/>

Your Python script can write data to a file with (for exemple) the3DPos 
(a vector), theSphereRadius (a scalar) and theColor (a color).
Each value separated with ","

The POV code open the file, read lines and for each of them define a 
sphere at the the3DPos with radius = theSphereRadius, and a 
pigment=theColor.

Simplified code :
#fopen FILE fileName read
#while (defined(FILE))
  #read (FILE,p,r,c)
  sphere { p, r pigment { color c } }
#end
#fclose FILE



there are always several ways to code ;)



-- 
Kurtz le pirate
Compagnie de la Banquise

Post a reply to this message

hi,

"Kenneth" <kdw### [at] gmailcom> wrote:
> ...
> example of 50 000 000 'things'--even as simple data points/radii-- might take a
> fair amount of time to #read. But I've never used such a really huge .inc file,
> so I don't know for sure.

nor me, so had to try it :-).  on a machine with 16G memory, I stopped at
writing/reading "only" ten million point+radius pairs, POV-Ray then uses already
2.6G.  fwiw, writing took around 150 seconds, reading back about 90 secs.


regards, jr.

Post a reply to this message