Just thought I would put some of my ideas for POV-Ray 3.5 down, any
suggestions? Have the final features of this version been decided yet?

Definitely needs a double_illuminate keyword, so you can make both sides
of a surface be illuminated.

There should be an internal_reflection keyword, to toggle whether the
inside of an object reflects. This could be used with a clipped plane to
make one-way mirrors.

The unlimited light option would be nice, as I understand it, this light
won't fade when it passes through media, but will still interact with
it.

And of course, angle dependant reflection(maybe refraction too?),
blurred reflection and refraction, and even though I have heard it is
not planned, Photon Mapping! It should probably only be added as an
"experimental feature" like atmosphere and halo were.

Post a reply to this message

I would like to see a 'highlightless' keyword so that you could type:

light_source
{ <10,20,30> rgb 1
  shadowless
  highlightless off
}

  This way you could make shadowless lights which cause highlights on
objects. You could also make regulars lights which don't cause highligths:

light_source
{ <10,20,30> rgb 1
  highlightless
}

but I think that the latter is not so useful as the first one.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On 28 May 1999 11:20:34 -0500, Nieminen Mika wrote:
>  I would like to see a 'highlightless' keyword so that you could type:

May I suggest that the keyword be "highlight" instead of "highlightless"?
I think it's easier to wrap your brain around "highlight on" than the
equivalent "highlightless off"

Post a reply to this message

How about phongless? :)

-mike

Ron Parker wrote:

> On 28 May 1999 11:20:34 -0500, Nieminen Mika wrote:
> >  I would like to see a 'highlightless' keyword so that you could type:
>
> May I suggest that the keyword be "highlight" instead of "highlightless"?
> I think it's easier to wrap your brain around "highlight on" than the
> equivalent "highlightless off"

Post a reply to this message

Mike wrote:
> 
> How about phongless? :)
> 
> -mike

What if it has metallic or specular highlighting ?

Would this keyword also affect the way reflection is calculated ?


-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

> Definitely needs a double_illuminate keyword, so you can make both sides
> of a surface be illuminated.
>

Personally, I'd rather have it handled differently.  Since the idea, to my
way of thinking, is to simulate translucency, it would be better to have a
more thorough treatment of it.  Both color_maps and image_maps should be
available to adjust the amount illumination that shows through and also
effect the coloration.

And since we're on wish lists, I'd really like to see some improvements to
bicubic patch.  The most important one is to do away with u and v steps and
handle the subdivision based on the output resolution.  This is the only way
I know of to insure perfect results.

These things are on my to-do list if I can find time 'to do' them.

-Mike

Post a reply to this message

Chris Huff wrote:
> 
> Just thought I would put some of my ideas for POV-Ray 3.5 down, any
> suggestions? Have the final features of this version been decided yet?

> The unlimited light option would be nice, as I understand it, this light
> won't fade when it passes through media, but will still interact with
> it.

  Add to the media features wish list a selectable sampling method that
can or will produce smoother media with improved speed results. I can
dream can't I ?


-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

Well translucency is a great idea(one I had thought of and forgot), but
I still think having control of double-illumination would be good. Both
of them, not either-or.

Post a reply to this message

Ken asks:
> I can
> dream can't I ?
>

    Well in that case I want a reality_dream setting that when it's value is
above zero it gives that nice, soft, fuzzy around the edges wavering that
dreams have and when the value is below zero it has the black iron claws
that seem to reach for me out of every shadow.

Post a reply to this message

Bill DeWitt wrote:
> 
> Ken asks:
> > I can
> > dream can't I ?
> >
> 
>     Well in that case I want a reality_dream setting that when it's value is
> above zero it gives that nice, soft, fuzzy around the edges wavering that
> dreams have and when the value is below zero it has the black iron claws
> that seem to reach for me out of every shadow.

Well it was made as a serious comment that I believe is echoed by many but
if it helps you achieve this in your work as a side effect then I am for
that too.

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

Ken wrote:
> 
> Mike wrote:
> >
> > How about phongless? :)
> >
> > -mike
> 
> What if it has metallic or specular highlighting ?
> 
> Would this keyword also affect the way reflection is calculated ?
> 
> --
> Ken Tyler
> 
> mailto://tylereng@pacbell.net

How about
light_source{
	location vector
	colour
	...
	diffuse value
	phong value
	specular value }

Makes it easy to tell what each value affects.

