Rune wrote:

> The pattern is a bit like gradient and a bit like planar, but more powerful
> IMHO. The syntax would be like gradient, only with another keyword of
> course.
> 
> gradient2 <VECTOR>
> 
> ...or something like that. gradient2 y would from y=0 to y=1 return 0 to 1.
> But unlike regular gradient y it would stay at 1 at y>1 instead of
> repeating. At y<0 it would return 0, and that's where it's different from
> both gradient and planar. It increases in only the positive <VECTOR>
> direction, not both in the positive and negative direction.

It has already been done... but not in the official 3.1g
Please have a look about SHEET (or BAND ?) in some unofficial version.
It is exactly what it does.

The code of the functions was posted on the server.

Post a reply to this message

In article <3A599631.FFE03888@atosorigin.com>, Jerome Grimbert 
<jer### [at] atosorigincom> wrote:

> It has already been done... but not in the official 3.1g
> Please have a look about SHEET (or BAND ?) in some unofficial version.
> It is exactly what it does.

There are two patterns..."sheet" and "banded". The "sheet" pattern uses:

  value = EPoint[X]*TPat->Vals.Gradient[X]
        + EPoint[Y]*TPat->Vals.Gradient[Y]
        + EPoint[Z]*TPat->Vals.Gradient[Z];

  return(value>1.0 ? 1.0 : (value<0.0? 0.0:value));

which looks like what he wants. The "banded" pattern is the same as 
gradient, except it doesn't mirror around the origin, and the bands are 
always the same length.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

In article <3a58e89a@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> Sounds like a very good idea. I have some questions.
> I don't know the POV source but judging from the way some patterns 
> seem to work I suspect that many patterns in fact does exceed the 
> [0,1] range but there's some global function that applies the mod 
> function to all patterns before they are returned. Is this assumption 
> correct?

Yes. There is a point in Evaluate_TPat() immediately before the 
waveforms that does this, using the fmod() function:
  if (TPat->Frequency !=0.0)
  {
    value = fmod(value * TPat->Frequency + TPat->Phase, 1.00001);
  }


> And you are thinking of alternatives to this global "mod enforcement"?

Yes. Specifically, a "waveform_list {}" feature. The current ramp wave 
would simply be the default, and you could override it with whatever 
waveform you want. You could even apply multiple waveforms, one after 
the other...sort of like post_process filters for pattern waveforms.
This would require some changes to current patterns in order to be 
really useful...gradient would become a gradient from -infinity to 
+infinity, for example...but nothing should be noticeable from the 
user(except a possible speedup because of the lack of redundantly 
wrapping to the [0, 1] range).


> It sounds like a good idea. But exactly why does all patterns need to 
> be in the [0,1] range anyway? Why can't we allow any values in 
> patterns? To access those unlimited values you would simply allow all 
> values in color_maps too etc. I have never understood the reason for 
> this limitation.

It is just to make creating color_maps easier...and certain things are 
only possible when you know the maximum and minimum values of a range. 
It wasn't something they just threw in for no reason...imagine if every 
time you changed a pattern, you had to completely renumber the 
color_map...you would probably end up using a 0-1 color map and a 
separate multiplier value to fit it to each pattern.


> But back to the original topic. Say you made a "wave-type" that 
> clipped patterns at 0 and 1 instead of "mod"-ifying them. That solves 
> a third of my problem with the gradient pattern.

That is close to what I am thinking of, except I would overhaul the 
entire waveform code and allow you to specify min and max values for 
that waveform filter.


> Another third of the problem is that only the x, y, and z vector can 
> be used plus combination such as <1,0,1> or <1,1,1>. Other vectors 
> don't work. For example <2.5,0,0> is converted to <1,0,0> and 
> <0.1,0,3> is converted to <1,0,1>. Fixing this odd behaviour would 
> not break old scenes, but only add new functionality to the gradient 
> pattern. Could you do that too?

Hmm, I'd never noticed that limitation before...
It should be as simple as replacing these lines in gradient():
      temp = fabs(EPoint[i]);

      value += fmod(temp,1.0);
With this one line:
      value += fmod(fabs(TPat->Vals.Gradient[i]*EPoint[i]), 1.0);

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

> Rune wrote:
> > gradient2 y would from y=0 to y=1 return 0 to 1. But unlike
> > regular gradient y it would stay at 1 at y>1 instead of
> > repeating. At y<0 it would return 0.
>
> It has already been done... but not in the official 3.1g
> Please have a look about SHEET (or BAND ?) in some unofficial
> version. It is exactly what it does.

Thanks for the tip!

Glad others than me could see the usefulness of such a pattern! ;)

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

Rune <run### [at] inamecom> wrote:

