 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
HI all,
since this seems to be something that comes back from time to time I
decided to post what I have achieved so far (Not a lot :).
I tried to compile the PVMPOV sources on win32 using the Microsoft
compiler and the output is in povray.binaries.programming. As you can
see the compiler finds problems in microsoft suplied .h files. Which I
assume are not there.
If I remember correctly I can compile the samples provided with PVM with
the same compiler without a problem and I copied over all the relevant
make files setting to the PVMPOV make file, but still no luck.
I have no clue where to look for the problem, so if somebody has a good
idea, please and if somebody would like to see the source or the make
files them selves, drop me a note at tho### [at] gmx net or post it here.
Thomas.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas wrote:
>
> HI all,
>
> since this seems to be something that comes back from time to time I
> decided to post what I have achieved so far (Not a lot :).
>
> I tried to compile the PVMPOV sources on win32 using the Microsoft
> compiler and the output is in povray.binaries.programming. As you can
> see the compiler finds problems in microsoft suplied .h files. Which I
> assume are not there.
>
Since PVMPov is usually compiled with gcc under Linux you might try Cygwin
instead of the MS-Compiler.
A quick Web search for 'Cygwin AND PVM' finds quite some things, for
example:
ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/cygwin/ports/
Containing the complete PVM package for Cygwin.
Christoph
--
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other
things on: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hhmmmmm,
Maybe not a bad idea, I tried to compile the Unix version with Cygwin some
time ago, it compiled and even worked only it was a LOT slower than the MSVC
compile. One would almost need two machines to compensate for the speed
difference :). And Cygwin had no clue how to deal with the library files from
PVM, but that problem should be solved by this.
Then again, if someone would have more then two machines there would be a big
improment in render time.
Thanks for the tip.
Thomas
Christoph Hormann wrote:
> Since PVMPov is usually compiled with gcc under Linux you might try Cygwin
> instead of the MS-Compiler.
>
> A quick Web search for 'Cygwin AND PVM' finds quite some things, for
> example:
>
> ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/cygwin/ports/
>
> Containing the complete PVM package for Cygwin.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3A965BFD.3BC16A48@gmx.net> , Thomas <tho### [at] gmxnet>
wrote:
> I tried to compile the PVMPOV sources on win32 using the Microsoft
> compiler and the output is in povray.binaries.programming. As you can
> see the compiler finds problems in microsoft suplied .h files. Which I
> assume are not there.
You didn't run into compile problems with Microsoft libraries. You are
simply defining types and functions that exist with the same name in the
Microsoft libraries or that do not exist in the libraries are and used
in your code. The problem is in the code, wherever you got it from, and
the solution is to take a look at the compiler errors and then go to
_your_ code, look for the symbols the compiler rejected and then fix
them. Of course, you have to start with the _first_ error message, not
the last one you get. Frequently one error causes another one later on
because the compiler made an attempt to recover and continue somewhere
later, but this rarely works.
Look at the output you get:
D:\PROGRA~1\MICROS~3\VC98\include\frame.h(22) : error C2061: syntax
error : identifier 'BYTE'
So, find out what the problem is with" BYTE" and you are one step
closer. "frame.h" is a POV-Ray include file (if it isn't your project's
include dirs are screwed up), so it has nothing to do with some other
library.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Since PVMPov is usually compiled with gcc under Linux you
> might try Cygwin instead of the MS-Compiler.
I managed to get the unix version of POV-Ray to compile under
Cygwin, I managed to get it patched to pvmpov, and even managed
to get PVM itself to compile.
Unfortunately t does seem to work properly. I can run pvm,
then start pvmpov. pvmpov gives all the usual povray output,
says it's started rendering, then just sits there doing nothing.
From the pvm console, I can see that a job has been started,
but nothing ever happens after that :(
Anyway, I've sort of given up on the pvm route, and I'm working
on another solution. I'm going to write my own simple distributed
povray rendering program. Nothing fancy. Just something to
split up the image and allocate a chunk to a each slave task.
I'll let you know how I'm getting on when I have something
working (or not!) :-)
--
Jonathan Hunt
http://www.xlcus.co.uk/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jonathan Hunt wrote:
>
> > Since PVMPov is usually compiled with gcc under Linux you
> > might try Cygwin instead of the MS-Compiler.
>
> I managed to get the unix version of POV-Ray to compile under
> Cygwin, I managed to get it patched to pvmpov, and even managed
> to get PVM itself to compile.
> Unfortunately t does seem to work properly. I can run pvm,
> then start pvmpov. pvmpov gives all the usual povray output,
> says it's started rendering, then just sits there doing nothing.
> From the pvm console, I can see that a job has been started,
> but nothing ever happens after that :(
Have you given a look at the logs given by pvm (under un*x, it is in
/tmp/pvml.<uid>) ?
It is very likely that your clients crashed with an error, and since the
"plain" pvmpov is not very brilliant at dealing with this, the master
process keeps waiting for its children to return information.
PvMegaPov is not perfect, but much better at this job.
Another first test is to run using the -n flag, just to verify if the
renderer works without using the pvm daemon and threads. Does this work?
Is speed correct when compared to m$vc?
I (and former pvmpov authors) know of no success ever achieved at
win+pvm+pov, but the question comes back sometimes. I have no experience
at win programming, I do not consider myself very good at pvm, but I
could try to help you porting PvMegaPov under windos if you want to
carry on.
> Anyway, I've sort of given up on the pvm route, and I'm working
> on another solution. I'm going to write my own simple distributed
> povray rendering program. Nothing fancy. Just something to
> split up the image and allocate a chunk to a each slave task.
Sooo sad :-(
--
__ __ __ __ _
| | / \ / / |_ / |/
\/\/ \__/ /_ /_ |__ \_ |\
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I managed to get the unix version of POV-Ray to compile under
> Cygwin, I managed to get it patched to pvmpov, and even managed
> to get PVM itself to compile.
> Unfortunately t does seem to work properly. I can run pvm,
> then start pvmpov. pvmpov gives all the usual povray output,
> says it's started rendering, then just sits there doing nothing.
> From the pvm console, I can see that a job has been started,
> but nothing ever happens after that :(
Hmm, seems that you got further than me. I never got the thing to
compile completly. In addition to what Francios says, you might want to
give xpvm a try (I think that's what it's called), It's some graphical
program that shows all the PVM machines and shows all the interaction
between them. I think it only runs on unix machine but I'm not sure.
That way you can also tell what it hapenning.
> Anyway, I've sort of given up on the pvm route, and I'm working
> on another solution. I'm going to write my own simple distributed
> povray rendering program. Nothing fancy. Just something to
> split up the image and allocate a chunk to a each slave task.
>
> I'll let you know how I'm getting on when I have something
> working (or not!) :-)
Regards,
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> You didn't run into compile problems with Microsoft libraries. You are
> simply defining types and functions that exist with the same name in the
> Microsoft libraries or that do not exist in the libraries are and used
> in your code. The problem is in the code, wherever you got it from, and
> the solution is to take a look at the compiler errors and then go to
> _your_ code, look for the symbols the compiler rejected and then fix
> them. Of course, you have to start with the _first_ error message, not
> the last one you get. Frequently one error causes another one later on
> because the compiler made an attempt to recover and continue somewhere
> later, but this rarely works.
>
> Look at the output you get:
>
> D:\PROGRA~1\MICROS~3\VC98\include\frame.h(22) : error C2061: syntax
> error : identifier 'BYTE'
>
> So, find out what the problem is with" BYTE" and you are one step
> closer. "frame.h" is a POV-Ray include file (if it isn't your project's
> include dirs are screwed up), so it has nothing to do with some other
> library.
this frame.h is not a povray include file it is one of the standard windows
include files, it is a microcsoft directory and not in the directory where
the POV sources are.
I just had a quick scan through the pov source and BYTE is only defined in
truetype.c. I have a look at that and see what I can do about it. it
probably is the same type as in the Windows *.h files.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 26 Feb 2001 13:19:33 +0000, Thomas wrote:
>this frame.h is not a povray include file it is one of the standard windows
>include files, it is a microcsoft directory and not in the directory where
>the POV sources are.
You'll want to include windef.h before frame.h in whatever module has that
error, unless it's an error that it's including the MS version of frame.h
instead of the POV version (The MS frame.h is the ethernet frame structure.
That seems singularly unuseful, even for PVM.)
>I just had a quick scan through the pov source and BYTE is only defined in
>truetype.c. I have a look at that and see what I can do about it. it
>probably is the same type as in the Windows *.h files.
windows/config.h probably includes windef.h indirectly.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
> <<snip>>
> You'll want to include windef.h before frame.h in whatever module has that
> error, unless it's an error that it's including the MS version of frame.h
> instead of the POV version (The MS frame.h is the ethernet frame structure.
> That seems singularly unuseful, even for PVM.)
The impression I had was that frame.h (the MS one) is included from windows.h
orso and not that PVM includes it, but I will have a look at it.
> >I just had a quick scan through the pov source and BYTE is only defined in
> >truetype.c. I have a look at that and see what I can do about it. it
> >probably is the same type as in the Windows *.h files.
>
> windows/config.h probably includes windef.h indirectly.
I don't use the windows POV source for PVMPOV win32, since I figured that the
render clients don't need screen output and I thought that patching all the
windows code might be a bit complicated.
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
