Chris Huff wrote in message ...
>In article <38b63a7e@news.povray.org>, "Gail Shaw"
><gsh### [at] monotixcoza> wrote:
>
>> The last texture should be layered over the others, instead
>> of just applying to objects without a texture.
>
>That is a good idea, although it would have to be used with a version
>switch. Maybe also provide for switching this off for specific objects,
>something like:
>union {
>    no_layer_over {
>        object {MyObject1 texture {A...}}
>    }
>    object {MyObject2 texture {B...}
>    ...
>
>    texture {C...}
>}
>MyObject1 would have texture A, and only texture A. MyObject2 would have
>texture B with texture C layered over it. This would be nice if you have
>a CSG with dozens of parts and which has one with a different texture.
>no_layer_over(again, can someone please come up with a better keyword?)
>could act like a kind of union, and contain multiple objects. Perhaps it
>could contain the texture for it's objects itself...
>Of course, this would need to be controlled by a #version switch,
>otherwise nearly every CSG ever done will need to be redone.


For backward compatability I would think the other way round would be
better:

union {
 layered_union

  object {A texture {A}}
  object {B texture {B}}
  texture { PartiallyTransparent}
 }
 object {C texture {C}}
}

Gail
*******************************************************************
* gsh### [at] monotixcoza              * ERROR: COFFEE.COM not found  *
* http://www.rucus.ru.ac.za/~gail/ * Insert cup and press any key *
*******************************************************************
* Definition of an upgrade: Take the old bugs out, put new ones in*
*******************************************************************

Post a reply to this message

