"Kenneth" <kdw### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> >
> > I do very much like your suggestion of the partial contribution of the
> > cutting
> > object's texture to the surface.  Like adding a bit of f or t in the cutting
> > object's texture to act as a filter to view the final surface through to
> > the final cutaway_texture result, or applying a faint amount of dye in the
> > cutter to tint the surface.   That would be useful indeed.
>
> That can be done even now. :-) It's part of my code test.
>
{snip]
> // When a partially-transparent texture is applied:
> //          1) with cutaway_textures missing, it's hard to tell what happens--
> //             perhaps the look is partially 'hollow' and partially non-
//               hollow,
> //             with the texture's color partially applied to the half-visible
> //             slicing walls. But no 'averaging' of the original objects'
> //             colors occurs.

Hmm, it does not work like I thought, for the reason given. The interiors of the
many objects ARE partially visible, as is the partially-transparent slicing
surface. A mix of the two.

Post a reply to this message

On 12/19/23 03:32, Kenneth wrote:
> It's interesting that you should mention this topic.*Many*  years ago (2009), I
> had a 'discussion' in the newsgroups with long-time user Warp

Thanks for the pointer. I read through it. I'll say my up front concern 
isn't really the averaging(a,b,c) when it comes into play, but rather 
that with relatively simple test cases for the cutaway_textures I found 
bugs and instability in behavior depending on the kind of inputs given 
to the intersection{} and difference{} blocks. Maybe the 'bug' mentioned 
in that 2009 thread compared to v3.6 didn't get fixed - or didn't get 
fixed completely?

(a) - Relative to the specific averaged texture discussion in that 
thread, the yuqk fork introduced a list_object{} pattern for pretty much 
the situation discussed. It allows the user to specify a list of objects 
for a patterned / *_map texture in a last one wins order. In other 
words, the user selects which texture wins in overlapping regions.

(b) - The averaging method provides a way to generate a texture when 
there are object overlaps, but the result is clunky I think; as in not 
being actually useful except to provide 'some' texture result indicating 
overlapping regions. In what I've seen so far you get bits that are 
averaged and bits not, depending on overlaps. If all we are after is 
some special effect - like image transitions in an animation or 
something - the set up could be useful.

(c) - I still haven't unrolled completely how the averaging gets done in 
our code. What concerns me some is the inside tests. These are sometimes 
very expensive. Even fast ones will be costly if there are huge numbers 
of shapes in the input CSG objects to the intersection / difference 
(really a modified intersection).

Anyhow, see the image and yuqk scene file(d) for the list_object{} 
pattern approach as a cutaway_textures alternative - one also with 
limitations.

(d) - I played very briefly with cutaway_textures in this file too and 
it seemed like the behavior was different yet again (ignored sometimes 
where not previous...?), but I didn't dig into it.

Bill P.

Post a reply to this message

Attachments:
Download 'list_object.png' (51 KB) Download 'list_object.pov.txt' (3 KB)

Preview of image 'list_object.png'

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> >
> > Yes, maybe if you reread that, you'll see where you don't understand their
> > point.
>
> I did. All the way through. Ugh. (Embarrassing, ha.) But in the 'present age', I
> now fully understand their point and where I was wrong. My basic assumption back
> then was...naive and rather uninformed :-\

I feel the same way when I read my posts going back to 2013.  <oof>
> Luckily, the UN-textured
> slicing object does not impose its own color on those surfaces...but will if
> given a 'specified' texture of its own.
>
> (I find it interesting-- and useful!-- that the un-textured object behaves this
> way, even though it does have a default texture applied 'behind-the-scenes'. Why
> it does not impose that on the cut surfaces is a mystery to me. But it's a happy
> circumstance!)

Well, if I had to speculate, it would be that there is a difference between a
primitive and an object.  We can define things as primitives, but the default
texture may not actually get assigned to them until we invoke them as visible
objects to be rendered in a scene, perhaps using object {}.

And honestly, I'd call the fact that a textured object can't be used as the
"cutter" without imparting its assigned texture to the intersection surface,
even when cutaway_textures is invoked, either a bug, or at least unexpected or
undesired behaviour.
So if I want to model a complex CSG object that I want to see in the scene, but
also use as a differencing cutter, I have to model it TWICE?
I would think that cutaway_textures should simply ignore all of the assigned
texturing of the cutter, since that's its conceptual function - to use the
textures of the cut object for the remaining surface, not those of the cutter.

> > One way to address the color selection would be to allow the optional
> > inclusion of a hierarchical index in the cutaway_textures call.   No index
> > averages the colors as is currently the default behaviour.  Supplying an
> > index allows the user to choose some texture in whatever texture
> > hierarchy that POV-Ray constructs, up to the max. So, if there are only 2,
> > and you supply 20, then it's texture #2.
>
> Ah yes-- and that would have been the solution to my old argument too!
> Well-explained, laddie.
>
> > I do very much like your suggestion of the partial contribution of the cutting
object's texture to the surface.  ..
. That would be useful indeed.
>
> That can be done even now. :-) It's part of my code test.

I copied and rendered the code, since The Naughty Walker didn't attach the scene
as a .pov file.  :P

