news:nuqu9u4rd9arf7qemfed5nkurhoabb7ogl@4ax.com...
> On Mon, 25 Mar 2002 13:27:48 -0500, "Corey Woodworth" <cdw### [at] mpinetnet>
> wrote:
> > I know I can save it but I'm still testing different values.
>
> Values of what ? Resoultion of mesh ? Consider that image_map base on
image so
> it has some highest limit of resolution.

Yes, but my bump map is *very* large. Much larger than I could make the
resolution
of the mesh without running out of memory i think.

> > Also the isosurface would be alot  more accurate
>
> and much slower, and so much memory optimized when copied, and gradient
> sensitive (note I'm advocate of functions/isosurfaces)

Slower to render? Its definetly faster to parse!

> > since it is a REAL sphere and it uses all the pixels
>
> AFAIK shape showed in your source at begining of this thread isn't
spherical
> heigh field, only container is sphere

Yes but its not limited to the resolution of  the mesh. And even if it is
limited to
the resoultion of the height field, that resolution is a lot higher than I
can
(practically) make the mesh. Still I know very little about this and could
be very
wrong. Please correct me if I am :)

Corey

> ABX

Post a reply to this message

On Mon, 25 Mar 2002 14:11:39 -0500, "Corey Woodworth" <cdw### [at] mpinetnet>
wrote:
> Yes, but my bump map is *very* large. Much larger than I could make the resolution
> of the mesh without running out of memory i think.

Do you really think you see all details on 800x600 render ?

> Slower to render? Its definetly faster to parse!

but when you adjust values and start adjusting of enviroment, in case on mesh
you can use include file with fast parsing, in case of isosurface you can't
use include file with fast rendering

> Yes but its not limited to the resolution of  the mesh. And even if it is
> limited to the resoultion of the height field, that resolution is a lot higher than
I
> can (practically) make the mesh.

The question is, do you really need it ? Do you really make posters with
dimensions 8000x6000

> Still I know very little about this and could be very
> wrong. Please correct me if I am :)

You are right abot accuracy. But You are using wrong method for spherical
mapping for so small image dimensions as presented in p.b.i.

ABX

Post a reply to this message

news:sgtu9u87d7i9966rv1gbas3sra9nmisohe@4ax.com...
> On Mon, 25 Mar 2002 14:11:39 -0500, "Corey Woodworth" <cdw### [at] mpinetnet>
> wrote:
> > Yes, but my bump map is *very* large. Much larger than I could make the
resolution
> > of the mesh without running out of memory i think.
>
> Do you really think you see all details on 800x600 render ?

I plan on scaling it up quite a bit when I'm done and then cropping it back
down. to just the important parts.

> > Slower to render? Its definetly faster to parse!
>
> but when you adjust values and start adjusting of enviroment, in case on
mesh
> you can use include file with fast parsing, in case of isosurface you
can't
> use include file with fast rendering


> > Yes but its not limited to the resolution of  the mesh. And even if it
is
> > limited to the resoultion of the height field, that resolution is a lot
higher than I
> > can (practically) make the mesh.
>
> The question is, do you really need it ? Do you really make posters with
> dimensions 8000x6000

Well I'm not using a CRAZY size 10k bump map. I'm using a 2k one. I know
I won't see all the detatails of it, but with a mesh I only see very few
details.
My mesh keeps looking chunky. :) I up the resolution and it looks less
chunky
but still far from what I want it to be.

> > Still I know very little about this and could be very
> > wrong. Please correct me if I am :)
>
> You are right abot accuracy. But You are using wrong method for spherical
> mapping for so small image dimensions as presented in p.b.i.

So you  suggest I just keep upping the resolution of the mesh untill it
doesn't
look like a mesh at my target resoultion?

Corey

> ABX

Post a reply to this message

May I interfere?  :o)  Well, I don't know how slow the isosurface solution
is, but I would go for a mesh. If you hesitate to do this because you
consider the memory it needs, please remember that even with an isosurface,
your input is an image_map. This also needs a lot of memory. If you save a
mesh, you nolonger need the bump map.

As for mesh resolution, it normally doesn't need to be very high. Meshes can
be smoothed (faked). I'm not sure an isosurface will look better in this
case.

Btw, don't worry about asking questions. :o)

Regards,
Hugo

Post a reply to this message

"Hugo" <hua### [at] post3teledk> wrote in message
news:3c9fac93$1@news.povray.org...
> May I interfere?  :o)  Well, I don't know how slow the isosurface solution
> is, but I would go for a mesh. If you hesitate to do this because you
> consider the memory it needs, please remember that even with an
isosurface,
> your input is an image_map. This also needs a lot of memory. If you save a
> mesh, you nolonger need the bump map.
>
> As for mesh resolution, it normally doesn't need to be very high. Meshes
can
> be smoothed (faked). I'm not sure an isosurface will look better in this
> case.
>
> Btw, don't worry about asking questions. :o)

Ok then :) Here is another question! I parsed a mesh and saved it to a file
named
earthMesh.pov. I added #declare earthMesh = to the beginning of the file and
then included it in my scene. I also commented out the macro that created
the
mesh so I didn't have to make it again. Why does it still take SOO LONG to
parse?! It takes just about as long as it originally did. Are meshes
supposed to
be imported differently than this? What am I doing wrong?

