Andreas Kreisig wrote:
>Slashdolt wrote:
>> I'm not sure if people simply don't notice, aren't sure what to do about
>> it,
>> or run out of time, or what.  I feel like we need a phrase similar to,
>> "Location! Location! Location!" (Textures! Textures! Textures!).  Anyone
>> can create a box, but creating a box with a 3-layer texture and some sort
>> of
>> normal plus a great finish can really pull it into reality.  So many
>> images could become incredible images if people would simply spend more
>> time on the textures.
>
>In my opinion POV-Ray needs more features regarding textures similar to
>other 3D applications like alpha maps, specularity maps (!!) or image based
>displacement mapping. The textures in POV-Rays include files are powerfull
>but in most cases not very realistic. Or you have not enough control about
>them, e.g. if you need rust or specularity only on special areas. In this
>cases you actually need an image map so that you can define these areas
>exactly.

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!).

POV-Ray has a good number of texturing tools, and if you spend enough time
at it you can get wonderful results. But it does take a lot of time (to
learn and to use). POV-Ray could use better starting points than the
terrible include files that often send you in the wrong direction. The IRTC
zip files provide a resource for good textures, though not organized for
quick access.

Also, I think artistic visual ability is required to "see" an object clearly
to know what texturing it needs. Photographic references help, but a simple
change of lighting can make a reference subtly wrong. One of the most
disappointing aspects of textures is how they almost always have to be
massaged for scale, position and lighting, so simply reusing a texture is
almost never good enough.

Post a reply to this message

Slashdolt's furious key-hammering produced this:
> As for the texture includes, I generally start using them for test-renders,
> and then end up creating my own textures, pigments, finishes, etc.,

I usually just set up a default, basic white texture (pigment{rgb 1}) and get
the scene modelling done first.

Using the ones in the includes isn't a half bad idea for tests, though.  It
might give a better idea of what the scene's going to look like.

> as I generally dislike the ones in the includes.  (Sorry)

I wouldn't really be sorry about saying that.  The ones in the includes are
pretty old.  Let's just say, the first time I downloaded POV-Ray was in 1995 and
I don't think very many new textures were added since then. :)

-- 
/*^*/light_source{100*<-5,2,-5>2}#macro I(i,n)#while(strlen(i)>=n)#local A=asc(
substr(i,n,1));#local a=asc(substr(i,n+1,1));cylinder{<div(A,8)-12,mod(A,8)-4,4
><div(a,8)-12,mod(a,8)-4,4>,0.1pigment{rgb z}}#local n=n+2;#end#end I("ScUe[]"1
/*<*/)I("mkmtlttk"1)//@_$#!,:<"Thhis polysig brought to you by Ian Burgmyer :)"

Post a reply to this message

Slashdolt <jer### [at] questsoftwarecom> wrote in message
news:3e67adfe$1@news.povray.org...
> Just an observation...  (Don't kill me!)
>
> From viewing IRTC images and some WIPs from past and present, it seems
like
> many of them are very complex images, for which someone probably spent
TONS
> of time creating.  But the one thing that strikes me so often is that the
> textures/finishes are not quite right.
>
> Textures are very hard to get right, I understand.  I spend most of my
time
> on textures when I create an image, and even so, I would agree that it's
> still not perfect.  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.
>

I'm a texture collector. Textures can make or break an image.  I usually
work on textures a lot in an image, and I create most of my own from
scratch. The only POV textures I have used 'as is' are some in glass.inc. I
use POVs wood textures, but usually modify them.

All my 3D experience prior to learning POV was in Bryce, so I'm probably
biased, but having a texture editor like Bryce's DTE for POV textures would
be great!  Creating good textures is time consuming even in Bryce, and far
more so in POV.

I can create pigments fairly quickly using Bob's color picker (thanks Bob!),
and I can even get basic finishes fairly quickly, primarily because I've
used Bryce's editor enough to know what I'm looking for as far as diffuse,
specular etc. But fine tuning finishes takes time, and the finer it is
usually the longer it takes to render, so testing starts running into
overtime.

And normals are harder to do, take even longer to test render, only to
discover it wasn't what you thought at all, and you have to start all over.
So far I have not been able to get the kind of detail I want in my POV
textures simply because I don't have the time to spend on them.

Having an editor that lets you do all that in one place, and see what you
are doing while you do it invaluable, especially when time is critical.

RG

Post a reply to this message

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