POV-Ray : Newsgroups : povray.general : Thoughts and questions Server Time
24 Nov 2024 20:40:38 EST (-0500)
  Thoughts and questions (Message 1 to 10 of 15)  
Goto Latest 10 Messages Next 5 Messages >>>
From: Bald Eagle
Subject: Thoughts and questions
Date: 15 Aug 2017 11:35:00
Message: <web.599313b857b47162c437ac910@news.povray.org>
I've been wondering about methods to render and speed up rendering certain
shapes - notably isosurfaces (IS) and parametric (PAR) surfaces.

It has been pointed out that scertain methods of describing algebraic surfaces,
such as the polynomial, are fast, compared to IS and PAR.

The obvious question is WHY are some of these methods fast and others slow?

Another question I have is:  What method is used to determine the fineness of
subdivision for calculation of the surface?  Is it a bailout sort of thing, or
is there some link to the pixel-coverage, where nothing finer than a pixel is
calculated?

Finally - considering a long, continued, and current interest in using meshes as
CSG objects,

Would it be possible / desirable to define an internal mesh-generation method
for rendering complex, time-consuming shapes?
It seems like constructing a mesh of smooth triangles would save a lot of
calculation for the surface (via interpolation)(but I could be wrong) - and
doing that as an internal function would be MUCH faster than doing it through
SDL.
Paul Nylander's code for rendering a parametric surface via smooth-triangles:
http://bugman123.com/Physics/Calabi-Yau.zip

And, speaking of "parametrics", it appeared to me that there were several
(obviously related) methods of calculating these - one method perhaps better
suited to a particular case than another.
For instance, a shape defined by spherical coordinates would only have 2
parametric equations - one for phi and the other for theta (u and v).
A shape using Cartesian coordinates obviously needs 3 - one each for x, y, and
z.
Presumably one can use cylindrical, hyperbolic, and other coordinate systems as
well.

Depending upon the complexity and number of calculations, it would seem that a
separate parametric for a 2-equation surface might be evaluated in 2/3 the time
as a 3-term surface.  Which could in extreme cases be the difference between 6
hours and 9 hours....

Thanks as always for listening, and offering any comments and explanations  :)


Post a reply to this message

From: Alain
Subject: Re: Thoughts and questions
Date: 15 Aug 2017 18:05:53
Message: <59937041@news.povray.org>
Le 17-08-15 à 11:31, Bald Eagle a écrit :
> I've been wondering about methods to render and speed up rendering certain
> shapes - notably isosurfaces (IS) and parametric (PAR) surfaces.
> 
> It has been pointed out that scertain methods of describing algebraic surfaces,
> such as the polynomial, are fast, compared to IS and PAR.

There is a polynominal, quadric and quartic primitives.
Here's a unit radius cylinder along the X axis defined as a quadric :
  quadric{<0, 1, 1>, <0, 0, 0>, <0, 0, 0>, -1}

And this is a cone :
quadric{<-1, 1, 1>,  < 0, 0, 0>,  < 0, 0, 0>, 0}

Here's a «folium» shape :
quartic
   {< 0,   0,   0,    0,  0,   0,   0,   0,   0,  2,
      0,   0,  -3,    0,  0,   0,   0,  -3,   0,  0,
      0,   0,   0,    0,  0,   1,   0,   0,   0,  0,
      0,   0,   1,    0,  0>
   }
And a poly (short for polynominal) defining a «glob» :
poly
   {5,
    <-0.5, 0,   0,  -0.5, 0,   0,   0,   0,   0,  0,
      0,   0,   0,   0,   0,   0,   0,   0,   0,  0,
      0,   0,   0,   0,   0,   0,   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,   0,   0,   1,   0,   0>
   }
#declare Sinsurf =
  poly
   {6,
    <    0,   0,   0,    0,  0,   0,   0,   0,   0,  0,
     -1116.226, 0, 0,    0,  0,   0,   0,   0,   0,  0,
         0,   0,   0,    0,  0,   0,   0,   0,   0,  0,
         0,   0,   0,    0,  0,   0,   0,   0,   0,  0,
         0,   0,   0,    0,  0,   0,   0,   0,   0, 18.8496,
         0,   0,   0,    0,  0,   0,   0,   0,   0,  0,
         0,   0,   0,    0,  0,   0,   0,   0,   0,  0,
         0,   0,   0,    0,  0,   0,   0,   0,   0,  0,
         0,   0,  -1,    0>
    }

Look at shapesold.inc and shapesq.inc for more examples.

> 
> The obvious question is WHY are some of these methods fast and others slow?
> 
> Another question I have is:  What method is used to determine the fineness of
> subdivision for calculation of the surface?  Is it a bailout sort of thing, or
> is there some link to the pixel-coverage, where nothing finer than a pixel is
> calculated?

That's the role of the «accuracy» parameter found in isosurface and 
parametric. The max_gradient parameter also play a capital role. The 
subdivision is along the tracing ray from the camera outward, possibly 
after some reflection or refraction.
There is no sampling between pixels unless antialiasing kicks in.

