"Bald Eagle" <cre### [at] netscapenet> wrote:
> Add these lines to the top of your file:
>
> #version 3.7;
> global_settings { assumed_gamma 1.0 }
> #include "colors.inc"


My code includes these lines, of course. I just had forgotten to copy them here
:)



>
>
> For your prism, if you are only making a square, then you only need 5 points
> instead of 7.   Your last 2 points are redundant.
>  prism {
>     linear_sweep
>     linear_spline
>     0,
>     0,
>     7,
>     <-2,-3>,<2,-3>, <2,0>, <2,3>, <-2, 3>, <-2,0>, <-2,-3>
>     pigment { Blue }
>   }

I am aware of the fact that only four different points are neccessary to define
the rectangle. The reason why I used six Points and not only four is that I
wanted to assign a spline line to each one of the six points. In that way, the
corners of the rectangle plus 2 points in the middle of both long sides would be
translated according to the (position) data I take from the Vibration file.



> If you could attach a copy of your data set, and maybe a diagram of the location
> of the points on the plate, it would be easier understand the full scope, and to
> head off anything that would need to be rewritten.
>

I uploaded three files: the vibration data as txt file, a diagram of the plate
with the real location of the measurement points and a diagram of the plate with
the measurement points located at the Corners, which corresponds to the code I
included here, where I intended to animate a "starting scenario".
(see
http://news.povray.org/povray.binaries.scene-files/thread/%3Cweb.56d82b80a405651b7f2c2ccf0%40news.povray.org%3E/)

Post a reply to this message

On 03.03.2016 3:43, Bald Eagle wrote:

> Is there a way to calculate where the control point needs to be given the
> surface coordinate?   I seem to recall some sort of A-Frame looking diagram,
> though I'll have to go dig that up and see if there's a way to back-calculate.

I think there is not enough degrees of freedom in single patch
to do meaningful interpolation. But you might connect the reference
points in such a way that they are at corners of patches (these should
touch) and calculate inner control points for smooth transitions.

See e.g. http://www.joshuarenglish.com/cyclopedia/patches.html

Post a reply to this message

> The "prism" function seemed to me a good way of modelling the plate, due to the
> given conditions in my case (1D vibration). For the animation I chose the linear
> spline curve, since I managed to make it work in other animations I tried
> before.

All you transformation does is calculate a point B from point A. It
will not affect any geometry. For that you must actually use the value
B inside the geometry instead of the literal <-2,-3> (and of course
reverse the order, calculate B before the prism).

Note using splines for that only makes sense if you need to
interpolate between measurements. If you want to render one frame
per measurement just use data point n for frame n.

Also I think you may be misinterpreting the prism. It extrudes
a 1d spline in a second dimension. It will not work if what you
have are corners + edge midpoints of a flat rectangle like this

X------X------X
|      |      |
|      |      |
X------X------X

As most simple linear geometry you could model this
with 4 triangles (or preferable a mesh2 object), as I
think you already did earlier. For a curved representation
use 2 bicubic patches that share the "middle" control points
at their corners but that is a bit more involved:

http://www.joshuarenglish.com/cyclopedia/patches.html

Post a reply to this message

Christian Froeschlin <chr### [at] chrfrde> wrote:
> See e.g. http://www.joshuarenglish.com/cyclopedia/patches.html

I saw that, along with some of Mr. English's posts here on the forum, but I
haven't been able to do anything meaningful with it.

I might be able to get somewhere with:
https://web.archive.org/web/20131225210855/http://people.sc.fsu.edu/~jburkardt/html/bezier_interpolation.html

Got some good looking stuff coded up.   Just need to be able to have the data
points be coincident with the actual patch, and then I can put together
something that draws it all together.

Post a reply to this message

OK, so due to the extreme difficulty of employing bicubic_patch objects for
this,

{issues I've run into are
- the sometimes extreme disparity between control points and patch surface
coordinates,
- Somehow trace does not hit the edge of the patch when a ray is shot straight
down at the patch in the y direction from far above a control point
- inability to get accurate min and max extent
- extremely difficult to determine control points from data points on the curve
}

I've reimagined this whole thing, and of course the first stumbling block I got
to was:

If I read all the data in from the file, then render the first frame,
what will happen is that upon rendering the 2nd frame, the data gets read in
AGAIN, over and over and over.

Any ideas for fixes for this?
This looks like the ole' Persistence of Data across frames problem.
"POV needs POD!"

Post a reply to this message

Am 04.03.2016 um 18:21 schrieb Bald Eagle:

> If I read all the data in from the file, then render the first frame,
> what will happen is that upon rendering the 2nd frame, the data gets read in
> AGAIN, over and over and over.
> 
> Any ideas for fixes for this?
> This looks like the ole' Persistence of Data across frames problem.
> "POV needs POD!"

UberPOV has an experimental feature to carry over data from one frame to
the next (or, actually more to the point, from one render to the next,
regardless of whether those are two frames in an animation or entirely
independent renders), using "#persistent" instead of "#declare".

Post a reply to this message

On 3/4/2016 5:21 PM, Bald Eagle wrote:
> OK, so due to the extreme difficulty of employing bicubic_patch objects for
> this,
>
> {issues I've run into are
> - the sometimes extreme disparity between control points and patch surface
> coordinates,
> - Somehow trace does not hit the edge of the patch when a ray is shot straight
> down at the patch in the y direction from far above a control point
> - inability to get accurate min and max extent
> - extremely difficult to determine control points from data points on the curve
> }
>

One of the problems might be that we do not have calibration data for 
the sensors.
I rendered it as triangles in a mesh. The points are not planer. You 
could use a statistical formula to make them sit on a plane.



> I've reimagined this whole thing, and of course the first stumbling block I got
> to was:
>
> If I read all the data in from the file, then render the first frame,
> what will happen is that upon rendering the 2nd frame, the data gets read in
> AGAIN, over and over and over.
>
> Any ideas for fixes for this?
> This looks like the ole' Persistence of Data across frames problem.
> "POV needs POD!"
>
>

You step through the data using the clock or frame_number variables.

Talking about the data. I don't understand the time stamp. Five second 
intervals, that's quite slow, is it not? And what are the units of the 
sensors?

The long time interval makes me think that using splines is not the way 
to go.



-- 

Regards
     Stephen

Post a reply to this message

Stephen <mca### [at] aolcom> wrote:

> One of the problems might be that we do not have calibration data for
> the sensors.

I think it's just a matter of displaying the data that's available.

> I rendered it as triangles in a mesh. The points are not planer. You
> could use a statistical formula to make them sit on a plane.

I think it's all Y data - the X and z coordinates I derived from the diagram
that was provided.  I just connected the perimeter points to get a few
triangles, and it looks _OK_ - it would be better with smooth triangles, but I'm
unsure exactly how to calculate the corner normals.

> You step through the data using the clock or frame_number variables.

I used frame number - worked fine
http://news.povray.org/povray.binaries.animations/thread/%3Cweb.56d9fbdd155fef445e7df57c0%40news.povray.org%3E/

> Talking about the data. I don't understand the time stamp. Five second
> intervals, that's quite slow, is it not? And what are the units of the
> sensors?

Maybe it's a geologic plate ...  ;)
Could be they meant milliseconds or something.

> The long time interval makes me think that using splines is not the way
> to go.

Just normalize the time stamp to the interval 0-1 by dividing them all by 490,
although I don't think the spline is limited by the numbers.

Post a reply to this message

> Stephen <mca### [at] aolcom> wrote:
>
>> One of the problems might be that we do not have calibration data for
>> the sensors.
>
> I think it's just a matter of displaying the data that's available.
>
>> I rendered it as triangles in a mesh. The points are not planer. You
>> could use a statistical formula to make them sit on a plane.
>
> I think it's all Y data - the X and z coordinates I derived from the diagram
> that was provided.  I just connected the perimeter points to get a few
> triangles, and it looks _OK_ - it would be better with smooth triangles, but I'm
> unsure exactly how to calculate the corner normals.
>
>> You step through the data using the clock or frame_number variables.
>
> I used frame number - worked fine
>
http://news.povray.org/povray.binaries.animations/thread/%3Cweb.56d9fbdd155fef445e7df57c0%40news.povray.org%3E/
>
>> Talking about the data. I don't understand the time stamp. Five second
>> intervals, that's quite slow, is it not? And what are the units of the
>> sensors?

The units used can be totaly arbitrary. They can be in thousanth of an 
inch, micrometer, dust grains, mili-picas,... They only need to be self 
concistent. All we meed to have, is the possibility to assume that the 
data are linear.

>
> Maybe it's a geologic plate ...  ;)
> Could be they meant milliseconds or something.

That would be my guess also. Mili- or microsecond.

>
>> The long time interval makes me think that using splines is not the way
>> to go.
>
> Just normalize the time stamp to the interval 0-1 by dividing them all by 490,
> although I don't think the spline is limited by the numbers.
>
>
>

Splines are not limited to any range of values. Those can be negative or 
positive and range in the millions if wanted or needed.

In this case, you can multiply clock by 490, or whatever, to get the 
same result.

Post a reply to this message

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

> Is there a way to calculate where the control point needs to be given the
> surface coordinate?


Not sure if this gets us anywhere...

https://etd.ohiolink.edu/rws_etd/document/get/wright1190032099/inline
From Page 67:

% determine the size scalar fo
u2size = size(u2,1);
v2size = size(v2,1);
% generate the matrices U and V for the ps
U2 = [u2.^3 u2.^2 u2
V2 = [v2.^3 v2.^2 v2
% control point matrix indices
cmri = j1*4;
cmci = i1*4;
%%%%%%% psuedo-inverse transform
%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%
Pxc(cmri-3:cmri,cmci-3
((inv(B)*pinv(U))*Px*(pinv(V)'*inv(B)
Pyc(cmri-3:cmri,cmci-3:cmci) =
((inv(B)*pinv(U))*Py*(pinv(V)'*inv(B)'));
Pzc(cmri-3:cmr
((inv(B)*pinv(U))*Pz*(pinv(V)'*i
%%%%%

Post a reply to this message