Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 16-1-2024 om 16:02 schreef Bald Eagle:
> > I gave it a go, since I had to visualize the rotations, lest it bother me for
> > the rest of the day. [...]
>
> Thanks Bill! I gave it a go and I noted the following:
>
> 1) [..]
> 2) [..]
> 3) so it appears (to me) that the texture does not follow the object
> rotation. Why this is is a mystery to me and it is the first time I
> witness such behaviour indeed.
>
> --
> Thomas

About your parallel lines result: have you tried the new macro with a sharpness
value above 0.5?

Regarding your third bullet point... The texture not following the object's
rotation is an issue I predicted, but was unsure if it would manifest or not. My
guess is that the slope inputs (x, y, z) need to be rotated independently of the
object, which probably means using vrotate() for the slope inputs to match the
object.

I'll need to test that...

Sam

Post a reply to this message

"Samuel B." <stb### [at] hotmailcom> wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> > 3) so it appears (to me) that the texture does not follow the object
> > rotation. Why this is is a mystery to me and it is the first time I
> > witness such behaviour indeed.
>
> Regarding your third bullet point... The texture not following the object's
> rotation is an issue I predicted, but was unsure if it would manifest or not. My
> guess is that the slope inputs (x, y, z) need to be rotated independently of the
> object [...]

(To everyone: I'm sorry for not replying to everything right now.)

As you've seen, rotating an object using a slope pattern doesn't give the result
one would hope for. Whether the rotation is placed before or after the triplanar
pattern matters a /bit/, but not enough: in either case the result will be
wrong. The answer seems to be to rotate the slope vectors /independently/ of the
object.

In the attached image, the left object is rotated in a naive manner. The right
object uses a new macro that rotates the slope vectors in tandem with the
object. It can be a hassle to do it this way, but it would appear that if you
wish to rotate your object it's what you have to put up with ;)

Here's the scene code:

/*
 triplanar-debug.pov

 2024 stb

 +fn +f +a0.3 +am2 +r2 +w1024 +h512
*/


#version 3.7;

global_settings{assumed_gamma 1.0}

camera{
 orthographic
 right x*2 up y
 location <0, 5, -10>
 look_at 0
 angle 33
}

// sunlight
#if(true)
 light_source{
  <1, .5, 0>*1e5, srgb <1.5, 1.4, 1.3>
  shadowless
 }
#end

// starry background
#if(true)
 background{rgb .5}
#end

// input image for triplanar color and normal
#declare PImg =
 pigment{
  image_map{
   png "craters.png"
   interpolate 2
  }
  scale 2
 }

#declare ObjRotate = <0, 37, 0>;

/*
 Triplanar macro
  Pigment: a pigment oriented in the z-direction
  Sharpness: a value between 0 and 1
  Rotate: the object's rotation
*/
#macro TriplanarR(Pigment, Sharpness, Rotate)
 pigment_pattern{
  slope vrotate(x, Rotate)
  triangle_wave
 }
 pigment_map{
  [0+.5*Sharpness Pigment rotate y*90]
  [1-.5*Sharpness
   pigment_pattern{
    slope vrotate(y, Rotate)
    triangle_wave
   }
   pigment_map{
    [0+.5*Sharpness Pigment rotate x*90]
    [1-.5*Sharpness Pigment rotate z*165]
   }
  ]
 }
#end

// don't use this if you want to rotate your object
#macro Triplanar(Pigment, Sharpness)
 pigment_pattern{
  slope x
  triangle_wave
 }
 pigment_map{
  [0+.5*Sharpness Pigment rotate y*90]
  [1-.5*Sharpness
   pigment_pattern{
    slope y
    triangle_wave
   }
   pigment_map{
    [0+.5*Sharpness Pigment rotate x*90]
    [1-.5*Sharpness Pigment rotate z*165]
   }
  ]
 }
#end

// object on left (naive rotation)
superellipsoid{
 <.2, .2>

 texture{
  pigment{pigment_pattern{Triplanar(PImg, .5)}}
  normal{
   pigment_pattern{Triplanar(PImg, .5)}
   poly_wave .5
   bump_size .75
   accuracy .01
  }
 }

 rotate ObjRotate

 translate -x*1.5
}

// object on right (corrected rotation)
superellipsoid{
 <.2, .2>

 texture{
  pigment{pigment_pattern{TriplanarR(PImg, .5, ObjRotate)}}
  normal{
   pigment_pattern{TriplanarR(PImg, .5, ObjRotate)}
   poly_wave .5
   bump_size .75
   accuracy .01
  }
 }

 rotate ObjRotate

 translate x*1.5
}


Sam

Post a reply to this message

Attachments:
Download 'triplanar-debug.jpg' (59 KB)

Preview of image 'triplanar-debug.jpg'

"Samuel B." <stb### [at] hotmailcom> wrote:
> it would appear that if you wish to rotate your object it's what you have to put up
with

After more testing, I think the best and most general way to handle this is to
not use the most recent macro after all. Just simply rotate all your objects
/before/ using the original Triplanar macro like so:

 superellipsoid{
  <.2, .2>

  rotate ObjRotate

  texture{
   pigment{pigment_pattern{Triplanar(PImg, .5)}}
   normal{
    pigment_pattern{Triplanar(PImg, .5)}
    poly_wave .5
    bump_size .75
    accuracy .01
   }
  }
 }


The left image again uses naive rotation, but with the rotation applied before
the Triplanar macro. There will still be some warping but hopefully no parallel
lines. (Some artifacts are unavoidable when applying such an experimental
feature on many different;y oriented objects :))

