![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 3/25/2023 2:21 AM, Thomas de Groot wrote:
> Op 24-3-2023 om 22:36 schreef Josh English:
>> Yup. uv_mapping needs to be triggered on the texture and the object to
>> work. I played with it a bit more and managed to get the torus onto
>> each triangle that has the Test texture
>>
> I have bit of a problem with this:
>> #declare TorusRadius = sqrt(3)/6;
>> #declare Torus = torus {TorusRadius-Line, Line rotate x*90 translate
>> <0.5, TorusRadius-Line, 0>}
>>
> and I got a better fit with:
>
> #declare Line = 0.02;
> #declare Torus = torus {sqrt(3)/8, Line rotate x*90 translate <0.5,
> sqrt(3)/6, 0>}
>
> ...which is less elegant but which fits better the triangle centres
> somehow. I don't know how to translate this to your solution though.
>
It looks good to me. I didn't get a satisfactory "kiss the edge of the
triangle" look but I didn't do a lot of heavy math. Even the sqrt(3)/6
was a guess that just seemed to work well enough.
I made a few more adjustments to the code
#declare TorusRadius = sqrt(3)/6;
#declare Torus = torus {TorusRadius-Line, Line rotate x*90 translate
<0.5, TorusRadius, 0>}
And then I experimented with stretching some triangles, which would
happen in a mesh and got the expected distortions of the radius. I'm not
sure that's even possible to fix without customizing ellipses for each
triangle, so probably at that point a cylinder and not a torus creates a
better marker.
Post a reply to this message
Attachments:
Download 'uv_test.png' (27 KB)
Preview of image 'uv_test.png'
![uv_test.png](/povray.general/attachment/%3C641f3861%241%40news.povray.org%3E/uv_test.png?ttop=441664&preview=1)
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Thomas de Groot <tho### [at] degroot org> wrote:
> > And you definitely are catching on to where I'm going with that. ;)
> >
> Eagerly awaiting further developments...
So, after I figured out that the basic mechanism of the uv_mapping was going to
work out the way that I wanted, I figured I'd give some Japanese kumiko a try.
I converted some of:
https://github.com/BorisTheBrave/grids/blob/main/src/updown_tri.py
But perhaps have to figure out how to mimic a python yield directive in SDL -
maybe TOK has some ideas on that.
Then I worked out a bunch of ternary diagram macros and made sure that was
working out ok.
Then I started making some of the patterns, hit a few snags, then tried to get
partial lines running from a vertex across the triangle, and --- that's when I
lost my mind. I'll take tensor calculus any day over the simple stuff :D
I found this:
https://medium.com/@deltaplotware/ternary-diagrams-in-chemistry-6c608ae5137b
showing the constant composition lines, but I haven't worked it out yet.
Anyway, here's the development doodles to give you an idea of where this is
going, once it gets organized. I think the end goal is to be able to scan an
image and use the color data to put the appropriate kind of pattern in the
triangular pixel. Kind of like an ASCII art, eval_pigment, halftone thing - but
made of 100,000 little pieces of wood.
Enjoy.
- BW
Post a reply to this message
Attachments:
Download 'ternaryplot.png' (92 KB)
Preview of image 'ternaryplot.png'
![ternaryplot.png](/povray.general/attachment/%3Cweb.641f76beeebe912c1f9dae3025979125%40news.povray.org%3E/ternaryplot.png?ttop=441664&preview=1)
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Op 25-3-2023 om 19:07 schreef Josh English:
> It looks good to me. I didn't get a satisfactory "kiss the edge of the
> triangle" look but I didn't do a lot of heavy math. Even the sqrt(3)/6
> was a guess that just seemed to work well enough.
>
Yes, I also "guessed" the best fits to what I wanted to achieve ;-)
> I made a few more adjustments to the code
>
> #declare TorusRadius = sqrt(3)/6;
> #declare Torus = torus {TorusRadius-Line, Line rotate x*90 translate
> <0.5, TorusRadius, 0>}
>
> And then I experimented with stretching some triangles, which would
> happen in a mesh and got the expected distortions of the radius. I'm not
> sure that's even possible to fix without customizing ellipses for each
> triangle, so probably at that point a cylinder and not a torus creates a
> better marker.
I did that too; gives insight at least about how it all works. I never
paid much attention to uv_vectors, as most of the uv_mapping I am doing
is through modellers and with image_maps. However, this is a good
learning exercise.
--
Thomas
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Op 25-3-2023 om 23:33 schreef Bald Eagle:
> So, after I figured out that the basic mechanism of the uv_mapping was going to
> work out the way that I wanted, I figured I'd give some Japanese kumiko a try.
>
> I converted some of:
> https://github.com/BorisTheBrave/grids/blob/main/src/updown_tri.py
> But perhaps have to figure out how to mimic a python yield directive in SDL -
> maybe TOK has some ideas on that.
> Then I worked out a bunch of ternary diagram macros and made sure that was
> working out ok.
>
> Then I started making some of the patterns, hit a few snags, then tried to get
> partial lines running from a vertex across the triangle, and --- that's when I
> lost my mind. I'll take tensor calculus any day over the simple stuff :D
> I found this:
> https://medium.com/@deltaplotware/ternary-diagrams-in-chemistry-6c608ae5137b
> showing the constant composition lines, but I haven't worked it out yet.
>
> Anyway, here's the development doodles to give you an idea of where this is
> going, once it gets organized. I think the end goal is to be able to scan an
> image and use the color data to put the appropriate kind of pattern in the
> triangular pixel. Kind of like an ASCII art, eval_pigment, halftone thing - but
> made of 100,000 little pieces of wood.
>
Phew... I need to ponder this a bit more but this leads to very
interesting potential possibilities. I have experience with eval_pigment
to do this kind of thing, but this is just a bit smarter. Well done so far.
--
Thomas
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Thomas de Groot <tho### [at] degroot org> wrote:
> Phew... I need to ponder this a bit more but this leads to very
> interesting potential possibilities. I have experience with eval_pigment
> to do this kind of thing, but this is just a bit smarter. Well done so far.
Well, what we're doing is instead of just using the underlying pigment value
returned by eval_pigment directly, we're using that color or grayscale value to
choose a shape that represents that "brightness".
You can do it with text (ASCII art), I've done it with the halftone project
using holes of different sizes (I _cannot_ find the thread), and here I'm going
to try it with the patterns filling the triangles.
I got some sleep, got my head screwed on straight, figured out the
constant-ratio lines, and that got me a bit further along on pattern
development.
Now I'm again a little stuck on lines perpendicular to edges, and that also
hinted that maybe somewhere in the code I have a few things switched around. I
have to check once get all the code written, and it could just be a matter of
swapping #cases of a #switch block.
Anyhow, I have most of what I wanted to do completed. I also noticed the
overall impression of the assembled patterns is very different depending on
color choice. I'll likely have to finish working through the triangle grid code
to get that all properly converted so that I can rotate triangles, select the
triangles that fill a rectangle, etc.
All in all, not bad for a weekend of coding.
Post a reply to this message
Attachments:
Download 'ternaryplot.png' (483 KB)
Preview of image 'ternaryplot.png'
![ternaryplot.png](/povray.general/attachment/%3Cweb.64209154eebe912c1f9dae3025979125%40news.povray.org%3E/ternaryplot.png?ttop=441664&preview=1)
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 3/26/2023 11:39 AM, Bald Eagle wrote:
> Thomas de Groot <tho### [at] degroot org> wrote:
>
>> Phew... I need to ponder this a bit more but this leads to very
>> interesting potential possibilities. I have experience with eval_pigment
>> to do this kind of thing, but this is just a bit smarter. Well done so far.
>
> Well, what we're doing is instead of just using the underlying pigment value
> returned by eval_pigment directly, we're using that color or grayscale value to
> choose a shape that represents that "brightness".
>
> You can do it with text (ASCII art), I've done it with the halftone project
> using holes of different sizes (I _cannot_ find the thread), and here I'm going
> to try it with the patterns filling the triangles.
>
> I got some sleep, got my head screwed on straight, figured out the
> constant-ratio lines, and that got me a bit further along on pattern
> development.
>
> Now I'm again a little stuck on lines perpendicular to edges, and that also
> hinted that maybe somewhere in the code I have a few things switched around. I
> have to check once get all the code written, and it could just be a matter of
> swapping #cases of a #switch block.
>
> Anyhow, I have most of what I wanted to do completed. I also noticed the
> overall impression of the assembled patterns is very different depending on
> color choice. I'll likely have to finish working through the triangle grid code
> to get that all properly converted so that I can rotate triangles, select the
> triangles that fill a rectangle, etc.
>
> All in all, not bad for a weekend of coding.
That is very cool. You shouldn't need to worry about rotating the
triangles, just reorder the UV mapping coordinates for the few patterns
you have where it will make a difference.
--Josh
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Bald Eagle" <cre### [at] netscape net> wrote:
> All in all, not bad for a weekend of coding.
And here you go, Internet. A cat.
Post a reply to this message
Attachments:
Download 'kumikophoto.png' (1604 KB)
Preview of image 'kumikophoto.png'
![kumikophoto.png](/povray.general/attachment/%3Cweb.6420d7b5eebe912c1f9dae3025979125%40news.povray.org%3E/kumikophoto.png?ttop=441664&preview=1)
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 3/26/23 19:39, Bald Eagle wrote:
> "Bald Eagle" <cre### [at] netscape net> wrote:
>
>> All in all, not bad for a weekend of coding.
>
> And here you go, Internet. A cat.
>
:-)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Bald Eagle" <cre### [at] netscape net> wrote:
> But perhaps have to figure out how to mimic a python yield directive in SDL -
> maybe TOK has some ideas on that.
I got the yield worked out, now I am trying to properly decipher these
expressions:
//#local ta = (a - int(da <= 0) - fa) / da if da != 0 else float('inf');
//#local ida = abs(1 / da) if da != 0 else float('inf');
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Le 2023-03-28 à 14:06, Bald Eagle a écrit :
> "Bald Eagle" <cre### [at] netscape net> wrote:
>
>> But perhaps have to figure out how to mimic a python yield directive in SDL -
>> maybe TOK has some ideas on that.
>
> I got the yield worked out, now I am trying to properly decipher these
> expressions:
>
> //#local ta = (a - int(da <= 0) - fa) / da if da != 0 else float('inf');
int(da<=0) evaluate to 1 whenever da is zero or negative, and 0 if da is
positive. The «int» does nothing as the <= operation returns ONLY 1 or 0.
As the else invert the result of the test,
«if da != 0 else» is the same as «if da = 0» of «if !da».
//#local ta = (a - da <=0 - fa) / da if !da float ('inf');
>
> //#local ida = abs(1 / da) if da != 0 else float('inf');
//#local ida = abs(1 / da) if !da float('inf');
>
>
>
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |