Marty Schrader wrote:
> Heh, heh. It's amazing that somebody can apologize for how screwed up 
> something is and still make it sound as if it's your fault for not 
> reading the FAQ or whatever. Hey, I'm not gonna whine too loudly. As 
> long as I can find the data I'm golden.

Those of us who know how to manipulate POV into something useful have 
been working with it for a long time. We are insanely dedicated to 
learning something we love doing.

If you want easy answers, you must look into your own mind. Since I've 
been using POV for quite a while now, those 'easy' answers are there for 
quick retrieval, in my own mind.

If you want a simpler way to do things, spend some cash on a program 
which makes it *really* easy.

Sam

Post a reply to this message

Marty Schrader wrote:

> For instance, the book mentions 
> strlen in talking about other string functions, but strlen itself isn't 
> available.

You're reading the Help file, right?  Click the "Index" tab.  Type 
"strlen" in the box.  Son of a gun, there it is.

> This would be very helpful in figuring out how to position 
> text without a lot of trial and error.

Actually, unless you're using a fixed-width font, you probably want 
min_extent and max_extent for that.

> Heavy accent on the error.

Practice makes perfect.

--Sherry Shaw


-- 
#macro T(E,N)sphere{x,.4rotate z*E*60translate y*N pigment{wrinkles scale
.3}finish{ambient 1}}#end#local I=0;#while(I<5)T(I,1)T(1-I,-1)#local I=I+
1;#end camera{location-5*z}plane{z,37 pigment{granite color_map{[.7rgb 0]
[1rgb 1]}}finish{ambient 2}}//                                   TenMoons

Post a reply to this message

Marty Schrader <mar### [at] parsecsystemsinccom> wrote:
> What you are telling me is that I need to create a complex 3D object and 
> manipulate it all over the place in order to paint 2D text. I gotta take a 3D 
> object and slice it off with an implied intersection to make a 2D pattern, which 
> I can then use to...Oy!

  No. I already gave you the solution in my other post (using the object
pattern). Perhaps you didn't read it? It's here:

http://tag.povray.org/povQandT/languageQandT.html#cylindricalrepeat

> By the way, strlen() returns a float? I have only been doing this C stuff for 25 
> years or so, but a float?!?

  POV-Ray doesn't have integers. All numerical values are floats. Hence
strlen() returns a float (even though the value of this float will always
be an integer).

> And in the last 32 years I can't recall coming 
> across any language spec where the builtins were index by their return type as 
> opposed to the operational group to which they belonged.

  Well, the POV-Ray documentation classifies the functions by their
return value type. It's a simple way of classifying them.

> And the length should be a character count instead of some 
> graphic index, eh?

  strlen() returns the character count.

-- 
                                                          - Warp

Post a reply to this message

M_a_r_c wrote:

> 47113368$1@news.povray.org...
>> Marty Schrader wrote:
>>> The book references you gave me don't point to anything. My POV for
>>> Windows (3.6.1) help file goes up to 3.4.9, but you mention sections
>>> 3.4.11 and 12. The online help is even worse, since Chapter 3 is the
>>> reference in the help file, but it's about windows in the online docs.
>> The first number denotes a "book" not a "chapter". Since there are three
>> platform specific "books", but the online help cannot have three "books"
>> with the same number (yet it makes the most sense to have platform docs
>> first), the order is different, the actual chapter numbers are identical 
>> though.
>>
>> Thorsten, POV-Team
> 
> I wonder how many dried frog pills were swallowed to keep that cool ;-)

LOL, eventually we should replace the first number with a unique letter (or
drop it altogether), then the complexity will go away :-)

	Thorsten

Post a reply to this message

Samuel Benge <stb### [at] THIShotmailcom> wrote:
> Marty Schrader wrote:
> > This subject has been beaten to death on this group, but to no
> > satisfactory conclusion.
>
> Here you go, Marty:
>

Hey Samuel can you tell me why I loose part of the first few characters?
see code below

Leef_me




camera {
//        orthographic
        location <0,0,-10.5> look_at <0,0,0>
}


light_source { <-10,-7,-40> color rgb 1}

light_source { <1,0,-1.5> color rgb 1}


// Create an infinite sphere around scene and allow any pigment on it
sky_sphere {
  pigment {
    gradient y
    color_map { [0.0 color rgb <0.7,0.7,1.0>] [1.0 color blue 0.5] }
  }
}


// using text as a pigment on a plane, original code was in response to text
on a cylinder

//From: Samuel Benge
//Subject: Re: Simple 2D text on a cylinder's surface
//Date: 12 Oct 2007 06:39:40


// begin code
#declare my_text=
text{
  ttf"arialbd.ttf"
  "Test"
  1,0
//    translate<1.5,0,0>

}

//**********************************************
//
//      Why is part of the first character or two lost?
//
//**********************************************


// flat circular FINITE (no CSG) shape, center hole cutout is optional
disc {
  <0, 0, 0>  // center position
  z,         // normal vector
  5.0,       // outer radius
  //0.2        // optional hole radius

       pigment{
   pigment_pattern{
    object{my_text 0,1}
//    translate<1.5,0,0>
   }

  }

}

