 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm creating a utility in DarkBASIC which will take a height field and a
text file containing 2d coordinates, and create a list of 3d coordinates,
i.e. the original values are treated as X and Z, and the height of the HF at
that point is treated as Y. This would create a text file usable in Chris
Colefax's spline macro. Does anyone want this utility when I'm finished?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Steven Jones wrote:
> I'm creating a utility in DarkBASIC which will take a height field and a
> text file containing 2d coordinates, and create a list of 3d coordinates,
> i.e. the original values are treated as X and Z, and the height of the HF at
> that point is treated as Y. This would create a text file usable in Chris
> Colefax's spline macro. Does anyone want this utility when I'm finished?
I'm not sure I follow here. Does the utility creat a list of vectors that
correspond to pionts on the HF? The reason I am asking is that if this is so, I
might like to look at it to see if it can be used to generate wireframe height
fields to be used in POVGUI.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
It's not for that. You have to create a list of 2d points that lie on a
path. My utility will put the Y values in, so that spline.mcr can generate
a spline path from those points.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Steven Jones wrote:
> It's not for that. You have to create a list of 2d points that lie on a
> path. My utility will put the Y values in, so that spline.mcr can generate
> a spline path from those points.
Actually, sounds like it may be just the thing. What I am thinking is that the
heightfiled wireframe will be a grid of splines (or MegaPOV sphere_sweeps),
say, 10 across in the X and Z directions. If your utility could supply the Y
values, then the crossed splines would form a wireframe representation of a
coarse section of the heightfield. Linear splines would give a more jagged
effect, and a cubic or catmull spline would represent the smooth keyword. I
guess something similar could be done with trace or height_field_at, but I
wanted to see what your util could do. Thanks anyway for responding, but I
think I have solved my own problem : )
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
You should get DB anyway at www.darkbasic.com because it loads many graphics
formats natively, and therefore makes the ideal language for writing povray
utilities.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wasn't it Steven Jones who wrote:
>I'm creating a utility in DarkBASIC which will take a height field and a
>text file containing 2d coordinates, and create a list of 3d coordinates,
>i.e. the original values are treated as X and Z, and the height of the HF at
>that point is treated as Y. This would create a text file usable in Chris
>Colefax's spline macro. Does anyone want this utility when I'm finished?
Would it perhaps be easier to write it in MegaPOV, using the trace
facility?
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Williams wrote:
> Would it perhaps be easier to write it in MegaPOV, using the trace
> facility?
For my own purposes, generating a wireframe heightfield, I ended up using
hf_height_at and sphere_sweeps. I know, I know, deprecated in 3.5 - use trace.
For now, I know how to use hf_height_at, but get confused by the docs for trace.
Guess I will have to learn it if I migrate POVGUI to 3.5.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Steven Jones wrote:
> You should get DB anyway at www.darkbasic.com because it loads many
> graphics formats natively, and therefore makes the ideal language for
> writing povray utilities.
...but is Windows-only.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Most people use Windows these days.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Steven Jones wrote:
>
> Most people use Windows these days.
ImageMagick is free (as a beer), features a lot of useful operations and
conversions between most graphics formats. It can be easily used inside
scripts using pipes, so it makes the "ideal language for writing povray
utilities" (tm).
Same for gimp, netpbm, gifsicle, <insert your favourite scriptable free
stuff here>...
An "ideal" thing depends on its own features, but also on your taste,
uses, os and many other factors. You see, nobody in the 3D business use
our ideal POV-Ray ;-)
--
__ __ __ __ _
| | / \ / / |_ / |/
\/\/ \__/ /_ /_ |__ \_ |\
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