Thanks,
Corey

> Regards,
> Hugo
>
>

Post a reply to this message

> I parsed a mesh and saved it to a file ....
> Why does it still take SOO LONG to parse?!
> It takes just about as long as it originally did.

Sounds strange. Reading a mesh2 file is the fastest way to go. If your
computer is modern, it shouldn't take more than a second unless the mesh is
huge (tens of megabytes). Coming to think of it .... HF_Sphere outputs an
old-style mesh, not mesh2 as far as I know.. This must be the problem.. Do
you know how to convert it to mesh2  ??  ;o)  Sorry for these troubles, I
think the final HF_Sphere include file ought to use mesh2.

Does someone have a mesh2 version?  There's a good explanation of mesh2 in
the docs, but it might still take a little effort.


Regards,
Hugo

Post a reply to this message

"Hugo" <hua### [at] post3teledk> wrote in message
news:3c9fc075@news.povray.org...
> > I parsed a mesh and saved it to a file ....
> > Why does it still take SOO LONG to parse?!
> > It takes just about as long as it originally did.
>
> Sounds strange. Reading a mesh2 file is the fastest way to go. If your
> computer is modern, it shouldn't take more than a second unless the mesh
is
> huge (tens of megabytes). Coming to think of it .... HF_Sphere outputs an
> old-style mesh, not mesh2 as far as I know.. This must be the problem.. Do
> you know how to convert it to mesh2  ??  ;o)  Sorry for these troubles, I
> think the final HF_Sphere include file ought to use mesh2.

Is it possible to convert it to mesh2? I've never used mesh2 before because
I
read it was mostly for importing files from other formats.

Thanks,
Corey

> Does someone have a mesh2 version?  There's a good explanation of mesh2 in
> the docs, but it might still take a little effort.
>
>
> Regards,
> Hugo
>
>

Post a reply to this message

> Is it possible to convert it to mesh2? I've never used mesh2
> before because I read it was mostly for importing files from
> other formats.

That's true because imported meshes are usually big and mesh2 is better to
handle this. It's the same data but written in a more efficient way. The
result is higher speed and less memory usage. At the same time it's harder
to read for the human eye, so sometimes old-style mesh is still preferred.

But readability is hardly necessary unless you want to manually edit the
files.. If I get the time, I'll write a mesh2 version for you.. I just
checked the HF_Sphere macros and they are easy to convert.. Let me know if
you think help is urgent.

Regards,
Hugo

Post a reply to this message

W wrote:
>On Mon, 25 Mar 2002 06:55:32 -0500, "Corey Woodworth" <cdw### [at] mpinetnet>
>wrote:
>> I don't really understand how far
>> reaching the function goes but I think I've figured out that it doesn't
>> scale with the container.
>
>One advice. Read _carefully_ documentation (all chapters about isosurfaces),
>then read http://www.econym.demon.co.uk/isotut/, and then study examples in
>/scenes/ folder available in standard distribution. It helps a lot.
>
>ABX
>

The http://www.econym.demon.co.uk/isotut/ link here isn't working anymore.

I use to do the image map stuff with megaPOV, but that code doesn't work
with POV 3.5, at least the version I downloaded a few months ago (I
think?).

This is how I did it in megaPOV -- but it doesn't work with POV 3.5:

// declare function with map_type 1 (spherical) mapping
#declare imageMap=function
{ pigment
 { image_map
   { png "C:\images\povsurf\earthbump.png"
     map_type 1 interpolate 2
   }
  scale 0.32
  //rotate x*45
  //rotate y*85
  //translate y*0.3
}}

// isosurface
#declare rs=0.015; // try rs values <1; higher it is, higher is text

#declare PlanetX = isosurface
{   function{x*x+y*y+z*z + rs - imageMap(x,y,z)*rs}
    contained_by{sphere{0,1}}
    eval
     max_gradient 150 // adjust to picture otherwise strange things happen
    threshold 1
    texture
    { pigment
      { image_map
        { png "C:\images\povsurf\earthcolor.png"
          map_type 1 interpolate 2
        }
  scale 0.32
  //rotate x*45
  //rotate y*85
  //translate y*0.3
      }
    }
}

I've got a lot of megaPOV code like that, is there an easy way to translate
it into something that works in POV 3.5?

normdoering

Post a reply to this message

Two things is all, I think. eval is now evaluate and you'll need to use the
dot vector of your imageMap function. Example:

imageMap(x,y,z).gray*rs

Look up evaluate in the help, it takes three parameters. Checking the Scene
Help myself... maybe a read at section 3.6.3.6 noise and pigment functions
will also help.
Another keyword I see you hadn't used is 'accuracy' although I think maybe
that was already in MegaPOV.

P.S. http://www.econym.demon.co.uk/isotut/  is working okay for me.
--
Farewell,
Bob

"normdoering" <nor### [at] yahoocom> wrote in message
news:web.3da7c4958dccf4e514e415dd0@news.povray.org...
>
> I use to do the image map stuff with megaPOV, but that code doesn't work
> with POV 3.5, at least the version I downloaded a few months ago (I
> think?).

Post a reply to this message