Ok, first, small picture to capture you attention (attached).

Now, problem I have with that. I'm using nested objects of objects 
(small POV example attached), and it seems like when I enable pigment or 
something at the minimal level, it overcomes instructions for top 
object. Sorry, haven't found anything about it in POV help.

My problem is, I want a per-object normal, rather than per-union. But 
when I uncomment

#declare bublik = torus {0.5, 0.25
//    normal {spiral1 5, 0.1 blah-blah-blah

pigments for all the objects made from "bublik" go to hell. I want 
colors from that higher level objects, but normal from "bublik" since it 
have orientation I want. Any chances I can have it? Did I miss anything? 
(in help file, I mean)

Ilyich the Toad

Post a reply to this message

Attachments:
Download 'l1.png' (237 KB) Download 'windows-1251' (1 KB)

Preview of image 'l1.png'

Ilya Razmanov <ily### [at] gmailcom> wrote:
> Ok, first, small picture to capture you attention (attached).

Excellent.   This is very cool.  :)

More please!

> My problem is, I want a per-object normal, rather than per-union. But
> when I uncomment
>
> #declare bublik = torus {0.5, 0.25
> //    normal {spiral1 5, 0.1 blah-blah-blah

So, you're in very tricky territory right here.
I think what you might need to do is give each item a layered texture - try
making the base layer your pigment, and the top layer clear, but with a normal.

object {
     bublik
     texture {pigment {}}
     texture {pigment {rgb 1} normal {MyNormal}}
}

Or something like that.

- BW

Post a reply to this message

On 31.01.2024 17:42, Bald Eagle wrote:

> Excellent.   This is very cool.  :)
> 
> More please!

Long ago I did something for textile simulation using normal 2D approach 
(well, more like 2.5D), but it went to people who paid for it. But now, 
with CPU speed drastically improved, chances are I can use 3D for this.

But so far prototype is full of junk, and I have next to no idea how to 
simulate irregular displacement.

But anyway, I'll share it on my github place when I remove all the junk 
I can find and add something looking more interesting than plane plastic 
wire. This grid is typical to linen, for example, but I need linen 
texture for it.

What as to textures, surely, I can decompose whole object down to thors, 
sorry, as you were, tori (damn it, aren't tori some sort of gates in 
Japan? anyway, I mean plural for donut) and assign anything necessary to 
each of them separately, but it will make development and especially 
debugging somewhat more complicated.

Ilyich the Toad
https://github.com/Dnyarri/

Post a reply to this message

On 1/31/24 08:14, Ilya Razmanov wrote:
> Any chances I can have it?

The usual way is to use the fast path texture element overrides.

//---
...
#declare Fn00 = function { pattern { spiral1 12 scale 1/6} }
#declare Fn01 = function { pattern { wrinkles scale 1/99 } }
#declare Tor00 = torus {
     0.5, 0.15
     // What follows are overrides of the default texture's
     // three components - creating a new texture for Tor00.
     pigment { White }
     normal {
         function { (Fn00(-x,y,z)+Fn01(x,y,z)*0.2)/1.2 }
         bump_size +0.67 rotate x*90
         accuracy 0.005
     }
     finish { ambient 0.0 brilliance 1.5 }
}

object { Tor00 } // White around origin.

// White on left side of image
union {
     object { Tor00 translate y*-0.7 }
     object { Tor00 translate y*+0.7 }
     pigment { Green } // Ignored where objects are textured.
     translate (x+z)*-1.25
}

// Following is a way to override just the pigment component
// of the texture already on Tor00.
union {
     object { Tor00 pigment { Green } translate y*-0.7 }
     object { Tor00 pigment { Red }   translate y*+0.7 }
     translate (x+z)*+1.25
}
...
//---

There are limitations to the approach where the texture{}s are 
non-simple (ie layered) or a material{} is used.

Bill P.


