Hi, all.

I've just created a pair of macros which will construct a brick texture
to wrap around a sphere or cylinder, keeping the bricks the same general
size (not stretched near the sphere equator nor squished near the
poles).  They were actually designed for spaceship hull plating, but
look just fine as bricks.

For sample image, basic information and zipfile download, go to

    http://www.gate.net/~shiprbk/raytrace/plates.html

I would appreciate any bug reports or suggestions for improvement.


-- 
Jeff Lee         shi### [at] gatenet         http://www.gate.net/~shipbrk/

Post a reply to this message

On Wed, 30 Jun 1999 19:30:48 GMT, Jeff Lee wrote:
>Hi, all.
>
>I've just created a pair of macros which will construct a brick texture
>to wrap around a sphere or cylinder, keeping the bricks the same general
>size (not stretched near the sphere equator nor squished near the
>poles).  They were actually designed for spaceship hull plating, but
>look just fine as bricks.
>
>For sample image, basic information and zipfile download, go to
>
>    http://www.gate.net/~shiprbk/raytrace/plates.html
>
>I would appreciate any bug reports or suggestions for improvement.

Or, if you really want to get there, 
    http://www.gate.net/~shipbrk/raytrace/plates.html

I note that you require unaltered distribution.  Is there a reason for 
this?  That's far more restrictive than even POVLegal, and a fair number
of people already chafe at its constraints.

I haven't succeeded in downloading your file, but you also note that 
there is a limit of 128 rows of bricks due to the internal 256-element 
limit on pigment maps.  Have you considered nesting pigment maps like so:

  pigment {
    gradient y
    pigment_map {
      [0.5 
        gradient y 
        pigment_map {
          [...the 1st map goes here...]
        }
      ]
      [0.5
        gradient y 
        pigment_map {
          [...the 2nd map goes here...]
        }
      ]
    }
  }

If you then put all values less than .5 in the first map, and all
values greater than .5 in the second map, you'll be able to use
up to 512 levels (assuming an even distribution of values, of 
course.)

With more divisions in the outer map, you can increase the limit
to 65,536 or so, at which point you could just add another outer 
map to raise the limit to 16,777,216 and so on.

Post a reply to this message

shi### [at] gatenet (Jeff Lee) wrote:

>     http://www.gate.net/~shiprbk/raytrace/plates.html

Whoops.  Can't even type my own username... It SHOULD be:

      http://www.gate.net/~shipbrk/raytrace/plates.html



-- 
Jeff Lee         shi### [at] gatenet         http://www.gate.net/~shipbrk/

Post a reply to this message

par### [at] fwicom (Ron Parker) wrote:
>
> I note that you require unaltered distribution.  Is there a reason for 
> this?

If someone wants to alter them, they're more than welcome to do so for
their own use.  If they think their improvements are worthy of
distributing, it would be nice if they would let *me* know about them,
so that I can include their ideas, give them credit, and not have a
bunch of possibly incompatible "unofficial" versions floating around.

Furthermore, since the concepts used within the macros are neither
unique nor novel, I have no problem if people want to write and
distribute their own macros based on the same algorithms, if mine do not
suffice for their purposes and they do not wish to make their
improvements known to me.

Besides, if the idea of distributing them unaltered is so unacceptable
that it outweighs any potential usefulness they might have, then nobody
has to use them in the first place.  No skin off *my* nose.


> That's far more restrictive than even POVLegal, and a fair number
> of people already chafe at its constraints.

POV-Ray is the POV Team's intellectual property, and they've put a LOT
of work into it.  They have a right to ask that people abide by their
wishes concerning distribution, incorporation of their code into other
packages, and so forth.  I certainly don't think they're being
unreasonable, but then again, I'm a computer programmer who has had code
used without permission -- or credit -- by others who didn't have the
decency to *ask*.

I also hope that this "fair number of people" doesn't include the ones
who are incensed that GeoCities seems to have decided to help itself to
its members' intellectual property...  That would certainly be ironic.


> I haven't succeeded in downloading your file,

Is the FTP server acting up again?  If so, I'll move it to my Web
directories and change the link to HTTP access.


> but you also note that 
> there is a limit of 128 rows of bricks due to the internal 256-element 
> limit on pigment maps.  Have you considered nesting pigment maps like so:

