Here is the POV-Ray 3.5-compatible version of POVGUI. There hasn't been
a lot of interest, so this may be the final release. The good news is
that everything works under 3.5 (beta 2 anyway). If you want to try it,
unzip the archive into a POVGUI folder and then move all the *.txt and
*.bmp files to a POVGUI folder under your POV 3.5 Insert Menu. You will
also have to run a file called "field.pov" to get the height field from
image to work.

Post a reply to this message

Attachments:
Download 'povgui15.zip' (131 KB)

Thanks!

- Nekar
"Dave Dunn" <poi### [at] aolcom> wrote in message
news:3BA### [at] aolcom...
> Here is the POV-Ray 3.5-compatible version of POVGUI. There hasn't been
> a lot of interest, so this may be the final release. The good news is
> that everything works under 3.5 (beta 2 anyway). If you want to try it,
> unzip the archive into a POVGUI folder and then move all the *.txt and
> *.bmp files to a POVGUI folder under your POV 3.5 Insert Menu. You will
> also have to run a file called "field.pov" to get the height field from
> image to work.
>

Post a reply to this message

Nekar Xenos wrote:

> Thanks!

You're welcome. Let me know what you think. I am always open to suggestions.

Post a reply to this message

When running GUIDEMO14.pov, I get an error from hfimage.inc:
Parse Error: Cannot open TGA image

I'm not quite sure what to do there.

Regards

- Nekar

Post a reply to this message

Nekar Xenos wrote:

> When running GUIDEMO14.pov, I get an error from hfimage.inc:
> Parse Error: Cannot open TGA image

There is a file called "field.pov" that should be in the main POVGUI
folder. You have to run this file so that it will render the image to be
used with the height field object. You will have to have your file
output set to TGA (+ft in povray.ini) and the location of your rendered
images will have to be in either the POVGUI folder or in your library
path. Sorry for the trouble here, but including the TGA image made the
archive too big, and having POV generate it seemed the easiest way. You
can also use your own image file, or just comment out or delete the
Height Field from Image macro call in your GUIDEMO file and it should
run just fine.

Post a reply to this message

Ok great, it works. For blobs though I think maybe using Runes blob macro might
be better - then you just show 1 sphere. What I'd like to see, though is the
ability to take any predefined object and use it something like this:

object {Object(object{MyObject,1,Silver,Polished_Chrome) translate y*3.5}

Maybe if you use trace this might be possible - but I've never used trace so I
can't be sure. I'm busy modelling a car with blobs and CSG and to convert it for
use with this macro would be quite tedious and quite confusing with the double
blobspheres.

Then again, it might have been easier if I had started with spline patches which
I still have to figure out.

I think PovGui is a good step for modelling in Pov and I appreciate everything
you've done here.

Thanks,

- Nekar

"Dave Dunn" <poi### [at] aolcom> wrote in message
news:3BB0D237.70B41872@aol.com...
> Nekar Xenos wrote:
>
> > When running GUIDEMO14.pov, I get an error from hfimage.inc:
> > Parse Error: Cannot open TGA image
>
> There is a file called "field.pov" that should be in the main POVGUI
> folder. You have to run this file so that it will render the image to be
> used with the height field object. You will have to have your file
> output set to TGA (+ft in povray.ini) and the location of your rendered
> images will have to be in either the POVGUI folder or in your library
> path. Sorry for the trouble here, but including the TGA image made the
> archive too big, and having POV generate it seemed the easiest way. You
> can also use your own image file, or just comment out or delete the
> Height Field from Image macro call in your GUIDEMO file and it should
> run just fine.
>
>

Post a reply to this message

Nekar Xenos wrote:

> Ok great, it works. For blobs though I think maybe using Runes blob macro might
> be better - then you just show 1 sphere. What I'd like to see, though is the
> ability to take any predefined object and use it...

First of all, glad you got it working. The blob implementation may not be perfect,
but I wasnted to show the relationship between the defined radius and the visible
portion of the component. It was not within my powers to show the surface of the
blob itself, so I settled for the dual-sphere solution to at least show where
blobbing would occur. In other words, if the yellow spheres touch, you will get some
effect, and if they don't, you won't. As for your second question, I am not sure
what you mean. It is already possible to use any of the wireframes (which are only
constructions using torus, cylinder and sphere_sweep after all) in an object
statement. As far as I know, the only POV primitives not covered are julia fractals
and isosurfaces, along with 2D objects such as triangle and polygon, which I am
planning to add. If I read your request correctly, you are looking for a single
macro that will read any POV object and, using trace, convert it to a wireframe. It
is an interesting idea, but I am not sure if it is within my feeble powers.

Post a reply to this message

"Dave Dunn" <poi### [at] aolcom> wrote in message
news:3BB### [at] aolcom...
> Nekar Xenos wrote:
>
> > Ok great, it works. For blobs though I think maybe using Runes blob macro
might
> > be better - then you just show 1 sphere. What I'd like to see, though is the
> > ability to take any predefined object and use it...
>
> First of all, glad you got it working. The blob implementation may not be
perfect,
> but I wasnted to show the relationship between the defined radius and the
visible
> portion of the component. It was not within my powers to show the surface of
the
> blob itself, so I settled for the dual-sphere solution to at least show where
> blobbing would occur. In other words, if the yellow spheres touch, you will
get some
> effect, and if they don't, you won't.

Thanks for clearing that one for me, I didn't know that one was the visible
component.

>If I read your request correctly,
Sort-of..
>you are looking for a single
> macro that will read any POV object and, using trace, convert it to a
wireframe. It
> is an interesting idea, but I am not sure if it is within my feeble powers.

MyObject is supposed to be a CSG of primitives, blobs and other stuff. Yes I
think it would be quite difficult.

Regards,

- Nekar

Post a reply to this message

Nekar Xenos wrote:

> >you are looking for a single
> > macro that will read any POV object and, using trace, convert it to a
> wireframe. It
> > is an interesting idea, but I am not sure if it is within my feeble powers.

> >>MyObject is supposed to be a CSG of primitives, blobs and other stuff. Yes I
> >>think it would be quite difficult.

This is not far from the idea that we were kicking around for julia fractals and
isosurfaces one night. The idea is to create a "box" of six grids, containing sphere
sweeps, exactly the way height_fields are implemented in POVGUI, but completely
surrounding the object. Using trace, the points would be translated to the point
where they hit the object. Points that did not hit the object would be deleted. I
never tried this, so I don't know if it would work or not, but it is a way to derive
wireframes from irregular objects.

Post a reply to this message