f_helix1(x,y,z,n,p,r,R,s,c,a)
supposedly, the fifth parameter is the period, or "Number of turns per unit
length".

The way I read this is that, for every unit the helix object rises, it should
make one complete turn.  This is obviously not the case.

isosurface {
    function { f_helix1(x, y, z, 1, 1, 0.25, 0.75, 1.5, 1.0, 0.0) }
    max_gradient 4
    threshold 0
    contained_by { box { <-1, 0, -1> <1, 10, 1> } }
    }

this should make 10 complete turns, and it only makes about one and a half.

Regards,
A.D.B.

Post a reply to this message

"Anthony D. Baye" <Sha### [at] spamnomorehotmailcom> wrote:
> f_helix1(x,y,z,n,p,r,R,s,c,a)
> supposedly, the fifth parameter is the period, or "Number of turns per unit
> length".
>
> The way I read this is that, for every unit the helix object rises, it should
> make one complete turn.  This is obviously not the case.

Anthony, I can confirm same here.

Slightly different wording found in the Insert menu, Special shapes|Isosurfaces
by function.inc and placing the Isosurface f_helix into a scene file, so I went
looking for the source code after realizing it was essentially saying the number
of turns is based on a complete circle. Meaning if you apply that 2*pi to your
number of turns you should get what you expected. I checked this and seemed to
work.

Source code makes very little sense to me, although a coding math wizard
probably could get the 2*pi introduced into there somehow.

You can look it over yourself at (line 519):

https://github.com/POV-Ray/povray/blob/3.7-stable/source/backend/vm/fnintern.cpp

Guessing it's the r or r2 variables which would require the 2*pi to complete
whole turns for the "period" parameter.

Looking at the online documentation, almost halfway down page at:

http://www.povray.org/documentation/view/3.7.0/448/

I see it also says "related" to number of turns, suggesting again it wasn't
actually made to do a user-specified amount.
Interesting thing, if not, because I would have thought same as you did.

Post a reply to this message

Le 11/12/2014 09:34, omniverse a écrit :
> "Anthony D. Baye" <Sha### [at] spamnomorehotmailcom> wrote:
>> f_helix1(x,y,z,n,p,r,R,s,c,a)
>> supposedly, the fifth parameter is the period, or "Number of turns per unit
>> length".
>>
>> The way I read this is that, for every unit the helix object rises, it should
>> make one complete turn.  This is obviously not the case.
> 
> Anthony, I can confirm same here.
> 
> Slightly different wording found in the Insert menu, Special shapes|Isosurfaces
> by function.inc and placing the Isosurface f_helix into a scene file, so I went
> looking for the source code after realizing it was essentially saying the number
> of turns is based on a complete circle. Meaning if you apply that 2*pi to your
> number of turns you should get what you expected. I checked this and seemed to
> work.
> 
> Source code makes very little sense to me, although a coding math wizard
> probably could get the 2*pi introduced into there somehow.
> 
> You can look it over yourself at (line 519):
> 
> https://github.com/POV-Ray/povray/blob/3.7-stable/source/backend/vm/fnintern.cpp
> 
> Guessing it's the r or r2 variables which would require the 2*pi to complete
> whole turns for the "period" parameter.
> 
> Looking at the online documentation, almost halfway down page at:
> 
> http://www.povray.org/documentation/view/3.7.0/448/
> 
> I see it also says "related" to number of turns, suggesting again it wasn't
> actually made to do a user-specified amount.
> Interesting thing, if not, because I would have thought same as you did.
> 
> 
> 

So, it is per radian rather than per turn ?

-- 
Just because nobody complains does not mean all parachutes are perfect.

Post a reply to this message

