Nemesis - they're the same command line parameters I've been using on all my
projects, and everything else in the scene is rendering fine.  Also, it
occured to me I AM using a round_cylinder elsewhere in the code and it does
render fine on the linux. This is insane. (+W640 +H480 -D -UV +AM2 +A0.1
+J0.0)


Christoph - I dont know what else to describe. When I say "no errors" I mean
there's no error reported in the verbose output when it renders. Not even a
warning.  The only thing presenting itself is the lack of these specific
objects when rendered on linux, but they're fine on windows. I know it
doesnt make sense, thats why I'm cracking up. These objects are critical,
and I'm very short on time, and this is the screwiest mystery I've ever
encountered.

I dont know what else to explain.  I just thought maybe someone might know
of a difference between the code for the two platforms, like maybe in the
parser or something, that might give me some clue.

Post a reply to this message

space_cadet schrieb:
> 
> Christoph - I dont know what else to describe. When I say "no errors" I mean
> there's no error reported in the verbose output when it renders. Not even a
> warning.  The only thing presenting itself is the lack of these specific
> objects when rendered on linux, but they're fine on windows.

What is so difficult about:

- posting a minimal scene
- describing what happens when you try to render this scene
- describing what you think is wrong about this

And as said make sure you don't call Round_Cylinder with radius, 
rounding radius and length in a relation that is not supported (see my 
previous post).

-- Christoph

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote:
> space_cadet schrieb:
> >
> > Christoph - I dont know what else to describe. When I say "no errors" I mean
> > there's no error reported in the verbose output when it renders. Not even a
> > warning.  The only thing presenting itself is the lack of these specific
> > objects when rendered on linux, but they're fine on windows.
>
> What is so difficult about:
>
> - posting a minimal scene
> - describing what happens when you try to render this scene
> - describing what you think is wrong about this
>
> And as said make sure you don't call Round_Cylinder with radius,
> rounding radius and length in a relation that is not supported (see my
> previous post).
>
> -- Christoph

I dont understand. I posted the source code. I described in full what
happens when I render it. I'm out of ideas as to what might be wrong, thats
why I'm posting here. What else are you looking for?

Post a reply to this message

oops, my bad. In my frustration, I got a bit careless in my checking.  Using
a regular cylinder{} object DOES in fact work and is totally usable for my
project.  And I have NOT in fact used Round_Cylinder elsewhere in the code
successfully on linux (its another regular cylinder that I was thinking
of).

So the original problem stands, that Round_Cylinder and Round_Cylinder ONLY
is rendering fine in my file on windows, but the same file renders everying
BUT the round_cylinder on linux with no errors reported in verbose.

Since I can use cylinder and I need to move on, I'm putting this behind me,
and may revisit later. It is a stupifying situation and I'd like to get to
the bottom of it.

Thanks for any time and attention.

Post a reply to this message

"space_cadet" <poc### [at] grcnasagov> wrote in message 
news:web.45818628f0b8b2e8339b0050@news.povray.org...
> oops, my bad. In my frustration, I got a bit careless in my checking. 
> Using
> a regular cylinder{} object DOES in fact work and is totally usable for my
> project.  And I have NOT in fact used Round_Cylinder elsewhere in the code
> successfully on linux (its another regular cylinder that I was thinking
> of).
>
> So the original problem stands, that Round_Cylinder and Round_Cylinder 
> ONLY
> is rendering fine in my file on windows, but the same file renders 
> everying
> BUT the round_cylinder on linux with no errors reported in verbose.
>
> Since I can use cylinder and I need to move on, I'm putting this behind 
> me,
> and may revisit later. It is a stupifying situation and I'd like to get to
> the bottom of it.
>
> Thanks for any time and attention.
>

If a cylinder of the same size displays correctly, then you should be able 
to identify the cause of the problem by substituting the object definitions 
that will be generated by the macro directly into your SDL. Then you can 
comment out lines of code back until you're just left with the outer 
cylinder definition and work out which piece of the merge is causing your 
distress.

