Dear Colleagues,

     this is a question for povray programmers. I am experiencing an

increasing number of crashes of povray with the error message

"Floating exception" on DecAlpha machines running Linux or Digital Unix.

The scene and the image is very large and I assume that this is why I get

all the trouble: 250000 scene objects, 2400x2400 pixel -> 750 Mbyte.

It seems that it runs a bit better under Digital Unix than under Linux but

I wish someone would come up with a stable version of povray 3.0 because every

crash is extremely costly and it takes about 2 h for the parser to read

in the scene objects. Povray usually runs for about 1 - 2 h so I loose about

50 % cpu time pro crash.  To sort of explore the options and maybe even solve the

problem myself I tried to compile povray with any available c compiler (cc,gcc,c89)
and

a number of different optimization options ... but it was in vane.

Any ideas ? Is this a povray problem or a problem of the operating system ?

Any help is much appreciated.

   Lothar Esser

------------------------------------------------------------------
Dr. Lothar Esser
Howard Hughes Medical Institute
5323 Harry Hines Blvd.
Dallas Texas 75235-9050
E-mail : ess### [at] chopswmededu
------------------------------------------------------------------

Post a reply to this message

I have had the same problem under AlphaNT and Alpha Linux.  It seems to be
something with the Alpha being 64bit.  I ran into the problem whenever I hit
an object whose edge was running parallel to the scan line.  Run the scene
using adaptive antialiasing (Sampling_Method=2) and it should get by the
point of failure.  Note that this will add alot of time.  Runs using method
2 would take (for me anyway) 3 to 5 times as long as using method 1.

I think this should be looked into before Alpha starts to really take off
this year as a common platform.  It looks as though Samsung is going to
price the 21264 at the same cost at the upper PII's.  Which makes owning a
PII look silly.

Also, is there any plan to make POVRay cross platform with its GUI?  How
about switching to a standard graphical library that is supported on more
than x86 Windows.

Mark Arrasmith
arr### [at] mathtwsuedu
  From his AlphaNT 21164PC 533MHz.
  Note: these machines start at $1800 and kick the crap out of anything else
(other than an Alpha 21164).

Post a reply to this message