I have tried, based on your response to my question about that very
problem, but was unable to get it working.  The macros are... somewhat
ugly, unfortunately, and will require a complete rewrite in order to
make this method implementable.

Perhaps for version 2...


-- 
Jeff Lee         shi### [at] gatenet         http://www.gate.net/~shipbrk/

Post a reply to this message

On Wed, 30 Jun 1999 21:24:25 GMT, Jeff Lee wrote:
>If someone wants to alter them, they're more than welcome to do so for
>their own use.  If they think their improvements are worthy of
>distributing, it would be nice if they would let *me* know about them,
>so that I can include their ideas, give them credit, and not have a
>bunch of possibly incompatible "unofficial" versions floating around.

That's fair.  Just wondered what your reasoning was is all.

>> That's far more restrictive than even POVLegal, and a fair number
>> of people already chafe at its constraints.
>
>POV-Ray is the POV Team's intellectual property, and they've put a LOT
>of work into it.  They have a right to ask that people abide by their
>wishes concerning distribution, incorporation of their code into other
>packages, and so forth.  I certainly don't think they're being
>unreasonable, but then again, I'm a computer programmer who has had code
>used without permission -- or credit -- by others who didn't have the
>decency to *ask*.

Whoa!  Didn't mean to incite a flamewar here.  For reasons that should
become obvious, I'm one of the people who says that whatever the POV-Team
wants to do with their code is their business, as I've said all along.
I do wish some parts of POVLegal would die a quiet death, as I don't see
them contributing in any significant way to keeping POV and its code free, 
but that's an entirely privately held opinion and I defer to the Team's
decision makers to have the final word on that.

I just wondered what made you decide on the license you did rather than 
using something like the GPL or BSD licenses or, as I unwittingly did, 
completely omitting any licensing language.  As you may have guessed, 
I'm also a computer programmer, but I've never been taken advantage of
to my knowledge.  But then, I tend to release anything I don't get paid
for either into the public domain or under some license or other (such
as POVLegal, which applies to the superpatch and my other POV-derived
works.)

>I also hope that this "fair number of people" doesn't include the ones
>who are incensed that GeoCities seems to have decided to help itself to
>its members' intellectual property...  That would certainly be ironic.

It's one thing to feel that the terms on a given piece of IP are too
strict for the accomplishment of the stated goals (and again I stress that
that is my private opinion, not anyone else's) and it's another thing 
entirely to ascribe so little value to the idea of IP that you wouldn't be 
incensed by what Yahoo! has done (unwittingly, I think, in that the TOS in
question has always applied to the older Yahoo! services like chat and 
member profiles.  They probably didn't even realize the impact of such a 
thing on a site like GeoCities.)  I think it's not a bit hypocritical to
hold both the view that Yahoo! screwed up and the view that POVLegal isn't
as lean as it could be.  I'm certainly not advocating stealing IP, as 
Yahoo! seems to be doing, and I have no problem working within the 
constraints of whatever licensing scheme the POV-Team wants to construct,
but at the same time I wish the constraints were a tad looser.

>> I haven't succeeded in downloading your file,
>
>Is the FTP server acting up again?  If so, I'll move it to my Web
>directories and change the link to HTTP access.

I did finally get it.  It was just slow. Obviously a lot of people wanted 
it all at once. :)  It really is quite nicely done.

>I have tried, based on your response to my question about that very
>problem, but was unable to get it working.  The macros are... somewhat
>ugly, unfortunately, and will require a complete rewrite in order to
>make this method implementable.

Hm... maybe if I get bored with all my other POV projects I'll see if I
can mess with yours. :)  I read through it and it looks quite readable, 
by comparison with e.g. my torus spline macro.

Post a reply to this message

par### [at] fwicom (Ron Parker) wrote:
> On Wed, 30 Jun 1999 21:24:25 GMT, Jeff Lee wrote:
>
>> I certainly don't think they're being
>> unreasonable, but then again, I'm a computer programmer who has had code
>> used without permission -- or credit -- by others who didn't have the
>> decency to *ask*.
>
> Whoa!  Didn't mean to incite a flamewar here.

