 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
> well. So if the myriad editors on that other "platform" cannot agree on a
> common format, who cares? ;-)
>
And which other platform are you talking about?
Even "good old" unix VI (and ViM, too, of course) can set the tab size:
:set tabstop=4
:set shiftwidth=4
Wolfgang
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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 understand these arguments.
> I once read that this indention issue was actually the reason for tabs
> being invented.
I don't think so :-)
Tabs were invented for "tabulation", meaning aligning text columns
whatever the length (provided short enough) of their content.
As a matter of fact it can also be used for indentation.
> 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).
Well, that's 3 minutes over 2 hours and half... a raw 2% more.
(you'd better get some DSL model ;-) )
Okay, I knew I should not answer Thorsten's notice about tabs,
but what I mean is that you don't always use an editor to look through
the files in a package. Personally I don't know how to make 'more' or
'less' change the tab width. Maybe I'll learn something today.
Anyway this is also a never-ending fight about how a source
code should or should not look like. I choose to use two spaces instead
of a tab (and those will both compress very well anyway) and to break
long lines before the 80th caracter. Therefore I can look at my code
even on a non-X term.
Now, go on with your own style -- that doesn't matter much as
long as the program compiles and works as intended !
- NC
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <403f5c62@news.povray.org> , Wolfgang Wieser <wwi### [at] gmx de>
wrote:
>> well. So if the myriad editors on that other "platform" cannot agree on a
>> common format, who cares? ;-)
>
> And which other platform are you talking about?
>
> Even "good old" unix VI (and ViM, too, of course) can set the tab size:
> :set tabstop=4
> :set shiftwidth=4
Yes, there are vi, then there are the vi clones and improvements. Then
there is this editor that is its own operating system (you know which one I
am talking about), there are improved versions of it. Then there is my
favorite pico, and then there is the myriad editors I did not mention. I am
sure there are plenty that have hard-coded tabs. In conclusion, for
compatibility (the holly cow) many argue to use spaces. And I agree with
you that I don't see why spaces offer anything.
Anyway, as was already said in this thread, that doesn't matter much as
long as the program compiles and works as indented. ;-)
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> and works as indented. ;-)
:-D
- NC
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
> 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.
>
Well, in iso code there is no difference between viewing and shadow rays.
The in_shadow_test flag is never actually used except for some cache
which is handeled at a higher level and should not matter here.
What I describe seems to be specific to rays which come in a _very_
flat angle over the surface. And for these Mars renderings, the
shadow rays come really flat on the shadow side of hills.
> I agree with Thorsten that the interpolation will probably cause
> slowdown without much advantage
>
I am not sure about that. Because the gain in accuracy is considerably.
The original code will track the ray until its position is known to
be within "surface +/- accuracy". But with the modification I propose,
we gain significantly in accuracy because we can linarly interpolate the
"exact" location of the surface.
> (and i don't think the simple version
> you posted will work correctly in all situations).
>
You don't _think_ ...
Okay, I am not completely sure, too.
Actually,
--------------------------
if(EP2->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.
ISOSRF->tl = (df>1e-14) ?
EP2->t + t21*EP2->f/df :
0.5*(EP2->t+EP1->t);
return true;
}
return false;
--------------------------
should work as well (and does for my scenes). All the other conditions
are just to work around conditions which I am not sure about.
> Also note we are
> talking about differences of a maximum of accuracy*0.5.
>
So what?
Please see the following web page for a comparison:
http://www.cip.physik.uni-muenchen.de/~wwieser/tmp/poviso.html
Wolfgang
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Calimet wrote:
> Well, that's 3 minutes over 2 hours and half... a raw 2% more.
> (you'd better get some DSL model ;-) )
>
I get the other one for free :) So I won't change.
> the files in a package. Personally I don't know how to make 'more' or
> 'less' change the tab width.
>
Use
less -x4 file
Or better, use
export LESS="-x4"
(in bash style) in your profile. (I am using LESS="-M -i -S -x4" or so.)
> Maybe I'll learn something today.
>
:)
> Anyway this is also a never-ending fight about how a source
> code should or should not look like. I choose to use two spaces instead
> of a tab (and those will both compress very well anyway)
>
I am using one tab per level and have tab size 4 as you already know.
> and to break long lines before the 80th caracter.
>
Me too. Because it is dangerous if one cannot see what gets clipped away
on the right and uneasy to navigate when the lines are folded.
> Now, go on with your own style -- that doesn't matter much as
> long as the program compiles and works as intended !
>
Be careful. Code at www.ioccc.org also "works as intended" but
I never want to read such code :p
Wolfgang
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Use
> less -x4 file
> Or better, use
> export LESS="-x4"
> (in bash style) in your profile. (I am using LESS="-M -i -S -x4" or so.)
Geeeee I already knew for a long time (but never did it) that I'd
better switch from 'more' to 'less'. This tab stuff, among several others,
is a good reason for.
<mode switch on>
>>Maybe I'll learn something today.
> :)
Cool, I didn't loose my day then.
Was worth answering Thorsten afterall... ;-)
- NC
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
For those who did not read my last reply till the end:
Here is a comparison:
http://www.cip.physik.uni-muenchen.de/~wwieser/tmp/poviso.html
Sorry, I just notized that I mistyped the time (now corrected).
It is:
Original code: 47.77 sec
Patched code: 47.89 sec
Difference: 0.25%
Hence, it can be neglected.
The reason is that this computation is only done one for each intersection
and thus not in the innermost loop.
Wolfgang
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
