 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>Anton Sherwood wrote:
>>
>> crackle solid metric 0.9, 1.0, 1.1
>>
> Shouldn't metric be always an integer? metric 1 looks like what I would
>expect anyway...
There is no reason why metric must be an integer, though using values other
than 1 or 2 can slow down the rendering. Metric 1 looks like it's broken,
and in fact it is:
VSub(dv, TPat->Vals.Crackle.cv[i], tv);
if ( UseSquare ) {
sum = VSumSqr(dv);
if ( Offset ) sum += Offset*Offset;
}
else if ( UseUnity ) {
sum = dv[X] + dv[Y] + dv[Z];
if ( Offset ) sum += Offset;
}
else {
sum = pow( fabs( dv[X] ), Metric ) +
pow( fabs( dv[Y] ), Metric ) +
pow( fabs( dv[Z] ), Metric );
if ( Offset ) sum += pow( Offset, Metric );
}
Note that in the metric=1 case (UseUnity) it doesn't take the absolute
values of the components of dv, whereas in the default case it does. The
default case is the correct one. This same fix must be made in the case
of the three minimum distance calculations before the loop.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
>
> Note that in the metric=1 case (UseUnity) it doesn't take the absolute
> values of the components of dv, whereas in the default case it does. The
> default case is the correct one. This same fix must be made in the case
> of the three minimum distance calculations before the loop.
>
Point. I only looked at the image and didn't see anything amiss in the
metrics 1 case (I'm completely unable to say what the others should look
like anyway...)
--
* Doctor Jekyll had something * mailto:ber### [at] iname com
* to Hyde... * http://www.enst.fr/~jberger
*******************************
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
[code]
> Note that in the metric=1 case (UseUnity) it doesn't take the absolute
> values of the components of dv, whereas in the default case it does. The
> default case is the correct one. This same fix must be made in the case
> of the three minimum distance calculations before the loop.
okay, what file is this in?
--
Anton Sherwood -- br0### [at] p0b0xcom -- http://ogre.nu/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I only looked at the image and didn't see anything amiss in the
> metrics 1 case (I'm completely unable to say what the others
> should look like anyway...)
The point of the image was that cases 0.9 and 1.1 strongly resemble each
other while 1.0 looks nothing like them.
--
Anton Sherwood -- br0### [at] p0b0xcom -- http://ogre.nu/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 30 Sep 2000 11:33:37 -0700, Anton Sherwood wrote:
>Ron Parker wrote:
> [code]
>> Note that in the metric=1 case (UseUnity) it doesn't take the absolute
>> values of the components of dv, whereas in the default case it does. The
>> default case is the correct one. This same fix must be made in the case
>> of the three minimum distance calculations before the loop.
>
>okay, what file is this in?
pattern.c
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Proudly not helping RIAA and SDMI steal my rights --
http://www.eff.org/Misc/EFF/Newsletters/EFFector/HTML/effect13.08.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Anton Sherwood wrote:
>
> > I only looked at the image and didn't see anything amiss in the
> > metrics 1 case (I'm completely unable to say what the others
> > should look like anyway...)
>
> The point of the image was that cases 0.9 and 1.1 strongly resemble each
> other while 1.0 looks nothing like them.
>
Yes, but the case 1.0 looks exactly like I'd expect so if there is a
problem, it's likely in the others (but I don't think so, changing
metrics is not a continuous operation...)
--
* Doctor Jekyll had something * mailto:ber### [at] inamecom
* to Hyde... * http://www.enst.fr/~jberger
*******************************
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
