Xplo Eristotle <xpl### [at] infomagicnet> wrote:
> Yes! Argh! God forbid I should use MegaPOV, which probably reuses 99% of 
> the official code. Quick, get the burning splints! 9_9;

  It's not about you using MegaPov. It's about you posting an example
code which does not work in POV-Ray without the user needing to edit it.
(And there wasn't even any reason for using that #version directive at all
in the first place.)

> Bite me, Warp. I wanted to know if this was a bug, and if not, why not.. 
> not to get a critique on my coding style. You wanted a scene, you got a 
> scene. Copy, paste, render, nod your head and tell me WTF is going on.

  The idea of a "minimal" scene is that it should be short, and not only
in the number of keywords it uses. Naturally it should be clear and easy
to read.
  A minimal scene means that you should remove everything that is not
necessary in order to show the phenomenon you are talking about. Also
things that are absolutely necessary for the scene to be rendable, but
not pertinent to the phenomenon per se should take as less space as possible
so that they don't confuse the person who is looking at your code.
  The person viewing your code should be able to concentrate on the core
code which causes the phenomenon. Making secondary definitions (such as
camera and light source) take tens of lines is only unnecessary clutter
and does not help this task. If the problem is not related to cameras or
light sources, they could be simple one-liners. The larger your code is
because of unneeded definitions, linebreaks and whitespace, the harder
it will be for the person looking at your code to find the problem.

  "I code in this way and you should accept that" is not the correct attitude.
Of course you can code in whichever way you want and keep your scenes that
way, but when you are posting a small example scene for others to view,
you should make their task as easy as possible.
  The more work you do in order to make other's work easier, the better.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Warp wrote:
> 
>   It's not about you using MegaPov. It's about you posting an example
> code which does not work in POV-Ray without the user needing to edit it.

I'm sorry. Leaving out the top line in a block of text when making a 
selection must require more dexterity than I would have imagined.

>   The idea of a "minimal" scene is that it should be short, and not only
> in the number of keywords it uses. Naturally it should be clear and easy
> to read.

And as we all know, whitespace exists to make code harder to read.

>   "I code in this way and you should accept that" is not the correct attitude.

The hell it isn't. My code's not unreadable.

> Of course you can code in whichever way you want and keep your scenes that
> way, but when you are posting a small example scene for others to view,
> you should make their task as easy as possible.
>   The more work you do in order to make other's work easier, the better.

I guess copy and paste is too hard for you, Warp. I can only hope that 
someone who can demonstrate that they've mastered these most basic of 
text operations is willing to help explain this seeming bug.

Good lord, man. I just wanted an answer, not a fucking editorial about 
how incredibly petty and lazy you can be. Next time I find some 
anomalous behavior in POV-Ray I'll just keep it to myself.

-Xplo

Post a reply to this message

The method of calculating the normal vector from the scalar
field may not be precise. Averaging these vectors would leave
a small residue or error. This is purely a guess based on the
existence of accuracy keyword for normals.


_____________
Kari Kivisalo

Post a reply to this message

Kari Kivisalo wrote:
> The method of calculating the normal vector from the scalar
> field may not be precise. Averaging these vectors would leave
> a small residue or error. This is purely a guess based on the
> existence of accuracy keyword for normals.

Thank you, Kari.

I'm not sure I'd call the results of the averaging a "small residue", 
though. There are some fairly deep bumps and pockmarks; it looks a 
little like the surface of a wooden baseball bat that's been used to hit 
rocks and pieces of metal junk.. like the dents normal, but messier.

I'll post a pic in p.b.i., since the usually-reasonable Warp seems to 
think that my code is a nightmare. 9_9

-Xplo

Post a reply to this message

In article <3e62268d@news.povray.org>,
 Xplo Eristotle <xpl### [at] infomagicnet> wrote:

> Yes! Argh! God forbid I should use MegaPOV, which probably reuses 99% of 
> the official code. Quick, get the burning splints! 9_9;

That doesn't mean the normal code is exactly the same. It would only 
take a very minor change to introduce a bug in MegaPOV. Besides, your 
scene does not require MegaPOV as far as I can see...you should have 
tested it in the official version and left that line out.

You included lots of other irrelevant stuff...#default, global_settings, 
etc. The idea of a minimal scene is that it includes only what is 
necessary. By breaking it down to the bare minimum, you not only keep 
the message short, but ensure that the problem is at least in the area 
you thought it was.

About the indentation issue, it is easier to copy and paste if the code 
is "compacted", and your indentation style is just the opposite, it 
can't get much longer or more spread out. It wasn't the real problem, 
though.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Xplo Eristotle <xpl### [at] infomagicnet> wrote:
> I'm sorry. Leaving out the top line in a block of text when making a 
> selection must require more dexterity than I would have imagined.

  Well, that's exactly what I'm talking about. You are cluttering your
scene with obsolete, unneeded definitions and assuming that the people
who want to look at your code will see the trouble to remove them because
you didn't want to do it yourself.

> And as we all know, whitespace exists to make code harder to read.

  When they clutter the scene, making secondary features of it to stand
out more than necessary, then yes, they make it harder to read.
  Did you even read what I said? The idea is that you should make the scene
minimal and help people concentrating on the *relevant* part of the code.
Making secondary, non-relevant parts of the code to exceedingly stand out
by making them to take lots of space does not help this task.