> "J?r?me Grimbert" wrote:
>> Rune wrote:
>> > gradient2 y would from y=0 to y=1 return 0 to 1. But unlike
>> > regular gradient y it would stay at 1 at y>1 instead of
>> > repeating. At y<0 it would return 0.
>>
>> It has already been done... but not in the official 3.1g
>> Please have a look about SHEET (or BAND ?) in some unofficial
>> version. It is exactly what it does.

> Thanks for the tip!

> Glad others than me could see the usefulness of such a pattern! ;)

I've always wanted a pattern like that, although what I'd like is more of an
S curve.  Lots of mathematical formulae work for that, though.

Geoff

Post a reply to this message

Chris Huff wrote:

> In article <3a5880ae@news.povray.org>, "25ct" <25c### [at] lineonenet> wrote:
> >      My idea would be for someone to produce a code that 'finds' the
> > centre of these shapes in the render window, and then, by clicking
> > your mouse on the shape, and holding down, just move the shape to at
> > least where you want it to go, rather than taking 30 minutes to get
> > it there in the first place.
>
> What you are looking for is a modeller. POV-Ray is a renderer.

I've used programs like CorelDream3D, Bryce, etc., and they are a PITA as
far as this kind of operation.  My experience is that a little program that
tries to read your mind on these kinds of operations is more headache than
help.  In CD3D, you could describe the object in world or object
coordinates, move the object itself or its center of mass, and it was often
automatically converting the units back and forth without my permission,
especially in rotations.  I wouldn't stop you from trying programs like
Moray or a demo of say Rhino, but if you are trying to avoid all math you
might not be in luck. Furthermore, while I have immense respect for sPatch,
I guess I just "cannot draw with a mouse" and so I find mouse-grabbing
programs don't aid my artistic output that much. Furtherfurthermore, a
measure of my intelligence is that I never got off the ground with Moray and
wasn't ever able to really model much of anything with it.  Povlab OTOH
doesn't work.

In MegaPov, there are advanced functions like trace and min/max_extent that
I have found very helpful in figuring out exactly where a missing object is.
And if I may say so, even when modelling in povray, I've found that a little
more work and discipline up front can avoid "where is my object?" headaches
later--such as deciding up front that my blob character will have feet
bottoms at y=0 and head top at y=10.  Just firing away modelling based on
looks in current window makes for more headaches later.

Post a reply to this message

"Greg M. Johnson" <gre### [at] my-dejanewscom> wrote in message
news:3A5B091E.1F85F9FD@my-dejanews.com...

> And if I may say so, even when modelling in povray, I've found that a
little
> more work and discipline up front can avoid "where is my object?"
headaches
> later--such as deciding up front that my blob character will have feet

The white man speaks truth. My big mistake in early pov was to define, say,
a table at <10,0,15>, then define a candle-stick at <10,5,15>, then decide
that the candlestick was too small, scale it up and watch it disappear over
the horizon. Nowdays, all my objects and object components start with some
logical point at <0,0,0>.

Post a reply to this message

"Greg M. Johnson" wrote:
> Furthermore, while I have immense respect for sPatch, I guess
> I just "cannot draw with a mouse" and so I find mouse-grabbing
> programs don't aid my artistic output that much.

You're not the only one. I feel that I just can't use 3D programs with
GUI...

The positive way of thinking of it is: "Monitor and mouse works in two
dimensions only, but in my head I can visualise things in 3d"

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

> You're not the only one. I feel that I just can't use 3D programs with
> GUI...

I went through a Lightwave tutorial once... when I was done, I had a very
nice exploding planet and all, but I also had a headache.

> The positive way of thinking of it is: "Monitor and mouse works in two
> dimensions only, but in my head I can visualise things in 3d"

You feel like you just want to reach in there and grab the darn thing!

Post a reply to this message

"Greg M. Johnson" wrote:
> 
> I've used programs like CorelDream3D, Bryce, etc., and they are a
> PITA as far as this kind of operation.  My experience is that a
> little program that tries to read your mind on these kinds of
> operations is more headache than help.

Any program that tries to do your thinking for you is likely to be
more trouble than it's worth.  The more recent versions of MS Word
give me fits.

> Furthermore, while I have immense respect for sPatch, I guess I just
> cannot "draw with a mouse" and so I find mouse-grabbing programs
> don't aid my artistic output that much.

The chief flaw of many modellers I've seen is the tendency for all
editing to be done in planes parallel to the coordinate axes.  While
working on my modeller [1], I found that being able to interactively
rotate the view of the project makes it much easier to understand what
one is doing.

Regards,
John
--
[1] Not even half done, I'm afraid.  I had something halfway decent
put together last year, and then decided to add movable limbs and
subdivision surface support to the features.  This is not hard, but
designing an intuitive user interface is proving to be difficult...

Post a reply to this message