> 
> Finally - considering a long, continued, and current interest in using meshes as
> CSG objects,
> 
> Would it be possible / desirable to define an internal mesh-generation method
> for rendering complex, time-consuming shapes?
> It seems like constructing a mesh of smooth triangles would save a lot of
> calculation for the surface (via interpolation)(but I could be wrong) - and
> doing that as an internal function would be MUCH faster than doing it through
> SDL.

Converting an arbitrary shape into a mesh is absolutely not trivial. 
Especially if that shape have any overhangs or holes/bubbles in it.
You may want to take a look at meshmaker.inc
Note that there are no general or universal way to make that conversion. 
Many shapes demand custom, specific to them, methods, and it may not 
always be accurate.


Post a reply to this message

From: Bald Eagle
Subject: Re: Thoughts and questions
Date: 16 Aug 2017 10:20:01
Message: <web.59945437f6e87b3ac437ac910@news.povray.org>
Alain <kua### [at] videotronca> wrote:

Thanks Alain - I'm familiar with all of the primitives and syntaxes - my
question was a deeper one, relating to the source-code/method of generating the
surface.

> > The obvious question is WHY are some of these methods fast and others slow?

I mean, why should there be *ANY* speed difference between an isosurface and a
parametric describing the same surface, and why should the polynomial equivalent
be faster than both of those?

I can only imagine that there must be some increased number of calculations
using one way compared to another, which would account for the speed difference.
 But if we only need to calculate enough points to get "good coverage" - all the
contiguous visible pixels of the surface - then why would there be so many
calculations to slow down the parsing?
And if we're talking about calculating only the pixels that a ray intersects,
then distance from the camera or scaling of the object should impact the speed
with which such a surface renders - scale {0.000001} might make the whole
parametric only cover a single pixel - so why calculate it in its entirety?


> > Another question I have is:  What method is used to determine the fineness of
> > subdivision for calculation of the surface?  Is it a bailout sort of thing, or
> > is there some link to the pixel-coverage, where nothing finer than a pixel is
> > calculated?
>
> That's the role of the «accuracy» parameter found in isosurface and
> parametric. The max_gradient parameter also play a capital role. The
> subdivision is along the tracing ray from the camera outward, possibly
> after some reflection or refraction.

I was under the impression that the primitive was constructed during parsing -
and was independent of the pixel coverage - which would only be relevant at the
time of rendering.  Which is why I'm asking.

> There is no sampling between pixels unless antialiasing kicks in.

There must be calculation "between the pixels" for these surfaces, otherwise one
would only need to provide very small numbers for accuracy, and speed would
never suffer.
I'm envisioning the surface is essentially a point cloud calculated during
parsing, and then the pixels get interpolated (if needed) during rendering.


> > Would it be possible / desirable to define an internal mesh-generation method
> > for rendering complex, time-consuming shapes?

> Converting an arbitrary shape into a mesh is absolutely not trivial.
> Especially if that shape have any overhangs or holes/bubbles in it.
> You may want to take a look at meshmaker.inc
> Note that there are no general or universal way to make that conversion.

Not for arbitrary shapes - but for mathematical ones, it seems pretty
straightforward.  If you lokk at Nylander's code, and the isosurface estimator,
and meshmaker, etc, I'm sure that's how they construct the meshes for those
alternate methods.  And it's "easy" and reliable - because the surfaces are
mathematical.   If they were arbitrary CSG shapes, it would be much more
difficult - the recent work on generating fillets for CSG objects comes to mind.
 Clipka said that if it were _already_ a mesh, it would be "trivial" (no details
provided), but going FROM the CSG of mathematical objects TO a mesh is not (as I
and others have discovered with some of our experiments).

> Many shapes demand custom, specific to them, methods, and it may not
> always be accurate.

True, but I can always project a rectangle onto the surface of a globe - no
matter the terrain, and get the 4 corners.  If the globe is a parametric object
in spherical coordinates, then the finer I subdivide it into rectangles, the
better my approximation will be.
There are no special cases - it's a general method.


Post a reply to this message

From: Bald Eagle
Subject: Re: Thoughts and questions
Date: 16 Aug 2017 12:35:01
Message: <web.5994742df6e87b3ac437ac910@news.povray.org>
Oooh.
And speaking of meshes:

https://www.cise.ufl.edu/~xwu/Pov-Sub/

"This is an expansion of POV-Ray (Persistence of Vision Raytracer), a very
popular (and free!) ray-tracing software. We enhanced the POV-Ray rendering
kernel with subdivision surfaces (Loop's Scheme). With this expanded version,
you can easily create high-quality ray-tracing images using smooth subdivision
surfaces."


Post a reply to this message

From: Kenneth
Subject: Re: Thoughts and questions
Date: 16 Aug 2017 22:40:00
Message: <web.599500f7f6e87b3a883fb31c0@news.povray.org>
"Bald Eagle" <cre### [at] netscapenet> wrote:
> Oooh.
> And speaking of meshes:
>
> https://www.cise.ufl.edu/~xwu/Pov-Sub/
>
That looks interesting-- a version of POV-Ray with built-in mesh subdivision.
(Looks like it was based on v3.6, though?) I initially thought 'Loop's Scheme'
was some kind of method or algorithm; but it's actually the name of the guy who
throught it up! I've also been reading some of the technical papers referenced
there (and the original university Math thesis on the subject.) Good stuff.

Apparently the program download is just a different version of Pov-ray's
'pvengine' file, to be substituted for the standard one. I might get curious and
try it out in some version of v3.7xx... to see what happens... ;-)


