 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I know it's possible to apply bitmap files to an object to create a custom
texture. My question is "how?" What should the code syntax look like?
What's the best resolution to use? and how should I go about constructing
the image itself outside of POV ray so that when it's imported in, it does
what it is supposed to do?
Thanks!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
web.4472029110e847ff3a4439080@news.povray.org...
> I know it's possible to apply bitmap files to an object to create a custom
> texture. My question is "how?" What should the code syntax look like?
http://www.povray.org/documentation/view/3.6.1/337/
> What's the best resolution to use?
The resolution at which you cant see the pixels of your bitmap
>and how should I go about constructing
> the image itself outside of POV ray so that when it's imported in, it does
> what it is supposed to do?
It depends on what you want it to do :-)
Marc
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"POV Shadow" <PCH### [at] gmail com> wrote:
> I know it's possible to apply bitmap files to an object to create a custom
> texture. My question is "how?" What should the code syntax look like?
> What's the best resolution to use? and how should I go about constructing
> the image itself outside of POV ray so that when it's imported in, it does
> what it is supposed to do?
>
> Thanks!
Using an image_map is the trick. The first thing to do is to make your image
in some graphics program like Photoshop. A square image is best (because, by
default, POV will apply the image to a flat "square area" of 1X1 units in
the X-Y plane, beginning at the origin ... that is, from <0,0,0> to
<1,1,1>.) This is called "planar" mapping, and is projected from the
"front" by default (which can be changed to any orientation.) There are
other types of mapping, but planar is the easiest to understand. The
image_map can of course be scaled up later in POV, to cover a larger area.
The resolution of your image can be anything you like--the bigger the image
the better, so you don't see any individual pixels when itis applied to your
object. (Practically speaking, there's no real reason to make your image any
larger than maybe twice the screen-size of your final rendered POV object.)
Finally, save the image file in a format that POV will recognize for
image_maps (take a look at the documentation.) I'll use the .jpeg format
for the following example.
Then, in POV, having made a 1X1X1-unit box object at the origin (just a
simple object as an example), texture it like this:
texture{
pigment{
image_map { jpeg "my_image.jpeg" map_type 0 once interpolate 2}
scale <...whatever...> // to optionally scale the IMAGE, not the box
translate <...whatever...> // optional as well
}
finish{
ambient 1
diffuse 0
}
}
The MAP_TYPE 0, ONCE and INTERPOLATE 2 keywords are all optional too. What
you should see is your image projected onto the front (and back) faces of
your cube.
Once you get a feel for how this works, then the fun can begin--spherical
and cylindrical mapping using a different MAP_TYPE; using "invisible" alpha
channel areas in the image_map; applying multiple images to different parts
of your object from different directions; using the same image to create
surface normals; etc.
Ken W.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
POV Shadow nous apporta ses lumieres en ce 22/05/2006 14:27:
> I know it's possible to apply bitmap files to an object to create a custom
> texture. My question is "how?" What should the code syntax look like?
> What's the best resolution to use? and how should I go about constructing
> the image itself outside of POV ray so that when it's imported in, it does
> what it is supposed to do?
>
> Thanks!
>
>
To add to what others have said. It's usualy best to use a compressed format instead
of a bitmap.
JPG and PNG are good choices. It can realy shorten the parsing of the file. It can
also prevent the
use of the swap file by reducing the memory useage, and that can have a dramatic
effect to the
parcing and render time.
--
Alain
-------------------------------------------------
A true friend is someone who reaches for your hand
and touches your heart.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain <ele### [at] netscapenet> wrote:
> To add to what others have said. It's usualy best to use a compressed format instead
of a bitmap.
> JPG and PNG are good choices. It can realy shorten the parsing of the file. It can
also prevent the
> use of the swap file by reducing the memory useage, and that can have a dramatic
effect to the
> parcing and render time.
Please don't get offended if I'm a bit blunt, but please, if you don't
really know how POV-Ray works internally, don't spread your assumptions.
You seem to somehow assume that POV-Ray stores a JPG or PNG as it is
in memory, without decompressing it.
This, of course, would be technically almost impossible. POV-Ray needs
to read pixels from image maps at random and that just cannot be done from
a compressed JPG or PNG directly. Those image formats need to be
decompressed before they can be used. (Even if someone developed a way
to keep the images compressed on memory and only decompressing them as
needed, that would make the rendering quite a lot slower, not faster as
you seem to believe.)
POV-Ray, naturally, keeps the images in memory in raw format. It has to.
There's no other way to randomly access them.
The only things JPG and PNG will save is disk space, but that's it.
They will not make POV-Ray take less memory, they will not have any
effect on render times (compared to uncompressed image formats) and they
will certainly not shorten parsing time in any way.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kenneth <kdw### [at] earthlinknet> wrote:
> A square image is best (because, by
> default, POV will apply the image to a flat "square area" of 1X1 units in
> the X-Y plane, beginning at the origin ... that is, from <0,0,0> to
> <1,1,1>.)
I suppose you mean from <0,0,0> to <1,1,0>?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
M_a_r_c <jac### [at] wanadoofr> wrote:
> > What's the best resolution to use?
> The resolution at which you cant see the pixels of your bitmap
That's not necessarily true in all possible cases.
Using very high-resolution image maps consumes memory, and in some cases
it's not needed. POV-Ray can perform bilinear interpolation of the image
map which in some cases is enough to make it look good. And having a smaller
resolution the image map will consume less memory which can be used for
other things (eg. more image maps).
In fact, since POV-Ray cannot perform trilinear interpolation (which is
rather difficult in a raytracer with reflections/refractions) using too
high resolution of image map might actually hurt the result.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> (Even if someone developed a way
> to keep the images compressed on memory and only decompressing them as
> needed, that would make the rendering quite a lot slower, not faster as
> you seem to believe.)
http://en.wikipedia.org/wiki/S3_Texture_Compression
I'm mostly pointing this out as a point of interest; I'm not sure how useful
it would be in software (considering the speed loss you mention). You can
use it to store an n by n image in the amount of memory that an n/2 by n/2
image would take, with a small but noticeable loss in quality. Naturally, a
cache can help improve speed.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime wrote:
> http://en.wikipedia.org/wiki/S3_Texture_Compression
>
> I'm mostly pointing this out as a point of interest; I'm not sure how useful
> it would be in software (considering the speed loss you mention). You can
> use it to store an n by n image in the amount of memory that an n/2 by n/2
> image would take, with a small but noticeable loss in quality. Naturally, a
> cache can help improve speed.
Sorry to burst your bubble, but that is a hardware-assisted algorithm that
is designed to trade access time for memory consumption. As such, it would
actually be slower to use is sufficient memory is available. Naturally, on a
graphics card this may _not_ be the case, and compression can help. The
trade off is that at least four times as much memory bandwidth is required
to access a pixel, due to interpolation...
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> Kenneth <kdw### [at] earthlinknet> wrote:
> > A square image is best (because, by
> > default, POV will apply the image to a flat "square area" of 1X1 units in
> > the X-Y plane, beginning at the origin ... that is, from <0,0,0> to
> > <1,1,1>.)
>
> I suppose you mean from <0,0,0> to <1,1,0>?
>
Yes indeed. (I, too, saw this little blooper--after I had posted it,
naturally. Arrgghh!)
Ken
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