Aside: Remember how in v3.8 beta2 is spiral1 is really spiral2 due a 
typo? Well, I coded a v3.7 version for posting here after my yuqk 
version (where spiral1 is spiral1) and, dang if doesn't look like the 
rotate of the spiral has been flipped in yuqk / v3.8? relative to v3.7.
I don't think this something I did, but suppose I might have to create
a fixed version of v3.8 beta 2 to be sure...

Post a reply to this message

Attachments:
Download 'keepnormal.jpg' (51 KB)

Preview of image 'keepnormal.jpg'

William F Pokorny <ano### [at] anonymousorg> wrote:

> The usual way is to use the fast path texture element overrides.

> // Following is a way to override just the pigment component
> // of the texture already on Tor00.


> There are limitations to the approach where the texture{}s are
> non-simple (ie layered) or a material{} is used.

I always thought that once the object was textured, it was fixed, and could not
be overridden.  This has been discussed in the past, so I'm surprised.  I also
do a lot of scenes where I have some objects in a union textured/pigmented and
then the union gets a texture/pigment, and only the default textured objects get
the union texture.


> Aside: Remember how in v3.8 beta2 is spiral1 is really spiral2 due a
> typo? Well, I coded a v3.7 version for posting here after my yuqk
> version (where spiral1 is spiral1) and, dang if doesn't look like the
> rotate of the spiral has been flipped in yuqk / v3.8? relative to v3.7.
> I don't think this something I did, but suppose I might have to create
> a fixed version of v3.8 beta 2 to be sure...

I thought you had fixed the uv-mapping of the torus, so that it's consistent
with all of the other primitives, and not backwards anymore.  Does that have
anything to do with it?  (probably not, but...)

- BW

Post a reply to this message

On 2/1/24 07:19, Bald Eagle wrote:
> I always thought that once the object was textured, it was fixed, and could not
> be overridden.  This has been discussed in the past, so I'm surprised.  I also
> do a lot of scenes where I have some objects in a union textured/pigmented and
> then the union gets a texture/pigment, and only the default textured objects get
> the union texture.

It can be confusing and we're not helped due some of the documentation 
being misleading.

Internally what happens is things not explicitly textured with 
texture{}(s) / material{} or by creating a texture via one of the fast 
path / shorthand texture component texture specifications, like a not 
texture{} wrapped color or pigment{} block specification, are not 
textured at all until a post process step of the parsing.

In that post step the parent 'stuff' which exists is pushed down onto 
the children - or the default texture gets applied - where there isn't 
already 'stuff'. (lying a little)

The thing about the fast path texture component methods is they 
sometimes assign the default texture and modify a particular component 
of it. Or, they modify a particular component of the existing attached 
texture. Supposing an already textured Tor00 and Tor01 with no texture.

object { Tor00 pigment{...} } // Modifies the already attached texture.
object { Tor01 pigment{...} } // Modifies / applies default texture

object { Tor00
// Replaces attached texture with modified, default texture. The
// texture{} wrap without a passed texture ID always starts with the
// default texture.
   texture { pigment {...} }
}

Aside: Good memory on the torus uv mapping! :-) One of the three forms 
was mistakenly created right handed. I do still flip it to left handed 
as I recall in the yuqk code. The official v3.8 POV-Ray releases left 
the mapping code as is. At the moment, not sure how it could be related, 
but maybe? I'm in the middle of some other code work, so the 
investigation on the spiral 1 & 2  won't happen for a while.

Bill P.

Post a reply to this message

On 01.02.2024 8:37, William F Pokorny wrote:
> On 1/31/24 08:14, Ilya Razmanov wrote:
>> Any chances I can have it?
> 
> The usual way is to use the fast path texture element overrides.
> 
> //---
> ...
> #declare Fn00 = function { pattern { spiral1 12 scale 1/6} }
> #declare Fn01 = function { pattern { wrinkles scale 1/99 } }

Sorry for extremely dumb question but I'm too slow and looks like I'm 
missing something.

