 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I am not completely sure about what I am talking here but at least
what I propose in the following lines removed black spots on the isosurface
of my Mars renderings. (These spots only occur when the light comes under
a flat angle and when no_shadow is NOT set.)
In isosurf.cpp, the recursive part of the root finder reads:
---------------------------------------
static int IsoSurface_Function_Find_Root_R(ISOSURFACE* ISOSRF, ISO_Pair*
EP1,
ISO_Pair* EP2, DBL dt, DBL t21, DBL len, bool in_shadow_test)
{
DBL temp;
temp = fabs((EP2->f - EP1->f) * len);
if(ISOSRF->gradient < temp) // update "max gradient found"
ISOSRF->gradient = temp;
if((ISOSRF->eval == true) && [...]
[...]
if(t21 < ISOSRF->accuracy)
{
#if ORIGINAL
if(EP2->f < 0)
{
ISOSRF->tl = EP2->t;
return true;
}
else return false;
#else /* !ORIGINAL /
if(EP2->f <= 0 && EP1->f >= 0.0)
{
ISOSRF->tl = 0.5*(EP2->t+EP1->t);
return true;
}
else if(EP2->f < 0) // This will normally not be reached (ww).
{
ISOSRF->tl = EP2->t;
return true;
}
else return false;
#endif
}
[...]
---------------------------------------
The idea is that in case we cross the isosurface threshold and
one point is outside (EP1) while the other one is inside (EP2),
then the average of the two depth values should give a better
estimate for the actual intersection than merely using EP2.
(This works because the root solver continuously halfes the interval
the root is in.)
The "else if" stmt is the original code which is probably not reached
normally because in case both points are inside the isosurface, we
should not be here.
At least that is what I think from reading the code because unfortunately
it completely lacks descriptive comments.
Maybe somebody with a clue could comment on that.
Wolfgang
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Why not just
if(EP2->f < 0)
{
if(EP1->f > 0.0)
ISOSRF->tl = 0.5*(EP2->t+EP1->t);
else
ISOSRF->tl = EP2->t;
return true;
}
else return false;
???
Thorsten
PS: You should really consider using a sane tab width with something like
four spaces per tab, and not unreadable eight spaces per tab!
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trf de
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
> Why not just
>
> if(EP2->f < 0)
> {
> if(EP1->f > 0.0)
> ISOSRF->tl = 0.5*(EP2->t+EP1->t);
> else
> ISOSRF->tl = EP2->t;
> return true;
> }
> else return false;
>
> ???
>
> Thorsten
>
>
> PS: You should really consider using a sane tab width with something like
> four spaces per tab, and not unreadable eight spaces per tab!
>
I AM using a tab with of 4 but when I copy-and-paste into the
news reader the tabs get expanded to 8. I actually thought, the
news reader would transmit the \t characters but it looks like it
is converting them to 8 spaces before sending.
But no problem, I'll do better the next time.
BTW, after posting, I wondered myself why I was using 0.5*(EP2->t+EP1->t),
i.e. the average. We could even do a linear interpolation which should be
much better: We know the f and the t values!
Since you (Thorsten) are the guy who ported the Suzuki code to povray:
What do you think?
Wolfgang
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> PS: You should really consider using a sane tab width with something like
> four spaces per tab, and not unreadable eight spaces per tab!
IMO you should never use tabs when writing some code, as they
make it very unreadable for most people (who usually don't bother setting
the tab width -- if ever possible). I'd say tabs can be used safely IF
your editor converts them automatically to a small amount of spaces
(ideally 2 -- my personal choice -- to 4).
- NC
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wolfgang Wieser wrote:
> Thorsten Froehlich wrote:
>
>> Why not just
>>
>> if(EP2->f < 0)
>> {
>> if(EP1->f > 0.0)
>> ISOSRF->tl = 0.5*(EP2->t+EP1->t);
>> else
>> ISOSRF->tl = EP2->t;
>> return true;
>> }
>> else return false;
>>
> [...]
> i.e. the average. We could even do a linear interpolation which should be
> much better: We know the f and the t values!
>
I now suggest the following: This does a linar interpolation and I verified
using my current mars rendering that it removes even more (_all_!)
spurious black dots.
---------------------------------------
if(EP2->f<=0.0)
{
if(EP1->f >= 0.0)
{
double df = EP1->f-EP2->f;
// Need to calc (EP1->t*EP2->f - EP2->t*EP1->f) / df
// in a numerically stable way.
if(df>1e-14)
ISOSRF->tl = EP2->t + t21*EP2->f/df;
else
ISOSRF->tl = 0.5*(EP2->t+EP1->t);
}
else
ISOSRF->tl = EP2->t;
return true;
}
return false;
---------------------------------------
The 1e-14 is just there to prevent a division by zero in
case the isosurface has zero gradient (along the ray) at the
intersection. Maybe we can even use smaller values.
Wolfgang
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <403f443a$1@news.povray.org> , Nicolas Calimet
<pov### [at] freefr> wrote:
>> PS: You should really consider using a sane tab width with something like
>> four spaces per tab, and not unreadable eight spaces per tab!
>
> IMO you should never use tabs when writing some code, as they
> make it very unreadable for most people (who usually don't bother setting
> the tab width -- if ever possible). I'd say tabs can be used safely IF
> your editor converts them automatically to a small amount of spaces
> (ideally 2 -- my personal choice -- to 4).
Urgh, no, this is the 21st century! Old junk DOS and ancient Unix editors
that do not support tabs properly should deleted, not used! There is
progress, and spaces only cause problems when writing code, while tabs make
everything evry easy and fast to write and change. One simply has to agree
on one tab size for shared code. Of course, on a particular kind of
platform(s) this seems to be impossible. Yet, on those platform(s)
everybody still writes C K&R style, so... ;-)
Actually, on Windows the practical standard is the one default of M$
Developer Studio (4 iirc) and on Mac OS the universal standard is 4 as well.
So if the myriad editors on that other "platform" cannot agree on a common
format, who cares? ;-)
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <403f5224@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>
wrote:
> The 1e-14 is just there to prevent a division by zero in
> case the isosurface has zero gradient (along the ray) at the
> intersection. Maybe we can even use smaller values.
You really don't want an unnecessary division is such heavily used code.
Doesn't "len" provide you with all you need?
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <403f13ad@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>
wrote:
> Since you (Thorsten) are the guy who ported the Suzuki code to povray:
> What do you think?
I haven't looked at that code for over a year...
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wolfgang Wieser wrote:
> I am not completely sure about what I am talking here but at least
> what I propose in the following lines removed black spots on the isosurface
> of my Mars renderings. (These spots only occur when the light comes under
> a flat angle and when no_shadow is NOT set.)
>
> [...]
What you describe seems to be specific to shadow rays, does your
suggested change also influence the appearance of the actual surface
(i.e. camera rays). You could try rendering with a fairly large accuracy
value for testing.
I agree with Thorsten that the interpolation will probably cause
slowdown without much advantage (and i don't think the simple version
you posted will work correctly in all situations). Also note we are
talking about differences of a maximum of accuracy*0.5.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 11 Jan. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Calimet wrote:
>> PS: You should really consider using a sane tab width with something like
>> four spaces per tab, and not unreadable eight spaces per tab!
>
> IMO you should never use tabs when writing some code, as they
> make it very unreadable for most people (who usually don't bother setting
> the tab width -- if ever possible). I'd say tabs can be used safely IF
> your editor converts them automatically to a small amount of spaces
> (ideally 2 -- my personal choice -- to 4).
>
I completely disagree. You _should_ always use tabs for indention because
it saves a lot of bytes on your hd and because anybody can adjust the
indention depth on his own editor to fit his needs.
I, for example, am used to tab width 4 and I don't like code written
with space-2 indention (too small indention).
I once read that this indention issue was actually the reason for tabs
being invented.
One could argue that today disk space is cheap but see the following
example:
Linux-2.6.3 kernel code would be 24 Mb (!!) larger if people used
4 spaces instead of one tab. That is nearly 15% more just for eye candy.
And that would enlarge the .tgz archive by 770 kb (37.9 -> 38.7 Mb) which
would take me 3 minutes longer for the download (my 56k modem has
4.4k/sec average).
The proper way to do intention is to use tabs.
Wolfgang
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