Mark Arrasmith (arr### [at] mathtwsuedu) wrote:
: Also, is there any plan to make POVRay cross platform with its GUI?

  As long as there is always a little command line version available!
  I don't want guis growing the file size where it's not necessary.

--
                                                              - Warp. -

Post a reply to this message

>: Also, is there any plan to make POVRay cross platform with its GUI?
>
>  As long as there is always a little command line version available!
>  I don't want guis growing the file size where it's not necessary.
>
>--
>                                                              - Warp. -

Yeah, I can always bolt on my own interface to the command line version.  It
just that I wish the GUI Win32 version would compile on Win32 machines, from
Cyrix to Alpha.  Which means no x86 specific stuff.

Heck, maybe I'll just rewrite all of POVRay in ISE Eiffel.  Or not.

mark

Post a reply to this message

Nieminen Mika wrote in message <6isnom$f7d$2@oz.aussie.org>...
>Mark Arrasmith (arr### [at] mathtwsuedu) wrote:
>: Also, is there any plan to make POVRay cross platform with its GUI?
>
>  As long as there is always a little command line version available!
>  I don't want guis growing the file size where it's not necessary.


IMHO, PovRay should be cut in two parts :

-  A highly portable PovRay Engine (PRE) :
When possible (most plateforms), it would be a DLL / Shared Library. On
others, static library.
It would enable easy and better integration with front-ends (shells,
modelers, texture editors, render farms, etc), for preview and final
rendering.

From version 3.0 code, at first look, it's seems not very hard work
(definition of officials APIs for calling PRE and setting callbacks for
handling POV_BANNER & Co, POV_DISPLAY_Xxxx, POV_SYSTEM).
In fact, I've already compile for personnal tests an unofficial PovRay
engine DLL for Win32...
A second look and the bad news is, today, PovRay 3.0 code isn't thread-safe
(many globals variables) !
Perhaps a welcomed next major version (4.0?) rewritten code will help this
particular point.

PRE development is obviously the POV-Team main focus, and should continue to
be.
An open (plugin-able) engine would be better...

- PovRay Shell(s), calling the PRE APIs :
An obvious and portable one (except for MacOS!?) is a little command line
shell. Any PovRay distribution should (and already) include this shell (even
if a GUI shell exist).
More sophisticated shells could be with GUI, like the Windows or MacOS
today's one.

With officials PRE APIs, more shells would be available than today. Most
plateform-specific, some cross plateform.
With same officials PRE APIs, more high front-ends could use PovRay.
Directly.

Just some suggestions for the future of PovRay developpment...

Thanks for reading.
And sorry for poor english...

Phil.

Post a reply to this message

>Yeah, I can always bolt on my own interface to the command line version.  It
>just that I wish the GUI Win32 version would compile on Win32 machines, from

As far as I am aware it should be able to. One of the reasons we went to a lot
of trouble to write the thing in C (and make the editor a optional loadable
DLL) was so it would be portable across Win32. I'm sure it won't compile out
of the box but it shouldn't be too hard.

>Cyrix to Alpha.  Which means no x86 specific stuff.

Can you please point me to the x86 specific stuff that you are referring to ?
Be sure to exclude any of the optional things like the editor and the ztimer
library ; they are not essential to building POVWIN.

Post a reply to this message

>-  A highly portable PovRay Engine (PRE) :
>When possible (most plateforms), it would be a DLL / Shared Library. On
>others, static library.
>It would enable easy and better integration with front-ends (shells,
>modelers, texture editors, render farms, etc), for preview and final
>rendering.
>


I'm starting work on an ActiveX version of PoV just for the purpose of
easy integration to front ends.  I think the Window's version of PoV is
bloated-  who wants to download a 4M rendering engine that should
be ~1M.  What should have been done was an ActiveX./DLL
version as you suggested, and if someone wants to add an editor, modeler,
everything but the kitchen sink, front end, then they can easily add the PoV
rendering engine by using the ActiveX control/DLL.

Is there much interest by other developers for this ActiveX control?
It would have a bunch of methods/properties that would allow
you to set the rendering options, fire off the rendering into your window,
then notify you that its done rendering.

I know I could use the GUI extensions already built into the Windows
version,
but its much nicer not to have PoV startup as a separate application.

    Jeff

Post a reply to this message

Philippe Houdoin <phi### [at] ouest-francefr> wrote in article
<6iuebt$hho$1@oz.aussie.org>...
> Nieminen Mika wrote in message <6isnom$f7d$2@oz.aussie.org>...
> >Mark Arrasmith (arr### [at] mathtwsuedu) wrote:
> >: Also, is there any plan to make POVRay cross platform with its GUI?
> >
> >  As long as there is always a little command line version available!
> >  I don't want guis growing the file size where it's not necessary.
> 
> 
> IMHO, PovRay should be cut in two parts :
> 
> -  A highly portable PovRay Engine (PRE) :
> When possible (most plateforms), it would be a DLL / Shared Library. On
> others, static library.
> - PovRay Shell(s), calling the PRE APIs :
> An obvious and portable one (except for MacOS!?) is a little command line
> shell. Any PovRay distribution should (and already) include this shell
(even
> if a GUI shell exist).
> More sophisticated shells could be with GUI, like the Windows or MacOS
> today's one.

	From what I've seen, I believe the Windows version of 3.1 will be like
this ! I can't confirm this, as I don't have CompuServe access, but, if
it's true, it's definitely a step in the right direction.

-- 
Scott Hill
Sco### [at] DDLinkscouk
Software Engineer (and all round nice guy)

"The best trick the devil ever pulled was convincing people he didn't
exist..."
								- Verbal Kint.

"the Internet is here so we can waste time talking about nothing in 
 particular when we should be working" - Marcus Hill.

Post a reply to this message

povray.org admin team wrote in message
<355306ea.39651135@news.povray.org>...
>Can you please point me to the x86 specific stuff that you are referring to
?
>Be sure to exclude any of the optional things like the editor and the
ztimer
>library ; they are not essential to building POVWIN.

Well now I have to look stupid here.  There was a discussion here at the
povray newsgroups about getting POVRay Win32 to compile under Alpha awhile
back.  My problem is that I am not speaking from my own experience.  (My
Visual C++ Risc Edition will not arrive until next week)

If I remember right the problem was with a dll or maybe several dll's that
were not available under the AlphaNT platform.  A Borland Delphi dll I
think.

Sorry if I was an ass about this.  I'll ask those that have actually tried
this to give a more complete answer.  And when my VC++ shows up I'll see
what the problems are firsthand.

Since you did mention the editor and ztimer I'll try to work around them.
You know building vim 5.0 as the editor would be kind of cool, with color
syntax and everything.

Mark Arrasmith
arr### [at] mathtwsuedu

Post a reply to this message

>Is there much interest by other developers for this ActiveX control?
>It would have a bunch of methods/properties that would allow
>you to set the rendering options, fire off the rendering into your window,
>then notify you that its done rendering.


I'm interested!!! Sound VERY cool.. Maybe set up Web support? So the people
can call it from a webpage, when they go to a site with a .POV file? =P

>I know I could use the GUI extensions already built into the Windows
>version,
>but its much nicer not to have PoV startup as a separate application.


I can DEFINATELY agree with that. It's quite hard, especially in VB5, to
monitor an external app like Povray, and see if it's finished.

>    Jeff


Twyst

Post a reply to this message