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

Philippe Houdoin <phi### [at] ouest-francefr> wrote:

> Perhaps a welcomed next major version (4.0?) rewritten code will help this
> particular point.

Another small problem is that (I read somewhere) povray version 4.0 will
be written in C++ which makes it a little bit more difficult to make
sharedlibraries of it on some plattforms. The reason for this is that
there is no widely addopted standard for how the name mangling should
be performed. Ie my MrC compiler and my Codewarrior compiler creates
different symbols (for the linker) for the same function. I would expect
this to be a problem also on other plattforms. Am I right?
I know that this is easy to overcome (Mix C and C++), but in a portable
way?

> An obvious and portable one (except for MacOS!?) is a little command line
> shell. 

You can make shell tools for the Mac too. Either for a real shell like
MPW (which many Mac developers use) or use a simple library
to simulate a shell in your program. (Ie creates a simple window and 
routes stdio,stdout and stderr to it without a single line of program
code).

/ Mathias Broxvall

Post a reply to this message

>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.

The DLL you are referring to is the Editor. It is not essential to the programs
operation.

Post a reply to this message

>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.

Get your facts right. Most of that 4m is docs and misc files. PVENGINE itself
is 1.4m total. Your claim that the 'rendering engine' is 4m is misleading and
could put people off using POVWIN if they haven't already tried it.

>What should have been done was an ActiveX./DLL

'Should' by your standards perhaps. Active X didn't exist at the time (as you
should well know) and we won't use a DLL because it allows POV-Ray's renderer
to be too easily subverted by leechware.

Really, if you want a DLL-based renderer, why don't you simply write your own ?

Post a reply to this message

Ok.  I'll try to get povwin to compile without the editor and ztimer
library.  Is there anything else I should look for?  And, any hints on
replacements?

Mark

povray.org admin team wrote in message
<35543cdd.25997502@news.povray.org>...
>>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.
>
>The DLL you are referring to is the Editor. It is not essential to the
programs
>operation.

Post a reply to this message

"Mark Arrasmith" <arr### [at] worldnetattnet> wrote:

>Ok.  I'll try to get povwin to compile without the editor and ztimer
>library.  Is there anything else I should look for?  And, any hints on
>replacements?

You don't need ztimer unless you want to do scene profiling. There's not
likely to be a replacement for the editor that will be easy to integrate.

Post a reply to this message

povray.org admin team wrote in message
<35553d06.26038110@news.povray.org>...
>>What should have been done was an ActiveX./DLL
>
>'Should' by your standards perhaps. Active X didn't exist at the time (as
you
>should well know) and we won't use a DLL because it allows POV-Ray's
renderer
>to be too easily subverted by leechware.
>
>Really, if you want a DLL-based renderer, why don't you simply write your
own ?

I've same feelings about ActiveX than you : not portable.
But shared libraries or at least static ones, exists on every plateforms /
compilers. And highly portable at source level.

Why a "DLL would allows POV-Ray's renderer to be too easily subverted by
leechware" ?

A library version of PovRay, shared or not, still could display legal
informations at STARTUP_POVRAY() and/or FINISH_POVRAY().
From User's point of view (UPOV?), he would see a POV-Ray startup screen
just after clicking on "Render now" button of his application. And then the
preview / final window on these application displaying result.
Exactly like today with Moray for Windows, Breeze Designer, Calimax or
Texture Magic...
But from these applications developers, a better "technically" integration
of POV-Ray renderer could be made, with callbacks for preview and final
rendering, rendering messages, pre and post traitment of output, in place of
pooling image output file and log files...

Okay, we could write our own DLL-based POV-Ray renderer. I actually trying
to do this for Win32.
But I want this DLL-based version to be thread-safe. Because of globals
variables and some others code's stuffs, I've to rewrite many modules.
And what a pain to do this, again, for future versions !

But perhaps I miss something about "subverted by leechware" ?

Phil.

Post a reply to this message

>But perhaps I miss something about "subverted by leechware" ?

You'd have to go back a few years, and be aware of some of the history of v2.0.
It's not really worth digging that up now ; all I'll say is that experience
with v2 heavily influenced a v3 decision we made to not make it too easy to
integrate with.

POV-Ray for Windows was originally intended to be just what was suggested - two
parts, a rendering engine and a front-end. The rendering engine was to be
written in portable C. This is why, even to this day, POV-Ray for Windows has
the name 'PVENGINE.EXE' and has most of its UI written in C (apart from the
editor). It was really intended to only be a very simple rendering engine that
was called from another application. We didn't really want to have a UI in it.