Post a reply to this message

From: omniverse
Subject: Re: Thoughts and questions
Date: 17 Aug 2017 01:30:00
Message: <web.5995296af6e87b3a9c5d6c810@news.povray.org>
"Kenneth" <kdw### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > Oooh.
> > And speaking of meshes:
> >
> > https://www.cise.ufl.edu/~xwu/Pov-Sub/
> >
> That looks interesting-- a version of POV-Ray with built-in mesh subdivision.
> (Looks like it was based on v3.6, though?) I initially thought 'Loop's Scheme'
> was some kind of method or algorithm; but it's actually the name of the guy who
> throught it up! I've also been reading some of the technical papers referenced
> there (and the original university Math thesis on the subject.) Good stuff.
>
> Apparently the program download is just a different version of Pov-ray's
> 'pvengine' file, to be substituted for the standard one. I might get curious and
> try it out in some version of v3.7xx... to see what happens... ;-)

Well, me too. Tried and failed, with both 3.7 and 3.6.

Apparently needs old editor DLL's, and MegaPOV seem to be the right ones after I
searched for answers about the error message.
Those DLL's are Cmax20.dll version 2.1.0.13 and Cmedit.dll version 3.5.0.0 that
I had here.

And although that will run the program with editor, there's no connection to the
povray.ini and/or file paths to the includes.
To check the example scenes I just added full path names, but that's only for
the scenes needing colors.inc, textures.inc...

Program freezes, "not responding", so had to close via Task Manager.
This being in Win10.

Bob


Post a reply to this message

From: Thomas de Groot
Subject: Re: Thoughts and questions
Date: 17 Aug 2017 02:42:49
Message: <59953ae9$1@news.povray.org>
On 17-8-2017 7:28, omniverse wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>> "Bald Eagle" <cre### [at] netscapenet> wrote:
>>> Oooh.
>>> And speaking of meshes:
>>>

Note that subdividing meshes (mesh or mesh2) can easily be done nowadays 
using Poseray. But you probably knew this already.

-- 
Thomas


Post a reply to this message

From: Kenneth
Subject: Re: Thoughts and questions
Date: 17 Aug 2017 03:05:01
Message: <web.59953f4ef6e87b3a883fb31c0@news.povray.org>
Thomas de Groot <tho### [at] degrootorg> wrote:
> >>
> >> "Bald Eagle" <cre### [at] netscapenet> wrote:
> >>> Oooh.
> >>> And speaking of meshes:
> >>>
>
> Note that subdividing meshes (mesh or mesh2) can easily be done nowadays
> using Poseray. But you probably knew this already.
>

I didn't :-( :-(  I confess to not having had a need to use Poseray in a long
time (only because I've been concentrating on modelling solely within POV-Ray.)

Thanks for the info!


Post a reply to this message

From: Thomas de Groot
Subject: Re: Thoughts and questions
Date: 17 Aug 2017 07:14:34
Message: <59957a9a$1@news.povray.org>
On 17-8-2017 9:01, Kenneth wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>>>>
>>>> "Bald Eagle" <cre### [at] netscapenet> wrote:
>>>>> Oooh.
>>>>> And speaking of meshes:
>>>>>
>>
>> Note that subdividing meshes (mesh or mesh2) can easily be done nowadays
>> using Poseray. But you probably knew this already.
>>
> 
> I didn't :-( :-(  I confess to not having had a need to use Poseray in a long
> time (only because I've been concentrating on modelling solely within POV-Ray.)
> 

I understand. I must say that I use Poseray /almost/ on a daily basis ;-)

> Thanks for the info!

My pleasure.

-- 
Thomas


Post a reply to this message

From: Stephen
Subject: Re: Thoughts and questions
Date: 17 Aug 2017 07:47:47
Message: <59958263@news.povray.org>
On 8/17/2017 12:14 PM, Thomas de Groot wrote:
> On 17-8-2017 9:01, Kenneth wrote:
>> Thomas de Groot <tho### [at] degrootorg> wrote:

>> I didn't :-( :-(  I confess to not having had a need to use Poseray in
>> a long
>> time (only because I've been concentrating on modelling solely within
>> POV-Ray.)
>>
>
> I understand. I must say that I use Poseray /almost/ on a daily basis ;-)
>

So do I but then we both use Poser models.




-- 

Regards
     Stephen


Post a reply to this message

Goto Latest 10 Messages Next 5 Messages >>>

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