Sam

Post a reply to this message

Attachments:
Download 'triplanar-debug-2.jpg' (59 KB)

Preview of image 'triplanar-debug-2.jpg'

"Samuel B." <stb### [at] hotmailcom> wrote:
> it would appear that if you wish to rotate your objects you have to put up with

some issues.

There will always be some stretching, since not all objects will be boxes or
superellipsoids aligned to one sole direction. You have to do your
transformations before applying the triplanar mapping.

Here's the code used to make the attached image:

/*
 triplanar-debugB.pov

 2024 stb

 +fn +f +w960 +h540
*/


#version 3.7;

global_settings{
 assumed_gamma 1.0
 #if(1)
  radiosity{
   count 1
   error_bound .05
   recursion_limit 1
   nearest_count 10
   normal on
  }
 #end
}

camera{
 orthographic
 right x*1.77 up y
 location <0, 5, -10>
 look_at 0
 angle 33
 aperture .28 focal_point 0 blur_samples 10 variance 0
}

// sunlight
#if(true)
 light_source{
  <1, .5, 0>*1e5, srgb <1.5, 1.25, 1>
  #if(1)
   #declare ALRes = 2;
   #declare ALSize = .1*1e5;
   area_light x*ALSize, z*ALSize, ALRes, ALRes
   jitter
   adaptive 1
   //area_illumination
  #end
 }
#end

// background
#if(true)
 background{rgb <.3, .5, .7>}
#end

// input image for triplanar color and normal
#declare PImg =
 pigment{
  image_map{
   png "craters.png"
   interpolate 2
  }
  scale 2
 }

#macro Triplanar(Pigment, Sharpness)
 pigment_pattern{
  slope x
  triangle_wave
 }
 pigment_map{
  [0+.5*Sharpness Pigment rotate y*90]
  [1-.5*Sharpness
   pigment_pattern{
    slope y
    triangle_wave
   }
   pigment_map{
    [0+.5*Sharpness Pigment rotate x*90]
    [1-.5*Sharpness Pigment rotate z*165]
   }
  ]
 }
#end

// random objects
union{
 plane{y, 0}
 #local Seed = seed(1002);
 #for(I, 0, 20)
  superellipsoid{
   <.2, .2>
   scale .2+.8*rand(Seed)
   rotate 360*<rand(Seed), rand(Seed), rand(Seed)>
   translate 12*(<.5-rand(Seed), 0, .5-rand(Seed)>)
  }
  torus{
   .5, .2
   scale .2+.8*rand(Seed)
   rotate 360*<rand(Seed), rand(Seed), rand(Seed)>
   translate 12*(<.5-rand(Seed), 0, .5-rand(Seed)>)
  }
  sphere{
   12*(<.5-rand(Seed), 0, .5-rand(Seed)>), .2+.8*rand(Seed)
  }
  cone{
   0, .5, y, 0
   scale .2+.8*rand(Seed)
   translate 12*(<.5-rand(Seed), 0, .5-rand(Seed)>)
  }
 #end

 // triplanar mapping after all transformations
 texture{
  pigment{
   pigment_pattern{Triplanar(PImg, .75)}
   color_map{
    [0 rgb <.05, .1, .15>]
    [1 rgb <.9, .85, .8>]
   }
  }
  normal{
   pigment_pattern{Triplanar(PImg, .75)}
   bump_size 1
   accuracy .01
  }
 }

}

Post a reply to this message