Additionally, (history again), it was originally written under Win32s (Windows
3.1) which didn't have threads. When '95 came alone, we added some Win32
support, but it still has a lot of its heritage from the Win32s days.

So, what we have today is the result of a number of compromises, since Win 3.1
was still a very viable platform at the time, plus a deliberate decision made
by the team as a whole (not just one person) to limit the ways that an external
program can use our renderer.

There is work afoot on a new version of POVWIN which will be split up (a team
member alluded to this a few weeks ago in an IRC chat with Twyst) but I can say
at this time that, again, the rendering portion will not be a DLL or ActiveX
control. Comms will be via TCP/IP (using a well-known port number already
allocated to POV-Ray by the IANA). It will not support Windows 3.1x. It will
support distributed network rendering. There is no date set. It may not even be
this year. Please don't bug us about it.

Again, however, we shall be taking steps to prevent subversion of our software
by unscrupulous developers who want a free ride. (Yes, such persons exist, like
it or not). This may make it difficult for others who do respect our software,
but that, as they say, is life. Please respect our wishes in this respect by
not hassling us over it.

Post a reply to this message

povray.org admin team <new### [at] povrayorg> wrote in article
<3555b828.55938845@news.povray.org>...

I've started using POV with the 3.0 versionn, so thanks you for development
history. 
Compromise is another name for (software development?) life.

> There is work afoot on a new version of POVWIN which will be split up (a
team
> member alluded to this a few weeks ago in an IRC chat with Twyst) but I
can say
> at this time that, again, the rendering portion will not be a DLL or
ActiveX
> control. Comms will be via TCP/IP (using a well-known port number already
> allocated to POV-Ray by the IANA). It will not support Windows 3.1x. It
will
> support distributed network rendering. There is no date set. It may not
even be
> this year. Please don't bug us about it.

Great. Going directly to Client-Server architecture is better than a just
modular (DLL & Co...) version.
I can totally wait for a such official client-server version ! 
Even for years...

Phil.

Post a reply to this message

Mathias Broxvall <mbr### [at] swipnetseNOSPAM> wrote in article
<1d8### [at] dialup150-2-39swipnetse>...
> Philippe Houdoin <phi### [at] ouest-francefr> wrote:
> 
> > Perhaps a welcomed next major version (4.0?) rewritten code will help
this
> > particular point.
> 
> Another small problem is that (I read somewhere) povray version 4.0 will
> be written in C++ which makes it a little bit more difficult to make
> sharedlibraries of it on some plattforms. The reason for this is that
> there is no widely addopted standard for how the name mangling should
> be performed. Ie my MrC compiler and my Codewarrior compiler creates
> different symbols (for the linker) for the same function. I would expect
> this to be a problem also on other plattforms. Am I right?
> I know that this is easy to overcome (Mix C and C++), but in a portable
> way?
> 

	Yeah, it easy, you just write the public interfaces in C, rather than C++,
then name mangling doesn't matter as all the mangled names are kept within
the library.

-- 
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

>       Yeah, it easy, you just write the public interfaces in C, rather than C++,
> then name mangling doesn't matter as all the mangled names are kept within
> the library.

Great! Sorry if this question isn't realy about programming povray:

Are there a standard for it? I have seen the following in some
of my system headers, is it the same on other platform to?

extern "C" {
  ...
  /* All my great C prototypes here */
  ...
}

Post a reply to this message

On Fri, 8 May 1998 08:50:21 -0600, "Jeff Hauswirth" <jha### [at] csnnet>
wrote:

>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 appreciate your enthusiastic desire to improve POV-Ray however what
you propose is a violation of POVLEGAL.DOC -- the general license
under which everyone is permitted to recompile and/or distribute
POV-Ray.  Specifically we state that you cannot link our code into
other applications.  This includes not only compile-time linkage but
run-time linkage as well.  Therefore turning POV-Ray into a DLL or
ActiveX package is not allowed because it links our engine into your
code.  Further, the license prohibits anything which obscures the fact
that the user is running our freeware renderer.  Creating a DLL makes
it much harder to distinguish which part is our renderer and which
part is the 3rd party product.  Unsuspecting users will pay for
shareware or commercial front-ends thinking they are buying the whole
package when in fact they're getting a simple menu system.

Even if your intent is NOT to unscrupulously make money off of a cheap
front-end and a POV-Ray DLL, it opens the door to anybody to do it.

Although we feel POVLEGAL.DOC already prohibits such practices, we
will probably add language to future versions of our license to make
sure people understand our intent.

As you know, our current POV-Ray for Windows allows the user to
substitute any editor for ours.  It provides GUI-Extension hooks and
operating system shell-outs so that POV-Ray can control other external
stand-alone tasks.  If you have suggestions on how we can improve the
interface without inviting rip-off front-ends, we'll be happy to
consider them.
	Chris Young, POV-Team coordinator.

Post a reply to this message

>
>Although we feel POVLEGAL.DOC already prohibits such practices, we
>will probably add language to future versions of our license to make
>sure people understand our intent.
>


This is a good idea.  The way I read the legal doc was that you
were not allowed to use the source except in custom/unsupported
builds of PoV.  I figured if I built a stand-alone ActiveX control and
then distributed the code/control with the necessary legal notices
it was OK.

POVLEGAL.DOC should be updated as you said to include static/
run-time linking of PoV.

I will then change my way of implementing this connection- for fun, but
maybe for release which just runs a minimized process that I communicate
with.  Much like the Windows version does, but without the GUI frontend-
just a Win32 console based app that can display the necessary legal
info on startup.  I know the future version will have this capability, but
I'm just doing it to learn.

    Jeff

Post a reply to this message

Mathias Broxvall <mbr### [at] swipnetseNOSPAM> wrote in article
<1d8### [at] dialup122-3-36swipnetse>...
> 
> >       Yeah, it easy, you just write the public interfaces in C, rather
than C++,
> > then name mangling doesn't matter as all the mangled names are kept
within
> > the library.
> 
> Great! Sorry if this question isn't realy about programming povray:
> 
> Are there a standard for it? I have seen the following in some
> of my system headers, is it the same on other platform to?
> 
> extern "C" {
>   ...
>   /* All my great C prototypes here */
>   ...
> }

	Yeah, that's the way to do it. I don't know how platform independent it is
though, so you may run into problems and I've a feeling, even if it is part
of the current C++ standard, it may well be dropped when the ANSI C++
standard is finally released, sometime this year (hopefully), but,
hopefully the name mangling problem will be cleared up as well.

-- 
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

Scott Hill wrote:
> 
> Mathias Broxvall <mbr### [at] swipnetseNOSPAM> wrote in article
> <1d8### [at] dialup122-3-36swipnetse>...
> >
> > extern "C" {
> >   ...
> >   /* All my great C prototypes here */
> >   ...
> > }
> 
> Yeah, that's the way to do it. I don't know how platform independent it is
> though, so you may run into problems and I've a feeling, even if it is part
> of the current C++ standard, it may well be dropped when the ANSI C++
> standard is finally released, sometime this year (hopefully),

Extern "C" is still in the standard. The necessity for linking with
other languages will always be there; there's no chance of it ever being
dropped.

> but,
> hopefully the name mangling problem will be cleared up as well.

No chance. The name mangling "problem" is there for a good reason. It's
not the result of an imperfect specification or lack of thought on
anyone's part; the C++ standard quite consciously and intentionally
*encourages* compiler writers to invent incomaptible name mangling
schemes.

The reason is that name mangling isn't the only difference between
compilers. The same class compiled by different compilers can differ in
many ways at the binary level -- different sizes for the primitive
types, different padding between elements, different choices for where
the vptr goes, how it's interpreted, or whether it's used at all. And so
on.

If name mangling incompatibility was "fixed", it wouldn't mean that
object modules compiled with different compilers could be used together.
It would just mean that the incompatibilities showed up as strange
behaviour and unpredictable crashes at run time, instead of (relatively)
clear error messages at link time. This would not be a Good Thing. So
compilers use incompatible name mangling on purpose.

So why didn't the standard fix this by specifying an interface at the
binary level (as Java did)? Because those different compiler conventions
are there for a reason. There is no one best way to build a class;
different binary standards are best for different purposes. Requiring
one binary interface would make the resulting code suboptimal in many
cases. (This is one of several reasons why Java can never match C++ for
efficiency no matter how good the compilers get. Lest I be accused of
language bashing, that doesn't make Java inferior -- it just has
different priorities.)

This problem isn't unique to C++, although many C++ bashers would like
you to think so. It's always been there in C too; what do you think all
those FAR/CDECL/STDCALL/PASCAL/WINAPI/etc prefixes (or the equivalent on
other platforms) are for? They're the equivalent of name mangling,
inserted manually by the programmer instead of automatically by the
compiler, to indicate different calling conventions.

-- 
Ross Smith ..................................... Wellington, New Zealand
<mailto:r-s### [at] ihugconz> ........ <http://crash.ihug.co.nz/~r-smith/>
   "Remember when we told you there was no future? Well, this is it."
                                                         -- Blank Reg

Post a reply to this message