If I've done my arithmetic right then you should be able to replace:

Round_Cylinder(<0,0,0>, <1,0,0>, .005, .005, 1)

with:

merge {
   cylinder {<0,0,0>, <1,0,0>, 0}
   cylinder {<0.005,0,0>, <0.995,0,0>, .005}
   torus {0, .005 translate y*.005}
   torus {0, .005 translate y*.995}
}

and get the same result.
Notice that your parameter settings result in a cylinder of 0 radius and two 
spheres where the major radius of the torus is 0.

If you get down to just
   cylinder {<0.005,0,0>, <0.995,0,0>, .005}
and it still doesn't show, then adjust the settings till it matches 
precisely the cylinder you have that does show.

Hope this helps,
Regards,
Chris B.

Post a reply to this message

Thanks, Chris. Thats a great idea, and I'll investigate as soon as I can.

If I am able to identify a particular line of code thats the culprit, I'm
still left with why that code would respond differently on the different
platforms.

Just in case this is relevant, on linux I'm running povray 3.6.1 (g++ 3.4.1)

on windows povray 3.6.1c.icl8.win32

Just wondering if that "c.icl8.win32" would include any mods or bug fixes
that might be pertinent to this issue.

Post a reply to this message

"space_cadet" <poc### [at] grcnasagov> wrote in message 
news:web.4581a6c8f0b8b2e8339b0050@news.povray.org...
> Thanks, Chris. Thats a great idea, and I'll investigate as soon as I can.
>
> If I am able to identify a particular line of code thats the culprit, I'm
> still left with why that code would respond differently on the different
> platforms.
>

That's true, but if you isolate the cause it may be possible to create a 
simple workaround. For example, the simplest way to get what you're using 
the macro for is one cylinder and two spheres and they don't need to be 
merged (unless you want to put the camera inside), so it could be very 
simple to write a macro that circumvents the problem.

Regards,
Chris B.

Post a reply to this message

truly strange.  I've experienced the same problem with almost the same scene
as he provided:

#include "shapes.inc"
object{
        Round_Cylinder(-x, x, .005, .005, 1)

        pigment{ rgb 1 }
        finish{ ambient 0 diffuse .7 specular .7 reflection .7}

        translate z*2
    }

light_source { 4-8*z 1 }


But solution is pretty simple.
Substitute this:
        Round_Cylinder(-x, x, .005, .005, 1)
For this:
        Round_Cylinder(-x, x, .0051, .005, 1)

or any minimally increased value for Radius in relation to EdgeRadius.

It's bizarre because, if the radii are the same, you get a warning for the
camera being inside a non-hollow object, even though you translate it far
away: I translated even as far as z*50!

I'm using Ubuntu Breezy Badger, which is fairly up-to-date as far as stdlibs
go.  Could be a problem with the GNU arithmetic libs?

Post a reply to this message

"nemesis" <nam### [at] gmailcom> wrote:
> truly strange.  I've experienced the same problem with almost the same scene
> as he provided:

Booyah! I'm NOT crazy!! ;-)


Thanks for taking time to play with it.

Post a reply to this message

space_cadet wrote:
> Thanks, Chris. Thats a great idea, and I'll investigate as soon as I can.
> 
> If I am able to identify a particular line of code thats the culprit, I'm
> still left with why that code would respond differently on the different
> platforms.

It is perfectly normal that in special cases like this (zero diameter 
cylinder, torus with zero major radius) different compiles generate 
different results (mostly due to different math library 
implementations).  As said it is simply expected that the user takes 
care of using reasonable values in such places.

Note while you might suggest one compile handles such a case 'more 
correctly' than another one this usually is pure luck.

Christoph

-- 
POV-Ray tutorials, include files, Landscape of the week:
http://www.imagico.de/ (Last updated 15 Oct. 2006)
MegaPOV with mechanics simulation: http://megapov.inetart.net/

Post a reply to this message