It seems like people are capable to define procedural, that is, 
algorithmic textures and stuff (for example, normals), to be calculated 
by POVRay internally, to be used in scenes. I mean defining them as some 
sort of non-POVRay-specific built-in functions but rather as some 
general math function similar to that in general programming languages.

I, however, am unable to find any understandable docs regarding this. I 
guess I'm completely wrong somewhere - asking wrong questions, searching 
in wrong places, etc. Any ideas regarding what may be the right place to 
get something to read?

Ilyich the Toad

Post a reply to this message

Ilya Razmanov <ily### [at] gmailcom> wrote:

> It seems like people are capable to define procedural, that is,
> algorithmic textures and stuff (for example, normals), to be calculated
> by POVRay internally, to be used in scenes.

Welcome to functions!

https://wiki.povray.org/content/Reference:Function

"Declaring User-Defined Color Functions
Right now you may only declare color functions using one of the special function
types. The only supported type is the pigment function. You may use every valid
pigment. This is a very simple example:

#declare foo = function {
  pigment {
    color red 1
    }
  }

#declare Vec = foo(1,2,3)
An example using a pattern:

#declare foo = function {
  pigment {
    crackle
    color_map {
      [0.3, color Red]
      [1.0, color Blue]
      }
    }
  }"

Post a reply to this message

On 2/8/24 04:01, Ilya Razmanov wrote:
> Any ideas regarding what may be the right place to get something to read?

Glad Bill W got you started with answers.

I'd add that a look at the documentation for isosurface and parametric 
surfaces - which are based on functions - might help. There are user 
defined pigments, densities, cameras possible too with examples. You can 
search the shipped example scenes for 'function'. Of course patterns and 
their modifiers are more or less functions of a sort too.

Ah, and you can look at the functions.inc include itself for 
descriptions of the inbuilt functions and their parameters in official 
releases of POV-Ray. I think a rough copy of the documentation therein 
is include somewhere in the official web documentation too. The warning 
I'd give is not all of the function.inc function and parameter 
description are accurate - it something seems really confusing, it might 
be a documentation mismatch. It is what is.

As for a really good, all in one tutorial, Mike Williams published what 
I think was the best one for functions and isosurfaces / parametrics. It 
was one from which I learned a lot, but the web site is no longer 
active. The wayback machine has a copy and, IIRC, Bill W (or someone) 
put a copy of a lot of it somewhere accessible?

I'm attaching scene and image output file. The scene started with Mike's 
cylcoords.pov from that tutorial - which I modified somewhat as the 
attached version given you were working some with textured torus 
objects. Once the base shape is in place, it's possible to get many 
different looks by changing parameters to the component functions. I 
often find it fun to just push parameters around and render repeatedly 
just looking at what appears in the final render.

Aside: My yuqk fork differs substantially with respect to built in 
functions and the interplay between patterns and functions - and I'm 
still hacking on the inbuilt code quite a bit. I don't have ready 
documentation which relates well to official POV-Ray releases. Yuqk's 
documentation for concepts sometimes OK, but particulars will often be 
different.

Bill P.

Post a reply to this message

Attachments:
Download 'cylcoords1.jpg' (98 KB) Download 'cylcoords1.pov.txt' (2 KB)

Preview of image 'cylcoords1.jpg'

William F Pokorny <ano### [at] anonymousorg> wrote:

> As for a really good, all in one tutorial, Mike Williams published what
> I think was the best one for functions and isosurfaces / parametrics. It
> was one from which I learned a lot, but the web site is no longer
> active. The wayback machine has a copy and, IIRC, Bill W (or someone)
> put a copy of a lot of it somewhere accessible?

Thanks for the reminder.
I just sent him a copy.

I think the document (pdf) is ~4mb, and the zip is 176 kb.
Perhaps we can find a spot to host the files?   The Wiki?
A link from the main page?   References?

- BW

Post a reply to this message