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.

  Nope. They are very predictable. Only a ray hitting the bounding object
can hit the bounded object.

  A bounding box is a bounding box, not a clipping box. The current
implementation is the correct one. It should be documented better to
avoid confusion, but it's correct.

-- 
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

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.

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

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.


>  The ability to layer a texture over a complex CSG when each
> part has its own texture (If this is possible without using two copies of
> the object, please
> let me know)
>
> union {
>   object {A texture {A}}
>   object {B texture {B}}
>   texture {PartiallyTransparentTexture layered}
> }
>
> The last texture should be layered over the others, instead
> of just applying to objects without a texture.
>

This could be a very useful feature.  I'd say that you should use a syntax
something like:

union {
  object {A texture {A}}
  object {B texture {B}}
  add_layer {PartiallyTransparentTexture layered}
}

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

-Nathan

Post a reply to this message

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