> The hell it isn't. My code's not unreadable.

  Where did I say that your code is unreadable?
  I said that you should *edit* your code before posting it. You should edit
it in such way that people don't need to edit it themselves if they want to
look at it. You should edit it in such way that the relevant part of the
code stands out and irrelevant secondary definitions don't.

> I guess copy and paste is too hard for you, Warp. I can only hope that 
> someone who can demonstrate that they've mastered these most basic of 
> text operations is willing to help explain this seeming bug.

> Good lord, man. I just wanted an answer, not a fucking editorial about 
> how incredibly petty and lazy you can be. Next time I find some 
> anomalous behavior in POV-Ray I'll just keep it to myself.

  Why do you keep talking about copying and pasting?

  And you are still showing the wrong attitude: You are expecting others
to edit your code and to interpret which parts are relevant and which aren't.
  That was exactly my point: You should see the trouble yourself, not
expect others to do it for you. It's not as bad as it could be (like those
who post a code thoushands of lines long and expect people to find one
buggy line in it), but IMHO you still showed an attitude which is not the
best possible.
  If you want answers, the correct attitude is not "here's some code I
quickly put together with a patched version and if you don't understand it
or can't edit it to work, then just fuck off".

  I did not criticize your coding style. I did not criticize your indentation
scheme. I did not criticize your choise of patched POV-Ray. I did not claim
that your example is not readable. So please stop claiming I did.
  I simply said that it's polite to see the trouble *yourself* in making
the scene as easy to use as possible, not expecting other people to do it
for you.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Warp wrote:
 >
>   And you are still showing the wrong attitude: You are expecting others
> to edit your code and to interpret which parts are relevant and which aren't.

No, I'm not.

I gave you the relevant piece of code in the first place, as well as a 
description of exactly what I was doing, and what the problem was. I 
don't think I could have been more clear. You and others complained 
about having to set up a test scene which might be different from mine, 
and realizing that this was a valid objection, I cut down the scene that 
had the problem to a viable test scene, and posted that.

It requires no editing, unless you wish to take out the version line 
(which is easily done, and obvious), or the global settings, which I 
seriously doubt are causing the "bug", and would not prevent the scene 
from rendering anyway. You wanted something that could be rendered with 
no thought or effort on your part, and I delivered.

>   I simply said that it's polite to see the trouble *yourself* in making
> the scene as easy to use as possible, not expecting other people to do it
> for you.

The only thing I "expect" anyone to do is to tell me whether it's a bug 
when two opposite normals are averaged together and produce a third, 
clearly visible normal instead of cancelling each other out, and if not, 
why not. The only reason I provided the code in the first place was so 
you could see exactly what I'm doing, and thereby confirm that the 
problem really exists and it's not just some incredibly stupid oversight 
on my part.

If you can't be bothered to try to help, then DON'T REPLY. Waste your 
free time on something else and let someone else take care of it. But 
don't sit here and lecture me over such trivial shit.

Of the four people who have replied to this thread (not counting me), 
only one has even TRIED to offer some useful explanation for my finding. 
So, again, thank you Kari for trying to help. The rest of you ought to 
be ashamed of yourselves.

-Xplo

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3e61f64d@news.povray.org...
> Xplo Eristotle <xpl### [at] infomagicnet> wrote:
> > #version unofficial MegaPov 1.0;
>
>   Argh!
>
>   And why all the unneeded whitespace bloating the code?
>   How about this:

      Warp, I have to agree with xplo, his reposted code was fine in
any pov laymans' terms - I cut and pasted it and got the desired
render - no problem, it was simple.

    I really don't see the problem with it, he did what was asked, and
as a user on this server, it was adequate for me, and that's sayin'
somethin'!

      ~Steve~


>
> --
> #macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N
color_map{[0rgb x]
> [1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end
M(-3<1.206434.28623>70,7)M(
> -1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// 
- Warp -

Post a reply to this message

Xplo Eristotle <xpl### [at] infomagicnet> wrote:
> If you can't be bothered to try to help, then DON'T REPLY.

  Do you really think you will get wholehearted help with that attitude?

> The rest of you ought to be ashamed of yourselves.

  Why?
  When I ask you to post a short, minimized and clean scene which shows
the phenomenon you are talking about, and then I explain myself what I
mean by minimal, you start insulting me.
  You still refuse to understand (or admit you understand) what I'm talking
about, but instead you keep making more or less direct insinuations about
me being stupid.
  I said that if you want help from people, it's good and polite to see
some trouble in making it the easiest possible for the people to study
your code and not expect people editing and understanding your code.
I also said that if you want help from people, you shouldn't start
depreciating their intelligence and insulting them. Your response to this
is basically "if you don't want to do it, fuck off".
  And lastly, when I show you how I think the code is at its minimum and
most clear shape, you don't even bother to comment it, why it's good/bad
and whether I, in your opinion, am right or wrong about it. (Instead you
start attacking me.)

  So why is it me who should be ashamed of myself?
  It wasn't me who started insulting and name-calling.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

St. <dot### [at] dotcom> wrote:
>       Warp, I have to agree with xplo, his reposted code was fine in
> any pov laymans' terms - I cut and pasted it and got the desired
> render - no problem, it was simple.

  It's not the code which is specially problematic. His attitude about my
comments is what made me lose my temper. He basically called me stupid.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message