 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 22 Oct 2002 09:11:13 -0400, "Greg M. Johnson" <gregj:-)565### [at] aol com>
wrote:
> I don't understand your spline/array fix.
You mean array-like access to splines ?
Have you checked original page (http://abx.art.pl/pov/patches/arspline.php)?
It basically is possibility of _reading_ number of control points and theirs
values. Imagine you have spline already created as
#declare S=spline{0,x 1,y 2,z};
which means S is linear spline with segments from <1,0,0>to<0,1,0>to<0,0,1>
With my patch you can acces those parameters, so:
#delcare N=dimension_size(S); // returns 3
#declare T1=S[0][0]; // returns 0
#declare V1=S[0][1]; // returns <1,0,0>
#declare T2=S[1][0]; // returns 1
#declare V2=S[1][1]; // returns <0,1,0>
#declare T3=S[2][0]; // returns 2
#declare V3=S[2][1]; // returns <0,0,1>
Advantage of this is that you can now write macros to operate on splines
without storing values in additional arrays.
> My interest is in splines for keyframing the animation variables of a
> blob-based character.
> If you've seen any of the professional packages, there are dozens of
> variables for limb position/rotation, etc., and the transition is done in
> "spline-like" graphs. Obviously, every limb control variable can be set
> independently, with different ones having different control points at
> different frames.
> Managing all of this with three dozen cubic_splines is doable but somewhat
> of a headache. Is your patch offering any help here?
Hard to say. I don't know internals of your human animation.
But I understand feature you are looking for. I have in mind some system for
helping in controlling such animations. But it is in my TODO since months and
when will be incorporated.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Greg M. Johnson wrote:
> My interest is in splines for keyframing the animation
> variables of a blob-based character.
>
> If you've seen any of the professional packages, there
> are dozens of variables for limb position/rotation,
> etc., and the transition is done in "spline-like"
> graphs. Obviously, every limb control variable can
> be set independently, with different ones having
> different control points at different frames.
>
> Managing all of this with three dozen cubic_splines is
> doable but somewhat of a headache. Is your patch
> offering any help here?
I think a system like that is too complicated and specialized for an
internal feature in POV-Ray, it would be difficult to make a system that
fits all cases.
I have tried to implement similar things in POV-script. Some of it is
used in my Lip Synch System, which can be found on my web site.
In the lip synch system it only applies to the muscles in the mouth, but
the concept is the same for anything moving that is controlled with
splines and where the concept of key frames make sense.
Rune
--
3D images and anims, include files, tutorials and more:
rune|vision: http://runevision.com (updated Oct 19)
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Rune" <run### [at] mobilixnetdk> wrote in message
news:3db558d8@news.povray.org...
>
> I think a system like that is too complicated and specialized for an
> internal feature in POV-Ray, it would be difficult to make a system
> that fits all cases.
>
Perhaps especially for a text-based SDL. I suppose one could write a program
which has a GUI where you click & drag your spline points and their control
points.
I envision a system (INC or patch) where you have a table, with clock values
0 to 1 on one axis and on the other, the x,y,z of say two dozen
vectors(representing translations & rotations). Then you just type in the
values you're interested in, and somebody turns all of them into a smoothly
flowing function of the clock over the places where your table is blank.
Oh, perhaps I could do this myself with Lotus 1-2-3 --- it's the
"programming language" I'm most fluent at-- but it wouldn't be very useful
to others, if I ever wanted to share....
ABX:
Could you humour me with the results when one has a spline of:
>> #declare S=spline{0.110 , x 0.151,y , 0.92 , z};
Q: Do you mind being called ABX?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 23 Oct 2002 08:47:54 -0400, "Greg M. Johnson" <gregj:-)565### [at] aolcom>
wrote:
> Perhaps especially for a text-based SDL. I suppose one could write a program
> which has a GUI where you click & drag your spline points and their control
> points.
Ingo recently made such addition for GIMP. Look for his post on 06.10.2002 in
povray.general.
> I envision a system (INC or patch) where you have a table, with clock values
> 0 to 1 on one axis and on the other, the x,y,z of say two dozen
> vectors(representing translations & rotations). Then you just type in the
> values you're interested in, and somebody turns all of them into a smoothly
> flowing function of the clock over the places where your table is blank.
I probably not understand You becouse from what I read in your wish is
basically what splines exactly do. You write clock values and vectors and then
spline represents smoothly flowing function of the clock.
> ABX:
> Could you humour me with the results when one has a spline of:
> > > #declare S=spline{0.110 , x 0.151,y , 0.92 , z};
Sorry, I can't recognize meaning and intentions of above with my poor English
:-( and I don't understand why you have changed content in quoted text.
You don't know what above is ? It is linear spline with two segments.
> Q: Do you mind being called ABX?
Since I use it for domains, emails and for posting ...
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"ABX" <abx### [at] abxartpl> wrote in message
news:ik6druo1klvj3cqfsnns7dvugik9hv4sti@4ax.com...
> I probably not understand You becouse from what I read in your wish is
> basically what splines exactly do. You write clock values and vectors and
> then spline represents smoothly flowing function of the clock.
>
But if you have about two dozen splines, they're sprawled all across the
several "pages" of text, with lots of re-typing and re-pasting of similar
information.
I made up a sample Lotus 1-2-3 file with the type of spreadsheet I'd like to
work with, and here is the .CSV formatted export of that file:
//---start pasted file
,"hand.x","hand.y","hand.z","arm.x","arm.y","arm.z"
0,1,0,0.25,0.75,0.5,0
0.1,,,,,,
0.2,,,,0.75,0.75,0.1
0.3,,,,,,
0.4,,,,,,
0.5,1,0.5,1,0.75,1,0
0.6,,,,,,
0.7,,,,,,
0.8,,,,,,
0.9,,,,,,
1,1,0,0.25,0.75,0.5,0
//---end pasted file
For example, I may want the hand file to have key frames at 0.00, 0.50, and
1.00, with the arms at 0.00, 0.25, 0.50, and 1.00. Of course instead of two
variables, it'd easily be two dozen.
So I suppose for my own benefit I could write my own pov file to read this
(yikes, what a task!), but "the system" might not be very useful to others
who don't have 1-2-3 or don't want to mess with a spreadsheet. And I'd have
to touch my mouse more often to do extra saves & switches between programs,
but I suppose I could survie this...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 23 Oct 2002 12:39:43 -0400, "Greg M. Johnson" <gregj:-)565### [at] aolcom>
wrote:
> //---start pasted file
> ,"hand.x","hand.y","hand.z","arm.x","arm.y","arm.z"
> 0,1,0,0.25,0.75,0.5,0
> 0.1,,,,,,
> 0.2,,,,0.75,0.75,0.1
> 0.5,1,0.5,1,0.75,1,0
> 0.6,,,,,,
> 1,1,0,0.25,0.75,0.5,0
> //---end pasted file
I think you can write a macro for this to operate on arrays. You can test
whether specified cell in array is defined or not and then create dedicated
spline.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ABX wrote:
>
> Hi!
>
> New version of PoPOV is available at http://abx.art.pl/pov/popov/
>
> This release contains next set of patches I gathered in repository at
> http://abx.art.pl/pov/patches/ and introduce windows port. Sorry for lack of
> sources and documentation. I have to make some work on them. I hope it can be
> already usefull for community.
I tried it and it worked, but the speed difference is IMO too significant
for it to be used for everyday POV-Ray work. You should really release
the source code, i understand it's easier to make a compiled version than
to create a clean version of the source but i somehow find it a bad habit
to offer binaries a lot earlier than the source.
Concerning the triangle function - i think you should include an updated
version of 'functions.inc'. And i would consider doing the docs soon,
otherwise - believe me - it will be an awful lot of work if done well.
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 21 Oct 2002 21:30:14 +0200, Christoph Hormann <chr### [at] gmxde>
wrote:
> I tried it and it worked, but the speed difference is IMO too significant
> for it to be used for everyday POV-Ray work.
http://news.povray.org/pce7rugbsntvn8aboobq3ea069erg1q7k3%404ax.com
> You should really release
> the source code,
surprise at www.abx.art.pl/pov/popov :-)
but sources were available via links in original places
> i understand it's easier to make a compiled version than
> to create a clean version of the source but i somehow find it a bad habit
> to offer binaries a lot earlier than the source.
wsn't 3.5 introduced this way ? :-)
> Concerning the triangle function - i think you should include an updated
> version of 'functions.inc'.
Yes, I thought about it but somehow forgot. I hope fixed now. This issue
should be introduced as important part of patching functions.
> And i would consider doing the docs soon,
Yes, that's my next step.
> otherwise - believe me - it will be an awful lot of work if done well.
I believe You :-)
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ABX wrote:
>
> > I tried it and it worked, but the speed difference is IMO too significant
> > for it to be used for everyday POV-Ray work.
>
> http://news.povray.org/pce7rugbsntvn8aboobq3ea069erg1q7k3%404ax.com
I know you already mentioned that but this does not change anything about
what i said. I'm quite confident there will be someone willing to make
regular compiles with the intel compiler once there is a standardized well
documented patch collection.
> > You should really release
> > the source code,
>
> surprise at www.abx.art.pl/pov/popov :-)
Thanks. I had a first quick look:
- renaming all file names to upper case is an *extremely* bad idea.
- all changes seem well marked by #ifdef's but most of the modifications
(counting number of blocks, not amount of code) are those preventing the
warnings. I don't want to warm up this discussion again, but for the sake
of easy adaptation to new official releases (3.50c just came out) i think
this should be dropped in a general patch collection.
- the 'patches.h' file seems a good idea, i just would wish a short
description of the individual patches at each #define (i know it's in your
repository but that's not the same as if it comes with the package).
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 22 Oct 2002 15:50:34 +0200, Christoph Hormann <chr### [at] gmxde>
wrote:
> I'm quite confident there will be someone willing to make
> regular compiles with the intel compiler
I hope too.
> > > You should really release
> > > the source code,
> >
> > surprise at www.abx.art.pl/pov/popov :-)
>
> Thanks. I had a first quick look:
>
> - renaming all file names to upper case is an *extremely* bad idea.
I not guilty. I did not changed it. It must be NT or Windows Commander.
I will automatize packing for future releases with some proces to control file
names
> - all changes seem well marked by #ifdef's but most of the modifications
> (counting number of blocks, not amount of code) are those preventing the
> warnings. I don't want to warm up this discussion again, but for the sake
> of easy adaptation to new official releases (3.50c just came out) i think
> this should be dropped in a general patch collection.
Two solutions. First, I can remove my modifications and turn off warnings -
but then incorporating new patches can have some warnings I could not catch.
Second, I can remove old behaviours and stay with new syntax when it not
changes features. Personally I prefer second solution but temporary I stayed
with #ifdefs to highlight all places modified by me.
> - the 'patches.h' file seems a good idea, i just would wish a short
> description of the individual patches at each #define (i know it's in your
> repository but that's not the same as if it comes with the package).
I though about it and probably incorporate this
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