On 12/11/2014 4:22 AM, Le_Forgeron wrote:
> Le 11/12/2014 09:34, omniverse a écrit :
>> "Anthony D. Baye" <Sha### [at] spamnomorehotmailcom> wrote:
>>> f_helix1(x,y,z,n,p,r,R,s,c,a)
>>> supposedly, the fifth parameter is the period, or "Number of turns per unit
>>> length".
>>>
>>> The way I read this is that, for every unit the helix object rises, it should
>>> make one complete turn.  This is obviously not the case.
>>
>> Anthony, I can confirm same here.
>>
>> Slightly different wording found in the Insert menu, Special shapes|Isosurfaces
>> by function.inc and placing the Isosurface f_helix into a scene file, so I went
>> looking for the source code after realizing it was essentially saying the number
>> of turns is based on a complete circle. Meaning if you apply that 2*pi to your
>> number of turns you should get what you expected. I checked this and seemed to
>> work.
>>
>> Source code makes very little sense to me, although a coding math wizard
>> probably could get the 2*pi introduced into there somehow.
>>
>> You can look it over yourself at (line 519):
>>
>> https://github.com/POV-Ray/povray/blob/3.7-stable/source/backend/vm/fnintern.cpp
>>
>> Guessing it's the r or r2 variables which would require the 2*pi to complete
>> whole turns for the "period" parameter.
>>
>> Looking at the online documentation, almost halfway down page at:
>>
>> http://www.povray.org/documentation/view/3.7.0/448/
>>
>> I see it also says "related" to number of turns, suggesting again it wasn't
>> actually made to do a user-specified amount.
>> Interesting thing, if not, because I would have thought same as you did.
>>
>>
>>
>
> So, it is per radian rather than per turn ?
>


Radians per unit length, I think.

Post a reply to this message

"omniverse" <omn### [at] charternet> wrote:
> "Anthony D. Baye" <Sha### [at] spamnomorehotmailcom> wrote:
> > f_helix1(x,y,z,n,p,r,R,s,c,a)
> > supposedly, the fifth parameter is the period, or "Number of turns per unit
> > length".
> >
> > The way I read this is that, for every unit the helix object rises, it should
> > make one complete turn.  This is obviously not the case.
>
> Anthony, I can confirm same here.
>
> Slightly different wording found in the Insert menu, Special shapes|Isosurfaces
> by function.inc and placing the Isosurface f_helix into a scene file, so I went
> looking for the source code after realizing it was essentially saying the number
> of turns is based on a complete circle. Meaning if you apply that 2*pi to your
> number of turns you should get what you expected. I checked this and seemed to
> work.
>
> Source code makes very little sense to me, although a coding math wizard
> probably could get the 2*pi introduced into there somehow.
>
The source makes very little sense, period.  I tried tracing the path for the
command line options to find out the answer for another question, and I couldn't
figure out where anything was handled.

I found references to several apparently different functions called "trace" but
nowhere could I find definitions or forward declarations for them. (I downloaded
the zip of the master and went through it using grep)

It would make more sense -to me, at least- for command line parsing to be more
centralized, with options and their values stored in a dictionary that could be
queried by various modules, but that's just my opinion.  It may be that there
would be some undesirable overhead in that method, but it would seem to me that
maintainability would win out.

At any rate, it makes no sense for the period of a helix to be based on length
of the curve.  Could something have gotten mixed up between this and the
toroidal form?

Regards,
A.D.B.

Post a reply to this message

"Anthony D. Baye" <Sha### [at] spamnomorehotmailcom> wrote:
> "omniverse" <omn### [at] charternet> wrote:
> > "Anthony D. Baye" <Sha### [at] spamnomorehotmailcom> wrote:
> > > f_helix1(x,y,z,n,p,r,R,s,c,a)
> > > supposedly, the fifth parameter is the period, or "Number of turns per unit
> > > length".
> > >
> > > The way I read this is that, for every unit the helix object rises, it should
> > > make one complete turn.  This is obviously not the case.
> >
> > Anthony, I can confirm same here.
> >
> > Slightly different wording found in the Insert menu, Special shapes|Isosurfaces
> > by function.inc and placing the Isosurface f_helix into a scene file, so I went
> > looking for the source code after realizing it was essentially saying the number
> > of turns is based on a complete circle. Meaning if you apply that 2*pi to your
> > number of turns you should get what you expected. I checked this and seemed to
> > work.
> >
> > Source code makes very little sense to me, although a coding math wizard
> > probably could get the 2*pi introduced into there somehow.
> >
> The source makes very little sense, period.  I tried tracing the path for the
> command line options to find out the answer for another question, and I couldn't
> figure out where anything was handled.
>
> I found references to several apparently different functions called "trace" but
> nowhere could I find definitions or forward declarations for them. (I downloaded
> the zip of the master and went through it using grep)
>
> It would make more sense -to me, at least- for command line parsing to be more
> centralized, with options and their values stored in a dictionary that could be
> queried by various modules, but that's just my opinion.  It may be that there
> would be some undesirable overhead in that method, but it would seem to me that
> maintainability would win out.
>
> At any rate, it makes no sense for the period of a helix to be based on length
> of the curve.  Could something have gotten mixed up between this and the
> toroidal form?

Or it could be based on the math for a helicoid:
http://mathworld.wolfram.com/Helicoid.html

