 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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 ;-)
--
François DISPOT -- http://www.wozzeck.net
__ __ __ __ _
| | / \ / / |_ / |/
\/\/ \__/ /_ /_ |__ \_ |\
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
That's because a lot of people in the 3d biz must have more dollars than
sense. Povray offers the most bang for your buck, after all, it's free.
3.5 made it better, too. Though it has been driving me nuts trying to find
any bugs in 3.5 beta. Zero so far.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Steven Jones wrote:
>
> Though it has been driving me nuts trying to find any bugs in 3.5 beta.
> Zero so far.
You don't know how happy that makes me :)
--
Ken Tyler - POV-Ray Technical Assistance Group
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I didn't know that you were on the POV-team Ken.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Steven Jones wrote:
>
> I didn't know that you were on the POV-team Ken.
I'm not. But I, and a few other hand choosen people, did extensive
testing before public release. It appears that we did well evidenced
by the fact you are having problems finding bugs.
--
Ken Tyler - POV-Ray Technical Assistance Group
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I spoke to soon Ken. I think I may have found a bug. I'm trying to read in
vector values with a #read statement but povray wont read more than two
values down the list. Did you experiment with the file input and output,
Ken?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Steven Jones wrote:
>
> I spoke to soon Ken. I think I may have found a bug. I'm trying to read in
> vector values with a #read statement but povray wont read more than two
> values down the list. Did you experiment with the file input and output,
> Ken?
Not really, but if you really think you have found a bug then post a
suitable bug report in the beta test group so it can be verified and
fixed if necessary.
--
Ken Tyler - POV-Ray Techncial Assistance Group
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Cool, someone else who uses DB. I haven't tried writing POV utilities with it
yet, but the "matrix" 3d grid looks like it might be useful for previewing
HF's...
From the Grey Knight
//@---signature---
// Grey Knight's site of the week: http://heday.freeservers.com/
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?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
