 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff <chr### [at] mac com> wrote:
> There's room for improvement, but what's there is a good
> start, and is very useful as is.
Yes, but what I am saying is that the improvements should be made *now*,
not some time in the future, because improvements will most probably need
a syntax change which will break backwards compatibility.
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mark Wagner <mar### [at] gtenet> wrote:
>> By the way, any chance of making the time values optional?
> No. The time for feature requests is over, particularly for difficult
> feature requests such as this.
Adding support for catmull-rom splines was a feature request, which is
being considered.
I was just suggesting that as someone is going to make changes to the
spline code anyways, if he could go a bit further.
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c77e8b4@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> Yes, but what I am saying is that the improvements should be made *now*,
> not some time in the future, because improvements will most probably need
> a syntax change which will break backwards compatibility.
I don't think so...it would be fairly easy to support the current syntax
along with a new one. Brackets (either {} or []) could be added now to
prevent having to do this though...I'd use [] for consistency with
*_maps.
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" wrote:
> You didn't get my point: I was complaining about
> *forcing* each time value to be specifically written.
I think you didn't get my point: You are not forced to specifically write
each time value when you can have a macro do it for you.
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated Feb 16)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune <run### [at] mobilixnetdk> wrote:
> I think you didn't get my point: You are not forced to specifically write
> each time value when you can have a macro do it for you.
I think it would be quite difficult and a bit cumbersome to make a
macro which supports optional time values (ie. any point can have a time
value or not).
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" wrote:
> I think it would be quite difficult and a bit
> cumbersome to make a macro which supports optional
> time values (ie. any point can have a time value or not).
Then we must make such a macro and include it in the standard distribution
so the user don't have to fiddle with it. I volunteer to make it.
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated Feb 16)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote in message <3c77e96e@news.povray.org>...
>Mark Wagner <mar### [at] gtenet> wrote:
>>> By the way, any chance of making the time values optional?
>
>> No. The time for feature requests is over, particularly for difficult
>> feature requests such as this.
>
> Adding support for catmull-rom splines was a feature request, which is
>being considered.
> I was just suggesting that as someone is going to make changes to the
>spline code anyways, if he could go a bit further.
When I re-wrote the MegaPOV spline code, I deliberately made it easy to add
more spline types. Consequently, doing so will probably take about two to
three hours to implement and debug.
The work needed to add catmull-rom splines:
Add a catmull_rom_interpolate() function to splines.cpp
Add one "case" statement to the switch statement in Get_Spline_Val() in
splines.cpp
Add a #define for catmull-rom splines to the splines.h file
Add a CASE(CATMULL_ROM_SPLINE_TOKEN) to Parse_Spline() in express.cpp
Add a CASE(CATMULL_ROM_SPLINE_TOKEN) to Parse_Num_Factor() in express.cpp
Possibly add the definition of "catmull_rom_spline" and
"natural_cubic_spline" to parse.h and tokenize.cpp
The work needed to add optional time values to splines:
A partial re-write of the Parse_Spline() function
A re-write of Insert_Spline_Entry()
Adding a "Post_Spline()" function to compute the time values that were not
given once parsing the spline is complete.
Far more time spent debugging this feature than I will have available in the
next few months
--
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" wrote:
> Eh, you didn't understand what I meant: I meant that
> a macro would be cumbersome because of limited syntax
> capabilities.
The suggested syntax I've described in the other thread is not *that*
cumbersome. You have to write a few more characters per point, yes, but
complaining about that is most of all nit-picking IMO.
> Using an "illegal" value to mean optionality is not
> very handy either (in a worst case scenario you would
> have to write tens or even hundreds of these "optional"
> time values even though you are using just two or three
> regular time values).
Copy and paste.
> The idea was that you don't have to write any time
> value for those points which you want to be calculated
> automatically.
I must admit that it would make it better for the purposes of obfuscated
signatures. Pity eh?
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated Feb 16)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Mark Wagner" wrote:
> The work needed to add catmull-rom splines:
> Possibly add the definition of "catmull_rom_spline" and
> "natural_cubic_spline" to parse.h and tokenize.cpp
You might want to check with Thorsten, but I think it was more or less
decided to call the catmull-rom spline for "cubic_spline" and the natural
cubic spline for "natural_spline".
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated Feb 16)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c788234@news.povray.org> , "Mark Wagner" <mar### [at] gtenet>
wrote:
> The work needed to add catmull-rom splines:
>
> Add a catmull_rom_interpolate() function to splines.cpp
> Add one "case" statement to the switch statement in Get_Spline_Val() in
> splines.cpp
If you just do this part, I can easily do the rest while integrating the code.
You can test it by temporarily using the cubic_spline option or something -
integrating parser code based on pre-3.5 code would take more time than
writing it from scratch...
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