> > And truly, I think it would be as simple as adding the cutting object's
> > texture into the averaged result.
>
> Exactly.

Wait, wha...?   We agree?
To quote Phil Collins, "There must be some misunderstanding...."  ;)

- BW

Post a reply to this message

So, my waking brain was just meandering over this topic, and I was wondering:

We have the object pigment pattern feature, and we have cutaway_textures.

How difficult would it be to implement a sort of hybrid feature?

Consider I have a base object, and I want to "intersect" it with another object,
but not do a CSG - rather leave the "imprint" of the other object on its
surface.

I suppose this is the object pattern, but with a different, simpler syntax,
perhaps leveraging whatever existing algorithmic processes exist under the hood
for cutaway_textures.

If I were to start intersecting the base object with a loop of random spheres
with random pigments, then the final result would either be the average of all
the overlapping spheres' pigments on the surface of the base object, or the
last-intersected sphere's pigment would take precedence, sort of like a
z-buffer/painter's algorithm.

Just an idea to throw out there.

- BW

Post a reply to this message

On 2023-12-18 11:16 (-4), William F Pokorny wrote:
> While continuing to think about yuqk / v4.0 texturing clean up /
> changes, I took a detailed look at cutaway_textures.
> 
> I'm pretty sure the 0110 difference case below should end up as 'Red
> Red'. The nullptr result for the pigment I see as a bug itself in any
> case - the pigment should end up set to something valid.
> 
> The behavior is identical v3.7-stable, v3.8 beta 2 and yuqk on linux.
> 
> Do windows users see the same bug?

I'm also using GNU/Linux, but for what it's worth, case 0110 halts in
POV-Ray 3.5 and 3.6 with the message "Rendering Error: No textures in
multi-texture CSG object."

Post a reply to this message

On 12/22/23 08:29, Cousin Ricky wrote:
> I'm also using GNU/Linux, but for what it's worth, case 0110 halts in
> POV-Ray 3.5 and 3.6 with the message "Rendering Error: No textures in
> multi-texture CSG object."

Thanks! :-) I wondered what might be happening in earlier versions but 
was too lazy to run it.

I was considering adding a render time error to yuqk too as something 
better than what is happening. However, I believe I've worked out a 
relatively simple fix.

In the file csg.cpp and the function CSG::Determine_Textures, change the 
line:

     if (Type & CSG_DIFFERENCE_OBJECT)

to

     if ((Type & CSG_DIFFERENCE_OBJECT) &&
         (children[0]->Texture != nullptr))

This aligns the results with those of intersection{} where the first 
object in the difference has no texture - and we are using cutaway_textures.

I've also worked up some yuqk documentation which goes as far as my 
current understanding of cutaway_textures goes. I'll stick the top part 
of that documentation below.

Bill P.


---
cutaway_textures

A modifier used with intersection and difference to tweak texturing

The keyword can only be used with a difference{} or intersection{} block.

The cutaway_textures is specified with no arguments.

The cutaway_textures keyword is useful ONLY where more than one, but not 
all of the objects in an intersection{} or difference{} blocks have no 
texture and there is no texture specified in the parent intersection{} 
or difference{}.

The keyword can always be used in any difference{} or intersection{} 
block, but as a rule, never do this where the keyword is not useful as 
it triggers extra work during ray tracing / rendering.

---
Useful things to remember when trying to understand cutaway_textures 
results.
---

0) If none of the input objects have textures, the parser will assign 
the current default texture to everything and cutaway_textures will have 
no effect.  This action of the parser can occur during a chain of csg / 
object {} block wraps prior to the difference{} / intersection{} blocks. 
In other words, it helps to keep the inputs - especially the 'cutting 
shape' - simple when attempting to use cutaway_textures.

1) If all input objects have textures, cutaway_textures will have no effect.

2) If the difference{} or intersection{} blocks themselves have a 
texture specified, cutaway_textures will have no effect.

3) Where the inputs are simple single objects (sphere, cone, etc) and 
one or more of the inputs (as seen by the current ray) is not textured, 
but one of the inputs is, use of cutaway_textures will result in the 
copying of of the other input's texture. This can vary, if the input 
object's texture vary.

4) Where the inputs are multiple, simple objects as with a csg input the 
resulting texture from the 'cut' will be an average of all the textured 
components - as seen by the current ray and determined by inside object 
tests.  (Yes, cutaway_textures can get expensive)

5) During parsing and internal to POV-Ray the cutaway_textures keyword 
prevents the copying of the default texture, leaving the texture pointer 
set to nullptr.  It further sets a cutaway_textures flag on those shapes 
with no texture as well on the parent intersection{} or difference{}. At 
render time and for each ray interacting with components having the 
cutaway_textures flag and no texture, extra work gets done to determine 
a resulting texture.

6) The direct inputs being a union{} or merge{} makes no difference. 
Less sure about uses of merge{} in csg chains coming into the 
difference{} / intersection{} blocks.

7) What happens with nested difference{} and intersection{} blocks using 
cutaway_textures in other difference{} and intersection{} blocks also 
using cutaway_textures was not explored - and unsure what happens.

Post a reply to this message