Post a reply to this message

Leef_me wrote:
> Hey Samuel can you tell me why I loose part of the first few characters?
> see code below
> 
> Leef_me

Yes, you are experiencing that old problematic artifact known as 
coincident surfaces. The front of the text object occupies the exact 
same space as the surface of the disc. Since the text object is 1 unit 
deep, change it to this:

#declare my_text=
text{
  ttf"arialbd.ttf"
  "Test"
  1,0
  translate -z/2
}

Doing that will allow the text object to intersect the disc correctly, 
thus displaying all of the text.

Sam

Post a reply to this message

Samuel Benge <stb### [at] THIShotmailcom> wrote:
> Leef_me wrote:
> > Hey Samuel can you tell me why I loose part of the first few characters?
> > see code below
> >
> > Leef_me
>
> Yes, you are experiencing that old problematic artifact known as
> coincident surfaces. The front of the text object occupies the exact
> same space as the surface of the disc. Since the text object is 1 unit
> deep, change it to this:
>
> #declare my_text=
> text{
>   ttf"arialbd.ttf"
>   "Test"
>   1,0
>   translate -z/2
> }
>
> Doing that will allow the text object to intersect the disc correctly,
> thus displaying all of the text.
>
> Sam

That does indeed <solved> the problem. And in understand the concept of
coincident surfaces. I failed to try translating the text in that axis.
I have experienced coincident surfaces as a random pixelation between the
two surfaces.

What I don't understand and what really through me was that it wasn't the
whole string. Just the top left at the start of the string was cut off at
an angle.

Thanks for the solution, now I start to comprehend the code.

Leef_me

Post a reply to this message

Leef_me wrote:
> That does indeed <solved> the problem. And in understand the concept of
> coincident surfaces. I failed to try translating the text in that axis.
> I have experienced coincident surfaces as a random pixelation between the
> two surfaces.
> 
> What I don't understand and what really through me was that it wasn't the
> whole string. Just the top left at the start of the string was cut off at
> an angle.

Yeah, you would expect the same random pixelation to occur, not the 
strange angled cut. It seems to be due to how POV handles object 
pigments. I'm getting the same effect with every flat object I try.

> Thanks for the solution, now I start to comprehend the code.

You're welcome. It's nice to see somebody passing through a difficult 
problem :)

If you *really* want to make sure it never happens again, you can make 
the object pigment infinitely long in the z-axis by changing your object 
pigment like so:

pigment_pattern{
  object{my_text 0,1}
  translate<1.5,0,0>
  warp{planar}
}

As long as you made the first 'translate' in the text object's 
definition, this should work just fine.

Sam

Post a reply to this message

Samuel Benge <stb### [at] THIShotmailcom> wrote:
> Leef_me wrote:
> > That does indeed <solved> the problem. And in understand the concept of


> If you *really* want to make sure it never happens again, you can make
> the object pigment infinitely long in the z-axis by changing your object
> pigment like so:
>
> pigment_pattern{
>   object{my_text 0,1}
>   translate<1.5,0,0>
>   warp{planar}
> }
>
> As long as you made the first 'translate' in the text object's
> definition, this should work just fine.
>
> Sam

Ok, that works as advertised. But I stumbled upon a new wrinkle.

I want to apply the 2D text to a flat object: disc, plane, sheet of paper,
or im my case a mesh.
(I'm looking the the scroll object at
                http://lib.povray.org/searchcollection/index.php     }

I've even succeeded in getting the text to run cross-wise or along the
length of the scroll. No code to share yey, it is very rough. Problem is
that the text 'bleeds through' and is visible from both sides of the
object.

Is there some way to apply a pigment to the 2D text and a different pigment
to the surrounding area including the opposite side, or maybe even a 3rd
pigment to the opposite side alone?

Leef_me

Post a reply to this message

Leef_me wrote:
> Ok, that works as advertised. But I stumbled upon a new wrinkle.
> 
> I want to apply the 2D text to a flat object: disc, plane, sheet of paper,
> or im my case a mesh.
> (I'm looking the the scroll object at
>                 http://lib.povray.org/searchcollection/index.php     }
> 
> I've even succeeded in getting the text to run cross-wise or along the
> length of the scroll.

Good work!

> No code to share yey, it is very rough. Problem is
> that the text 'bleeds through' and is visible from both sides of the
> object.
> 
> Is there some way to apply a pigment to the 2D text and a different pigment
> to the surrounding area including the opposite side, or maybe even a 3rd
> pigment to the opposite side alone?
> 
> Leef_me

Not having used the scroll object, I cannot say for certain if this will 
work with it. You may want to try interior_texture. Since objects in POV 
have two sides (inside, outside), there is a provision for texturing 
both sides separately.

Try something like this:

object{ my_object
  texture{
   pigment{ my_text_pigment }
  }
  interior_texture{
   pigment{ no_text_pigment }
  }
}

Sam

Post a reply to this message