Cheers, PoD.

Post a reply to this message

> Well it was made as a serious comment that I believe is echoed by many but
> if it helps you achieve this in your work as a side effect then I am for
> that too.

    No slur on your comment was intended and I regret that it may have
seemed that way.

Post a reply to this message

Bill DeWitt wrote:
 
> > but if it helps you achieve this in your work as a side effect then
> > I am for that too.
    ^ ^   ^   ^    ^
>     No slur on your comment was intended and I regret that it may have
> seemed that way.

  No slur taken nor admonishment intended sir.

  I would like to stress though to anyone who will listen I feel strongly
that the sampling method currently used for the media feature is inadequate
for the process. It is not living up to it's expectations and a major feature
in the program is currently crippled as a result.
  Some of these other suggestions are nice luxury items but this is a feature
attraction that is is not working right or as well as it might. In my opinion
other newer additions can wait for important corrections or improvements. If
the choice comes down to time available only to work on one or the other I
personaly choose improving what we have over adding more onto a crippled
system

Proverb time:

... or as grampa used to say why buy a bucket to catch the water from
the leaky faucet when you can pay to fix the leak instead... or why paint
the car when the engine wont run... or...

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

With the method I described both could be handled in the same manner.  I
think it would also be easier to type.

translucence {
color <1, 1, 1>
}

or

translucence {
color_map {
[0 color rgb <1, 1, 1>]
[1 color rgb <1, 0, 0>]
}
}

or
translucence {
image_map {
tga "leaf.tga"
}
}

The default would be black, which would be double-illuminate off, and
anything other than that would turn it on.  Clearly it would require a new
entity in texture, which some folks might not like, but I don't see how it
could be handled better, unless it was given an entry in finish like irid.

The image_map example also alludes to an important point.  If UV mapping is
going to be in the next release of POV-Ray, it really should have texture
coordinates specified for image_maps, bump_maps, or any other maps within
those statements, and not part of an object's geometry.  Texture
coordinates should be relative to the uv coordinates of a surface, not
redefine them, otherwise all maps can only be applied in one way.

-Mike

Chris Huff wrote:

> Well translucency is a great idea(one I had thought of and forgot), but
> I still think having control of double-illumination would be good. Both
> of them, not either-or.

Post a reply to this message

What I had in mind was more along the lines of having the translucency
{...} stuff be in the interior {...} portion, and have a
double_illuminate keyword in the finish {...} statement.
Double-illuminate would affect the surface of the object (both inside
and outside would be illuminated), and translucence would depend on
thickness, and affect light passing through(photon-mapping + blurred
reflections + translucence = WOW!). I know that translucence can be done
with media, but this is hard to control and slow. A special keyword with
a sampling method designed for doing translucence would be much better.

Post a reply to this message

I'm hesitant to mention this because, for all I know, it's in there
somewhere and I haven't found it yet:

texture coordinates for triangle meshes.

VRML has got this, and it's marvelous.  Quite often I'll sketch in
VRML to get the basic geometry and camera and lighting and then
export to POVRay, and it's kind of weird to lose capabilities
when I go up to POVRay.
+-------------------------------+--------------------------------------+
| Rev. Bob "Bob" Crispen        |            "IT FOUND ME!"            |
| cri### [at] hiwaaynet            |      Campus Crusade for Cthulhu      |
+-------------------------------+--------------------------------------+

Post a reply to this message

Have you looked at the tri-color macro for triangles yet? You may have and
I'm leading you to old stuff. Anyway, it's at:

http://www.geocities.com/SiliconValley/Lakes/1434/otherincludes.html

No idea if this is the same kind of thing you are looking for or not, but
it does apply a pigment to points on the triangles.


Bob Crispen wrote:
> 
> I'm hesitant to mention this because, for all I know, it's in there
> somewhere and I haven't found it yet:
> 
> texture coordinates for triangle meshes.
> 
> VRML has got this, and it's marvelous.  Quite often I'll sketch in
> VRML to get the basic geometry and camera and lighting and then
> export to POVRay, and it's kind of weird to lose capabilities
> when I go up to POVRay.
> +-------------------------------+--------------------------------------+
> | Rev. Bob "Bob" Crispen        |            "IT FOUND ME!"            |
> | cri### [at] hiwaaynet            |      Campus Crusade for Cthulhu      |
> +-------------------------------+--------------------------------------+

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/homepage.htm
 mailto://inversez@aol.com?Subject=PoV-News

