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