Attachments:
Download 'triplanar-debugb2m_17s.jpg' (123 KB)

Preview of image 'triplanar-debugb2m_17s.jpg'

Living in different time zones have their advantages! ;-)

While I was sleeping you seem to have really tackled the issues with 
triplanar mapping. With my early morning cup of hot coffee beside me, I 
have been reading your posts. Thanks for all that good work, gentlemen!

No opportunity now to answer in detail, but I am going to seriously 
apply the latest codes to my test range.

Again, my deeply felt appreciation for all your creative thinking and 
coding. This really is a great community!

-- 
Thomas

Post a reply to this message

Nice work - that's looking really good!  :)

So now here's a question - while trying to hunt down an answer to WFP's default
importance question, I stumbled upon a thread where clipka discusses
pleochromism.

https://en.wikipedia.org/wiki/Pleochroism

I know that I've brought up the topic of wet paper in the past in this regard.

It seems that this approach might also make for a good anisotropic effect if we
roll some layered texturing + filter/transmit into it?

What do you think?

- BW

(You wouldn't believe how hard it is to find an example image of this effect)

Post a reply to this message

Op 16-1-2024 om 17:51 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>> 3) so it appears (to me) that the texture does not follow the object
>> rotation. Why this is is a mystery to me and it is the first time I
>> witness such behaviour indeed.
> 
> I think it might be more of an issue of how the image_map is oriented with
> regard to the slope, (+90 vs -90 deg).
> 
Yes, I guess you are right.


> I also don't think I have a complete pattern definition, since I was unsatisfied
> with how the slope controlled 100% pigment when perfectly aligned with an axis
> vs rgbt 1 when perpendicular to it.
> 
> I would suggest looking at the method of creating a normal map by user "NPC"
> used in this thread:
>
https://news.povray.org/povray.binaries.images/thread/%3Cweb.5d978f0b44e99bc84eec112d0%40news.povray.org%3E/
> 
> The key being:
> sine_wave frequency 0.5 phase -0.25
> 
I need to plunge into this... it does not seem to improve /that/ much 
(at least for the sine_wave option).


> which, indeed, when I add that frequency and phase correction in my WaveType
> macro, seems to get rid of what you might be seeing.
> (left: pigment applied before -90*y rotation, right: pigment applied after -90*y
> rotation)
> 
> Try and experiment.

To date, what works best with your code, is using triangle_wave or 
scallop_wave as WaveType, as those show least artefacts it seems on the 
superellipsoid (see attachment: use of triangle_wave). Still, I have not 
yet fully experimented your code in comparison with Sam's but I intend 
to do so.

-- 
Thomas

Post a reply to this message

Attachments:
Download 'be_triplanar mapping.jpg' (250 KB)

Preview of image 'be_triplanar mapping.jpg'

Op 17-1-2024 om 04:40 schreef Samuel B.:
> There will always be some stretching, since not all objects will be boxes or
> superellipsoids aligned to one sole direction. You have to do your
> transformations before applying the triplanar mapping.
> 
Sam, I am very happy with this final development, thank you very much 
for your efforts!

I think the time has come to apply this to my Logo Planet scene. Stay tuned!

-- 
Thomas

Post a reply to this message

Attachments:
Download 'sb_triplanar mapping.jpg' (336 KB)

Preview of image 'sb_triplanar mapping.jpg'

Op 17-1-2024 om 00:58 schreef Kenneth:
> To me, those parallel lines look similar to the typical behavior of an image_map
> applied to a 1X1X1-unit box-- where the edge pixels 'wrap around the sides' (as
> an analogy only.) I haven't examined the code examples here or run them yet--
> I'm currently testing other things-- but I wonder if a small scaling factor
> needs to be used *somewhere*, to try and eliminate that effect. Something like
> scale <0.9999,0.9999,1>. Sorry if this proposal seems simplistic, but it's the
> first thing that popped into my head.
> 
Thanks for thinking along, Kenneth!

> As for the textures etc not following the rotation of the whole object, that's a
> strange mystery...perhaps a hidden problem with the 'slope' pattern itself?

Yes, that is really strange, isn't it?

-- 
Thomas

Post a reply to this message

Op 17-1-2024 om 12:43 schreef Bald Eagle:
> Nice work - that's looking really good!  :)
> 
> So now here's a question - while trying to hunt down an answer to WFP's default
> importance question, I stumbled upon a thread where clipka discusses
> pleochromism.
> 

Ha! Next fascinating problem! Excellent! :-)

-- 
Thomas

Post a reply to this message