Wasn't it Christopher James Huff who wrote:
>In article <TwEMgAA0$+Z+EwJ### [at] econymdemoncouk>,
> Mike Williams <mik### [at] econymdemoncouk> wrote:
>
>> It's already achievable in POV 3.5. This is a texture I've used for
>> importing transparency maps from Poser. "transmap.jpg" is used to
>> control the transparency and "texture.jpg" is used to control the
>> colour. Obviously, the two image_maps could be replaced by any pattern
>> or function.
>
>This is linearly blending between a transparent texture and a 
>non-transparent one, not quite the same thing.

Well that's all you get if yo have use the alpha channel in the same
image. What extra are you hoping for when the alpha channel is moved to
a different image?

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

> Alpha maps...

I've never tried it but I think povray can use the alpha channel of a PNG

> Specularity maps: better to make all finish values controllable as I
> mentioned for transparency, or add a finish_map feature. I think there
> are patches out there for this, I don't know how complete they are or
> how well it works.

My "finish maps" patch allows to specify a function for each finish
parameter. But it's a quick and dirty hack (there are problems with
transformations). I'll post an example image in p.b.i

M

Post a reply to this message

in news:cja### [at] netplexaussieorg Christopher
James Huff wrote: 

> Displacement mapping: this has been discussed a *lot* on these
> groups. It would require automatic tessellation of all objects, and
> is generally a huge amount of work before you even get to the
> displacement features. [...]

Yes, it has been discussed many times and the answer you give has also 
been given many times. But I completely disagree.

You don't need automatic tesselation of all objects. Displacement 
mapping and also (sub pixel) surface subdivision, are typical features 
for triangle based objects. So why not implement them just for mesh(2) 
to begin with? Why not stretch POV-Ray's mesh-abilities to the maximum
[1]? Displacement mapping and subdivision are allready mentioned, other
things can be 'bones', reading *.obj files, making mesh
available/accessable as array's, writing modified mesh to file,do the
latter for a tesselate bicubic patch or even a NURBS-object.  I'm sure
there's a lot more that could be done while keeping an eye on the
purely triangle based renderers and modellers. 

Once all that is done, or as a parallel project, one can always look
into tesselation of other objects. 

A side effect of strong mesh-abilities will be that POV-Ray will gain 
more attention from 3D-world outside the POV-Ray community, as they are
almost completely triangle mesh orientated. 


[1] ... and why only mesh-abilities? What about, for example, blobs? 
box-blob, spline-blob, torus-blob(section), blob calculation methods 
...? Let me guess, the awnser will probably be "you can do that with 
isosurfaces". As a user, that is not good enough for me (within
limits). When I start building a blob object and feel the need for a

isosurface.

Ingo

Post a reply to this message

In article <Xns### [at] povrayorg>,
 ingo <ing### [at] tagpovrayorg> wrote:

> in news:cja### [at] netplexaussieorg Christopher
> James Huff wrote: 
> 
> You don't need automatic tesselation of all objects. Displacement 
> mapping and also (sub pixel) surface subdivision, are typical features 
> for triangle based objects. So why not implement them just for mesh(2) 
> to begin with? Why not stretch POV-Ray's mesh-abilities to the maximum
> [1]? 

True, and I agree that it would be useful. It just doesn't seem complete 
without a way to turn other primitives into meshes, either explicitly or 
hidden behind a deformation feature.
And it's still a lot of work.


> [1] ... and why only mesh-abilities? What about, for example, blobs? 
> box-blob, spline-blob, torus-blob(section), blob calculation methods 
> ...? Let me guess, the awnser will probably be "you can do that with 
> isosurfaces". As a user, that is not good enough for me (within
> limits). When I start building a blob object and feel the need for a

> isosurface.

You can do that with isosurfaces. ;-)
More blob component types would be very nice, but the math is pretty 
complex, there aren't many people who understand it. What you want is 
probably possible, but you'll have to find someone who knows how to 
implement it.
You might be interested in one of my other projects though. I've been 
working on an updated blob pattern, using a smooth blob function...no 
more abrupt changes in shading and reflections when using it as an 
isosurface. Isosurfaces with this function are much faster than the 
equivalent function written with user-defined functions, but could be 
made even faster with a new "blob2" primitive, which would use an 
isosurface-type solving method with additional optimizations, such as 
only computing the components that can affect the ray. Making all the 
component types you talked about would be very easy (several of them are 
already implemented partially), and you could even use user-defined 
functions as well, though you would have to bound them manually or leave 
them without bounds.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

>  But often, it appears that the artist spent all of
> their time creating the gadgets' shapes, and then simply said "texture
> {wood_12}", and that's a shame.
unfortunately, that's what I do, because I failed to do more realistic
texture than the one already include in povray.
 
> I'm not trying to put down anyone's work, but rather I hope that I'm
> helping
> to make everyone's works more impressive.  There is an entire tutorial
> section (actually 2) on creating textures + finishes, etc.
yes, I didn't find that those tutorials was very helpfull to do realistic
textures. After I finished to read them, I knew a lot of things about
textures.  But when I tried to do one, it was a catastrophe.

-- 
Cyrille Berger

Post a reply to this message

Renderdog wrote:
> 
> The most disappointing aspect of the IRTC is how so many great images are
> let down by plain, or even non-existant, textures. I'm not sure it's a lack
> of tools (though I wish I could layer over a patterned texture!).

Doesn't everyone?

I've never understood why we *can't* do this. A texture, whether it's 
patterned or not, is just a texture. You shoot a ray at an object and 
the texture contributes a few numbers to the color calculation for the 
ray. If it doesn't matter whether the top layer is patterned or not, and 
the texture engine can perform the necessary math to work out the color 
of a layered texture at a given point, why can't that non-top layer be 
patterned?

It almost sounds like some stupid oversight that no one felt 
particularly motivated to fix.. or else the code is old and crufty and 
makes assumptions about textures that aren't necessarily true today, but 
rewriting the code would take a lot of work.

(In which case, this had better be fixed in the semi-mythical 4.0 release.)

-Xplo

Post a reply to this message

in news:cja### [at] netplexaussieorg Christopher
James Huff wrote: 

>> You don't need automatic tesselation of all objects. 

> True, and I agree that it would be useful. It just doesn't seem
> complete without a way to turn other primitives into meshes, either
> explicitly or hidden behind a deformation feature.

Regarding tesselation, why build an object with 'POV-Ray primitives' 
first and then tesselate the result? Why not start with already 
tesselated primitives and then do the CSG etc.? Something like:
 http://gts.sourceforge.net/gallery.html

> And it's still a lot of work.

I guess anything 'new' will be, concidering what is already in POV-Ray 
today.

>> What about, for example, blobs?
> You can do that with isosurfaces. ;-)
> [...] there aren't many people who understand it. 

Yeah, right :)

> I've been working on an updated blob pattern,[...]

Sound good, I'll patiently await the results.

Ingo

Post a reply to this message