Post a reply to this message

Bob Hughes wrote:

> Have you looked at the tri-color macro for triangles yet? You may have and
> I'm leading you to old stuff. Anyway, it's at:
> 
> http://www.geocities.com/SiliconValley/Lakes/1434/otherincludes.html
> 
> No idea if this is the same kind of thing you are looking for or not, but
> it does apply a pigment to points on the triangles.

Many thanks, Bob.  That's a feature request I didn't mention, but
which has a very high coolness-per-byte payoff: per-vertex coloring.
I'm off to try it now.

What I had in mind was mapping 2D coordinates of a texture image to
points on a mesh.  The way it's done in VRML is explained at
http://home.hiwaay.net/~crispen/vrmlworks/tutorials/texture.html
There's a fairly spectacular example of texture coordinates at
http://home.hiwaay.net/~crispen/worlds/avatar/bobhead.wrl -- a
friend of mine did this for me last summer at SIGGRAPH.  It's three
photos overlaid on three laser rangefinder scans of my head.

They messed up on my nose -- it doesn't point west quite so much
as it does in one of those meshes, but thanks to texture coordinates,
when I move the points of my nose over, the texture will move with
the points.

Granted that file formats where meshes are central and you have
point sets and indices (Inventor, VRML, lots of others) make the
texture coordinate mapping pretty compact, but compactness doesn't
matter so much in POV.  There's no reason why it couldn't be
applied to the POV notation just like Chris's tri-colour macro.
Instead of rgb value, just specify the texture image for the
triangle and the coordinates within the image for each point.
+-------------------------------+--------------------------------------+
| Rev. Bob "Bob" Crispen        |            "IT FOUND ME!"            |
| cri### [at] hiwaaynet            |      Campus Crusade for Cthulhu      |
+-------------------------------+--------------------------------------+

Post a reply to this message

That head mesh is great. Only other one I've seen was on TV. I'd wager it
was the crowd at SIGGRAPH that caused the nose to be off center. Somebody
probably nudged the tripod (if the laser range finders were tripod
mounted). heh-heh
From what I could make out of that tri-color macro I thought perhaps a
whole texture (including image_map?) might be done the same way. I'm not
much a user of meshes though.
In case you hadn't heard or seen it, there's a thing called Photo Modellor
that applies images to meshes you create by plotting out the points onto
several views of the pictured object (front, side, top, etc.). Only tough
part is the manual mesh making and I didn't have any success learning to
get the surfaces defined enough. Seems potentially a great thing, free
trial version available. Mike Hough told several of us about it at AOL,
it's at:

 http://www.eossystems.com/Lite/


Bob Crispen wrote:
> 
> Bob Hughes wrote:
> 
> > Have you looked at the tri-color macro for triangles yet? You may have and
> > I'm leading you to old stuff. Anyway, it's at:
> >
> > http://www.geocities.com/SiliconValley/Lakes/1434/otherincludes.html
> >
> > No idea if this is the same kind of thing you are looking for or not, but
> > it does apply a pigment to points on the triangles.
> 
> Many thanks, Bob.  That's a feature request I didn't mention, but
> which has a very high coolness-per-byte payoff: per-vertex coloring.
> I'm off to try it now.
> 
> What I had in mind was mapping 2D coordinates of a texture image to
> points on a mesh.  The way it's done in VRML is explained at
> http://home.hiwaay.net/~crispen/vrmlworks/tutorials/texture.html
> There's a fairly spectacular example of texture coordinates at
> http://home.hiwaay.net/~crispen/worlds/avatar/bobhead.wrl -- a
> friend of mine did this for me last summer at SIGGRAPH.  It's three
> photos overlaid on three laser rangefinder scans of my head.
> 
> They messed up on my nose -- it doesn't point west quite so much
> as it does in one of those meshes, but thanks to texture coordinates,
> when I move the points of my nose over, the texture will move with
> the points.
> 
> Granted that file formats where meshes are central and you have
> point sets and indices (Inventor, VRML, lots of others) make the
> texture coordinate mapping pretty compact, but compactness doesn't
> matter so much in POV.  There's no reason why it couldn't be
> applied to the POV notation just like Chris's tri-colour macro.
> Instead of rgb value, just specify the texture image for the
> triangle and the coordinates within the image for each point.
> +-------------------------------+--------------------------------------+
> | Rev. Bob "Bob" Crispen        |            "IT FOUND ME!"            |
> | cri### [at] hiwaaynet            |      Campus Crusade for Cthulhu      |
> +-------------------------------+--------------------------------------+

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/homepage.htm
 mailto://inversez@aol.com?Subject=PoV-News