Nathan Kopp wrote in message <38b68a04@news.povray.org>...
>
>Gail Shaw <gsh### [at] monotixcoza> wrote...
>>
>> That would make my life SO much easier. Difficult to
>> implement though (Think of the following:
>> difference {
>>  union {
>>   sphere {
>>     <0,0.5,0>,1
>>     pigment {Red}
>>    }
>>    sphere {
>>     <0,-0.5,0>,1
>>     pigment {Blue}
>>    }
>>   }
>>   box {
>>    <0,-2,-2>,<2,2,2>
>>   }
>>  }
>>
>> What colour should the overlapped area of the spheres be?
>> Red, Blue or Purple?
>
>None of those.  The overlapped area should be the color of the box.  The
>surface in question could either belong to the box or to the whole CSG, but
>it couldn't belong to either (or both) of the spheres.
>
>If the box has not texture and you don't specify one for the CSG, then
you'd
>get the default texture.
>


I was replying to Peter's suggestion and illustrating a possible problem.

Peter Popov wrote :
>>>When performing a CGS difference or intersection, any object with a
>>>non-specified texture is assumed to have a black pigment and ambient
>>>0. I think a more reasonable behaviour would be to ignore its texture
>>>and use the texture of whatever object the intersection point is in.

Gail
*******************************************************************
* gsh### [at] monotixcoza              * ERROR: COFFEE.COM not found  *
* http://www.rucus.ru.ac.za/~gail/ * Insert cup and press any key *
*******************************************************************
* Definition of an upgrade: Take the old bugs out, put new ones in*
*******************************************************************

Post a reply to this message

Chris Huff <chr### [at] yahoocom> wrote...

> axis's(axii?)

"axes"

-Nathan

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote...
>
> Chris Huff wrote:
>
> > Also, remove the limitations on layering patterned textures.
>
> The biggest single question I have is what are you breaking by removing
> the current restriction. I have a feeling that it is there for a good
> reason but not being a coder do not know what that reason is.

A significant amount of code would have to be re-worked to remove this
limitation.  The limitation is caused by legacy code.  The original authors
never invisioned this feature, and thus it cannot easily be implemented.
Also, if this limitation were removed and the texturing system were made
more clean and consistent, we may run into backwards-compatibility issues
(the details rather difficult to describe, unfortunately).

-Nathan

Post a reply to this message

Chris Huff wrote:
> 
> In article <bCW1OIjrykoVBR6nY5iI6VMKZ3UL@4ax.com>, Peter Popov
> <pet### [at] usanet> wrote:

> > : chop pieces off with bounding
> >
> > If a bounding object is smaller than what it bounds, the results are
> > unpredictable. I think a more logical behaviour would be the one seen
> > in isosurfaces, i.e. the bounding object should restrict the bounded
> > object, exposing the intersection surface and texture. Of course, it
> > would still bound the object for ray-shape intersection tests.
> 
> This might be a good idea. On the other hand, it would reinforce the bad
> habit of using bounded_by as a kind of CSG...(remember that with some
> settings POV can override this statement and use it's own bounding)

No no no... bounding has nothing to do with CSG and should'nt be
confused with it.

> 
> Patterned light_source's: Have the ability to apply a patterned
> color_map to a light source, with the option to use ray direction and
> depth instead of point position.(which would kind of simulate light
> coming through a colored, transparent sphere surrounding the light
> source, but with depth)
> light_source {blah, blah
>    PATTERN
>    color_map {...}
>    use_depth_for_z on/off
> }
> 
> If the "use_depth_for_z"(somebody please come up with a better keyword!)
> feature is turned on, the angles of the initial emission from the light
> source will be used for the x and y axis, and the distance the ray has
> travelled for the z axis. This should make things like interference
> patterns possible.(I wonder what this would look like combined with
> scattering media and photons!)

Interesting, but I think it should be done the same as sky_sphere
i.e. the colour comes from the intersection of the ray and a unit
sphere.
> 
> --
> Chris Huff
> e-mail: chr### [at] yahoocom
> Web page: http://chrishuff.dhs.org/


PoD.

Post a reply to this message

In article <38b6cbc8@news.povray.org>, "Nathan Kopp" <Nat### [at] Koppcom> 
wrote:

> A significant amount of code would have to be re-worked to remove this
> limitation.  The limitation is caused by legacy code.  The original 
> authors
> never invisioned this feature, and thus it cannot easily be implemented.
> Also, if this limitation were removed and the texturing system were made
> more clean and consistent, we may run into backwards-compatibility issues
> (the details rather difficult to describe, unfortunately).

Something for POV 4.0 maybe?

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

In article <38b68a04@news.povray.org>, "Nathan Kopp" <Nat### [at] Koppcom> 
wrote:

> Note that the keyword used is 'add_layer' instead of 'texture'.  I 
> personally don't like the way that layered textures are currently 
> specified (it has produced unexpected results for me on many 
> occasions before I looked at the source code).  Therefore, this is 
> just a quick brainstorm suggestion (probably not something that I 
> will endorse in the future).

I agree about the layered texture syntax...if someone rewrites it, it 
might also be a good idea to specify the way a texture's contribution is 
calculated: additive, multiplicative, subractive, darken, lighten, etc. 
Something like my old transparency patch(which never got finished). The 
ability to access layers by index might be useful too. Something like:
texture_layers {
   add_layer {subtractive MyTexture// Adds a texture to the list
      at layer_top// or layer_bottom, or index value
   }
   replace_layer {additive MyTextureB// replaces a texture in the list
      at layer_bottom// or layer_top, or index value
   }
   
   //removes a layer from the list
   remove_layer layer_top// or layer_bottom, or index value
}

However, most of the time only "add_layer" would be needed. The only 
uses I can think of for the other keywords would be for modifying 
existing declared objects(not that this wouldn't often be useful...). 
The same would go for the "at" keyword for specifying the position of 
the layer: the default would be layer_top, and so the order could be 
specified just by adding them in order.

And of course this could be a lot of trouble to implement in the current 
code. Another possibility for 4.0?

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

In article <38B6E4BC.977FD8A0@merlin.net.au>, PoD <pod### [at] merlinnetau> 
wrote:

> > This might be a good idea. On the other hand, it would reinforce the bad
> > habit of using bounded_by as a kind of CSG...(remember that with some
> > settings POV can override this statement and use it's own bounding)
> 
> No no no... bounding has nothing to do with CSG and should'nt be
> confused with it.

That is what I was trying to get at-if bounding boxes chop off pieces of 
the object instead of behaving as they currently do, people will mistake 
them for a type of CSG more often. This is a bad thing. I don't want it 
to happen.


> > If the "use_depth_for_z"(somebody please come up with a better keyword!)
> > feature is turned on, the angles of the initial emission from the light
> > source will be used for the x and y axis, and the distance the ray has
> > travelled for the z axis. This should make things like interference
> > patterns possible.(I wonder what this would look like combined with
> > scattering media and photons!)
> 
> Interesting, but I think it should be done the same as sky_sphere
> i.e. the colour comes from the intersection of the ray and a unit
> sphere.

But that would make it a lot less flexible...you wouldn't be able to 
simulate the wave-like characteristics of light, for example. It would 
be the same as placing a small-scaled sphere around the light source.

Hmm, you could even do a cheap imitation of laser beams without photons: 
use the object pattern with two cylinders meeting at a mirror as the 
pigment for the light, and use scattering media with isotropic 
scattering(this would be important, because although the light would 
seem to be constrained to the two cylinders, it's direction would still 
be away from the light_source). This would be messed up by shadows, but 
it is an interesting possible use.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Some wishes arising from my current projects:

Dynamic arrays. In POV, arrays are the best way to acces large datasets, but the
size of the array has to be declared before any data is inserted. The thing is,
you often don't know how much data will be generated. And manually resising a
100,000 element array is inefficient, to say the least.

Better I/O support, such as read/write offset, insertion etc.

Margus

Peter Popov wrote:
> 
> With time I've compiled a list of features I would be happy to see in
> POV-Ray. I think it wouldn't hurt if I posted it here.
>

Post a reply to this message

In article <38B711FF.1E959678@peak.edu.ee>, Margus Ramst 
<mar### [at] peakeduee> wrote:

> Some wishes arising from my current projects:
> 
> Dynamic arrays. In POV, arrays are the best way to acces large 
> datasets, but the size of the array has to be declared before any 
> data is inserted. The thing is, you often don't know how much data 
> will be generated. And manually resising a 100,000 element array is 
> inefficient, to say the least.

Or list and maybe binary tree structures. I actually started on a list 
patch, but realized it was out of my range after looking at the array 
code. Append, resize, and insert functions for an array should be fine, 
but how would multiple dimensions be handled? Maybe a dynamic_array 
which behaves like a C++ STL vector.(If you are not familiar with this, 
it is an object type, a container class which is basically a dynamic 
one-dimensional array. It includes functions for appending, inserting, 
etc)

Maybe also a kind of "pointer". With the appropriate saveguards against 
accessing memory it shouldn't, of course.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message