since it doesn't seem to maintain its shape very well w/r/t different parameters
for min and max radius.  Wouldn't it be better to plot the shape in the
normal plane? http://mathworld.wolfram.com/Helix.html

See: osculating plane -> normal plane

Keep in mind that my math skills aren't stellar.  Some things I can keep up
with. Others, not so much.

Regards,
A.D.B.

P.S. more comments in the code would help.  Not every programmer is a math
genius. My programming instructors would have docked me letter grades. (I'm not
trying to start a flame war here or point fingers.  I know this codebase was
written by a lot of different people over quite a long time, and I understand
that cleanup is an ongoing process.)

http://yarenty.blogspot.com/2014/03/pants-on-fire-9-lies-that-programmers.html
I'm guilty of a few of these.

A.D.B.

Post a reply to this message

On 11.12.14 23:45, Anthony D. Baye wrote:
> The source makes very little sense, period.  I tried tracing the path for the
> command line options to find out the answer for another question, and I couldn't
> figure out where anything was handled.

The code makes sense if you know how to build parallel and/or distributed 
software. Then you also know what design patterns to look for ;-)

All communication between threads is handled via message passing, and all 
computations are handled in worker threads that get created based on 
messages with commands that tell the code to do so. Hence you cannot follow 
a simple call chain in a parallel and/or distributed program because there 
isn't one!

Imagine this like modern manufacturing where parts of products are produced 
in different countries around the globe. If you only look at he 
manufacturing plants, you will never figure out how a whole product is made 
from beginning to end because some plants might get half-finished parts from 
other plants, add a piece and then send them elsewhere for assembly. What 
you need to know is the freight traffic between those plants to figure out 
what product depends on which pre-produced part. The plants are the threads 
and the freight traffic are the messages in POV-Ray 3.7...

> I found references to several apparently different functions called "trace" but
> nowhere could I find definitions or forward declarations for them. (I downloaded
> the zip of the master and went through it using grep)
 >
> It would make more sense -to me, at least- for command line parsing to be more
> centralized, with options and their values stored in a dictionary that could be
> queried by various modules, but that's just my opinion.  It may be that there
> would be some undesirable overhead in that method, but it would seem to me that
> maintainability would win out.

Depending on where you looked (i.e. Windows version) it can be a bit 
complicated to find the start. It is easier to start with the native main 
function in 
https://github.com/POV-Ray/povray/blob/3.7-stable/source/backend/povray.cpp 
line 677. Parsing the command line starts in line 753 with the creation of 
the ProcessRenderOptions object. Parsing takes place for command line 
arguments in line 765 with the call to renderoptions.ParseString, with all 
values stored in the POVMS object 'obj', which is then passed to 
frontend.Start in 780, which sends it to the backend.

The actual parsing takes place in the class ProcessOptions, while the 
specific implementation is included in the derived class 
ProcessRenderOptions 
https://github.com/POV-Ray/povray/blob/3.7-stable/source/frontend/processrenderoptions.cpp

. Most important are the tables starting in line 89 for INI options and in 
line 235 for the command line options. Most of the magic of command line 
parsing can be seen in ProcessRenderOptions::ProcessUnknownString starting 
on line 823.

In the backend the parsed object appears again in 
https://github.com/POV-Ray/povray/blob/3.7-stable/source/backend/scene/scene.cpp 
in line 437, where it arrives as argument of Scene::StartParser. Later is 
arives again, this time in 
https://github.com/POV-Ray/povray/blob/3.7-stable/source/backend/scene/view.cpp 
line 668 as argument of View::StartRender. Tracing is started in line 1135 
for the main image (radiosity pretace etc happened earlier).

So now you arrive in 
https://github.com/POV-Ray/povray/blob/3.7-stable/source/backend/render/tracetask.cpp 
line 215 with takes all the data and initializes the state of the tracing 
code. Then eventually TraceTask::Run in  line 263 is called, which selects 
the different tracing methods. The actual tracing takes place with the 
various calls to the 'trace' object, which is of class TracePixel. Here the 
function operator in line 258 of 
https://github.com/POV-Ray/povray/blob/3.7-stable/source/backend/render/tracepixel.cpp

takes care of tracing by calling the method TraceRay from the parent class 
Trace. So you continue looking in 
https://github.com/POV-Ray/povray/blob/3.7-stable/source/backend/render/trace.cpp 
line 108 where Trace::TraceRay does all the work. From here on, you are 
basically in the same code as in 3.6 and before, though the names of 
functions/methods have changed a bit.

     Thorsten

Post a reply to this message