Sorry about that, I guess I'm a bit touchy on that subject.  Once
burned, twice disgruntled, or something like that.


> I just wondered what made you decide on the license you did rather than 
> using something like the GPL or BSD licenses or, as I unwittingly did, 
> completely omitting any licensing language.

Fair enough.


> I'm certainly not advocating stealing IP, as 
> Yahoo! seems to be doing, and I have no problem working within the 
> constraints of whatever licensing scheme the POV-Team wants to construct,
> but at the same time I wish the constraints were a tad looser.

Which bits do you feel are too restrictive?  I read the whole thing when
I started using it, and didn't find anything I thought was unreasonable.


>> Is the FTP server acting up again?  If so, I'll move it to my Web
>> directories and change the link to HTTP access.
>
> I did finally get it.  It was just slow. Obviously a lot of people wanted 
> it all at once. :)  It really is quite nicely done.

Thanks.


>> I have tried, based on your response to my question about that very
>> problem, but was unable to get it working.  The macros are... somewhat
>> ugly, unfortunately, and will require a complete rewrite in order to
>> make this method implementable.
>
> Hm... maybe if I get bored with all my other POV projects I'll see if I
> can mess with yours. :)  I read through it and it looks quite readable, 
> by comparison with e.g. my torus spline macro.

Well, that's a bit of a relief, then.  I usually try to make my stuff
readable (since I've had to work on other people's legacy code), but on
this one I was just concentrating on getting it to work.


-- 
Jeff Lee         shi### [at] gatenet         http://www.gate.net/~shipbrk/

Post a reply to this message

On Wed, 30 Jun 1999 23:09:41 GMT, shi### [at] gatenet (Jeff Lee) wrote:

>Which bits do you feel are too restrictive?  I read the whole thing when
>I started using it, and didn't find anything I thought was unreasonable.

Nothing unreasonable, just a couple things that seemed a little
excessive for the stated goal of keeping the code free.  The usual
suspect when you're talking to me is the ban on new interfaces, but
I'm also wary of the "these specific people may not do anything with
POV" clause, not because I'm against it but because I feel like it
might be opening a legal can of worms that's best left sealed.  

When you're talking to other people, the usual complaint is that the
code can't be used in other free projects, as it could be if it were
under the GPL or a similar license.

Since my biggest complaint was that I couldn't add all the
functionality I wanted to, I'm not really the one to ask.  And, I'm
probably going to regret bringing this whole thing up again. :)

Post a reply to this message

Jeff Lee wrote:

> par### [at] fwicom (Ron Parker) wrote:

> > I note that you require unaltered distribution.  Is there a reason for
> > this?

> If someone wants to alter them, they're more than welcome to do so for
> their own use.  If they think their improvements are worthy of
> distributing, it would be nice if they would let *me* know about them,
> so that I can include their ideas, give them credit, and not have a
> bunch of possibly incompatible "unofficial" versions floating around.

	In the "good old days" one of my disclaimers read to the effect,
"If you change this, put your own name on it. I have enough
problems dealing with my own mistakes." 

-- 
<blink>-------please--don't-----------------</blink>

http://www.giwersworld.org/artii/
http://www.giwersworld.org/artiii/

Finally up on 99/06/22 updated 06/30

Post a reply to this message

Attachments:
Download 'us-ascii' (1 KB)

On Wed, 30 Jun 1999 19:30:48 GMT, Jeff Lee wrote:
>Hi, all.
>
>I've just created a pair of macros which will construct a brick texture
>to wrap around a sphere or cylinder

[...]

>I would appreciate any bug reports or suggestions for improvement.

I've succeeded in eliminating the limit on the number of rows in a
spherical texture.  Jeff, if you're interested in having the changes, 
email me.

Post a reply to this message

Jeff Lee wrote in message <377a727c@news.povray.org>...
>shi### [at] gatenet (Jeff Lee) wrote:
>
>>     http://www.gate.net/~shiprbk/raytrace/plates.html
>
>Whoops.  Can't even type my own username... It SHOULD be:
>
>      http://www.gate.net/~shipbrk/raytrace/plates.html


I am unable to download your macro.  When I tried, Netscape popped up a
dialog box stating that a username and password were required.

Mark

Post a reply to this message