Post a reply to this message

I just want a function to tell me the height at a particular coordinate of a
heightfield.  That way I can programatically place objects at the surface of
the heightfield instead of having to place objects by hand with
trial-and-error or externally with a program.

Imagine if you will... Romans charging across a "Khaki" rippling HF plain in
close regular but randomized formation.  Or barbarian blue-skinned celts,
wild-eyed and naked skewered on roman philum.

Seriously, a cohort of soldiers flowing across the crest of a heightfield
would be much more impressive and interesting to look at than ranks of them
lined up on level "boxes".

Towns and villages could be contoured to the terrain giving much more
realistic "spaces".

Owwww heck... just getting the trees to set right on the landscape would be
nice.

Post a reply to this message

On Sun, 30 May 1999 12:25:45 -0500, Bob Crispen wrote:
>I'm hesitant to mention this because, for all I know, it's in there
>somewhere and I haven't found it yet:
>
>texture coordinates for triangle meshes.
>
>VRML has got this, and it's marvelous.  Quite often I'll sketch in
>VRML to get the basic geometry and camera and lighting and then
>export to POVRay, and it's kind of weird to lose capabilities
>when I go up to POVRay.
>+-------------------------------+--------------------------------------+
>| Rev. Bob "Bob" Crispen        |            "IT FOUND ME!"            |
>| cri### [at] hiwaaynet            |      Campus Crusade for Cthulhu      |
>+-------------------------------+--------------------------------------+

Try UVPOV, http://nathan.kopp.com/patched.htm , or the superpatch
(currently offline.)

Post a reply to this message

On Tue, 1 Jun 1999 09:42:08 -0400, Robert J Becraft wrote:
>I just want a function to tell me the height at a particular coordinate of a
>heightfield.  That way I can programatically place objects at the surface of
>the heightfield instead of having to place objects by hand with
>trial-and-error or externally with a program.

You might look at the trace() function in the superpatch.  It was
designed to do this and more.  Unfortunately, the superpatch is
offline at the moment, but it will go back online within the next
day or so; watch for an announcement.

Post a reply to this message

Ron Parker wrote:

> Try UVPOV, http://nathan.kopp.com/patched.htm , or the superpatch
> (currently offline.)

Cool.  If the acronym means what I think it does, it's exactly what
I want.

Many thanks.
+-------------------------------+--------------------------------------+
| Rev. Bob "Bob" Crispen        |            "IT FOUND ME!"            |
| cri### [at] hiwaaynet            |      Campus Crusade for Cthulhu      |
+-------------------------------+--------------------------------------+

Post a reply to this message

Bob Hughes wrote:

> That head mesh is great. Only other one I've seen was on TV.

Thanks -- of course, the only thing I had to do with it apart from
(not) sitting still was to reduce it to something you could download
in your lifetime.  Flamingo Optimizer and Chisel can both decimate
a VRML mesh with texture coordinates without screwing up the
image-to-mesh mapping, which I think is magic.  I can't conceive of
trying to write and debug that code.

> I'd wager it
> was the crowd at SIGGRAPH that caused the nose to be off center. Somebody
> probably nudged the tripod (if the laser range finders were tripod
> mounted). heh-heh

No, it was a problem we both share.  An old friend I hadn't seen in
a while came by and said "Hi, Bob", so naturally I had to take a
drink.  ;-)

The lasers were tripod mounted and they even did an automatic scan
which took about a minute.  He took three scans and three photos
and then imported them into MAX and played with them for about a
minute to join them.  Sorry that I've forgotten who made the
cameras and software, but I'll bet there's a dozen of them at this
year's SIGGRAPH.  Beats the hell out of that little finger thingy
that does sort of reverse STL to scan models in.
+-------------------------------+--------------------------------------+
| Rev. Bob "Bob" Crispen        |            "IT FOUND ME!"            |
| cri### [at] hiwaaynet            |      Campus Crusade for Cthulhu      |
+-------------------------------+--------------------------------------+

Post a reply to this message