[Ernesto]

Thanks Fernando,

The post you redirected says the following:

Had to open rendernodes local settings/temp folder and rename each cooperative.mxi file to cooperative#.mxi (# = rendernode number). (Local settings folder hidden by default, change view hidden files to view.)
The location of the coop.mxi and coopaux.mxi can be found by copying the mxs address in the mxcl server window, if you don't know it exactly.

In my case:
MXS:C:/DOCUME~1/PLANTI~1.3DE/CONFIG~2/Temp\cooperative.mxs

I have just found it!!!

Ernesto

[Ernesto]

CONCUSION:

Here I will write my opinion:

Thanks to all the Users that have helped solving this mystery!

The Interface of a software IS the connection between the program and the User.
The main function of the User Interface, is comunicate the USER the main necesary aspects to get a job done correctly.
In the Maxwell Render Interface, this is NOT the case. The Software is not reliable enough, and the interface does not help, but acts as an obstacle to the USER.

For instance: In case of cooperative Rendering, part of the interface gets USELESS as it was noted in this same topic.
A USELESS part of the interface is not a neutral detail, but can be a mortal trap! I suggest that in case of USELESS parts of the interface, it should change the color to grey, telling the USER acondingly to the Iterface standards that we can see in most softwares. Having a RED button called RENDER is a trap for users.

On the other hand, in case of unpredicted behavious as it is normal in Maxwell Render, the developer must give a solution clearly stated. For instance if the case is that Maxwell didn´t saved the image in the output folder, it should be stated in the manual or in the interface so that the user can find a way to solve the problem, instead of needing a forum, where the users helps each other without of the intervention of Next Limit.

The weird thing about NL not participating, is that they seem not to be aware of these problems, or in case they are, they seem not to care, as we can deduct by the absence of actions in order to fix the problems.

I am really surprised by this software that is supposedly not BETA, but works like one.
It is possible to learn all the bugs traps and problems in order to work more freely, but it is not the expected way.
I feel reallly fooled by this software which interface is conspiring against the succes of the work!

In my opinion, a User Interface need to be INTUITIVE. That is the KEY to fuctionality. The ITUITIVITY must be over the Aestectic design. In the Maxwell Render these values are INVERTED and the result is an interface that looks great but works badly. This is the worse combination, since the design fix the expectations and the experience cannot fullfill the previous expectations. The result is USER DISAPOINTING.

Of coures I love the images made by Maxwell, but there is NO RIGHT to make the user´s life so complex!!!!
Pleasse NEXT LIMIT, listen to these CRITICS.

Ernesto

PS.

[Ernesto]

Ok, After so many problems I decided to do a next test, just to make sure I will be able to do it another time!

But got this surprise: The render FAILS...
I tried in 5 diferent machines and they failed the 5 times....
there is no WARNING message that can tell me what is WRONG this time...
This is discouraging....

Here I pasted the messages:

===================== New session opened at 14/September/2009 20:14:01 =====

Maxwell Render® 1.7.1 - win32
(C) 2004-2007. Next Limit Technologies

C:\Archivos de programa\Next Limit\Maxwell\mxcl.exe -server -p:low
--------------------------------------------------------------------------

WARNING: - Low Priority Enabled
[14/September/2009 20:14:01] Starting Render Node

[14/September/2009 20:15:40] Reading MXS:C:/DOCUME~1/PLANTI~1.3DE/CONFIG~2/Temp\cooperative.mxs
[14/September/2009 20:15:40] MXS file read successfully

Geometry:
- Num Meshes: 227
- Num Triangles: 315734
- Num Vertexes: 173361
- Num Normals: 217188
Render settings:

- render core : RS1
- render version : Maxwell Render® 1.7.1 - win32
- desired rendering time : 240h00m
- desired sampling level : 15.000
- render resolution : 1920 x 1080
- using 0 threads
- illumination layers:
. . direct layer: true
. . indirect layer: true
. . direct caustic reflection layer: true
. . direct caustic refraction layer: false
. . indirect caustic reflection layer: true
. . indirect caustic refraction layer: false
- bitmaps path : W:/Recursos
- ignoring bitmaps

[14/September/2009 20:15:40] Checking Data
[14/September/2009 20:15:40] Loading Bitmaps & Preprocessing Data
[14/September/2009 20:16:10] Start Voxelization
[14/September/2009 20:16:15] End of voxelization
ERROR: - XOê "C:/DOCUME~1/PLANTI~1.3DE/CONFIG~2/Temp\cooperative.mxi"

ERROR: - Render Failed




Any hint will be greatly apreciated!

E

[Ernesto]

Now, in order to discard possibilities, I tried to render the same MXS file that was rendered the first time, and it failed!
So this discards a wrong MXS file...

Ernesto

[Ernesto]

Here I tried to render the same MXS file in normal mode and it works OK.
This discards again a problem in the MXS file.
The problem is in the COOPEERATIVE mode
E

[Ernesto]

Here am posting a new test:


===================== New session opened at 14/September/2009 20:37:32 =====

Maxwell Render® 1.7.1 - win32
(C) 2004-2007. Next Limit Technologies

C:\Archivos de programa\Next Limit\Maxwell\mxcl.exe -server -p:low
--------------------------------------------------------------------------

WARNING: - Low Priority Enabled
[14/September/2009 20:37:32] Starting Render Node

[14/September/2009 20:38:44] Reading MXS:C:/WINDOWS/TEMP\cooperative.mxs
[14/September/2009 20:38:44] MXS file read successfully

Geometry:
- Num Meshes: 75
- Num Triangles: 320121
- Num Vertexes: 164534
- Num Normals: 174554
Render settings:

- render core : RS1
- render version : Maxwell Render® 1.7.1 - win32
- desired rendering time : 240h00m
- desired sampling level : 15.000
- render resolution : 1920 x 1080
- using 0 threads
- illumination layers:
. . direct layer: true
. . indirect layer: true
. . direct caustic reflection layer: true
. . direct caustic refraction layer: false
. . indirect caustic reflection layer: true
. . indirect caustic refraction layer: false
- ignoring bitmaps

[14/September/2009 20:38:44] Checking Data
[14/September/2009 20:38:44] Loading Bitmaps & Preprocessing Data
[14/September/2009 20:39:09] Start Voxelization
[14/September/2009 20:39:16] End of voxelization
ERROR: - 8´"C:/WINDOWS/TEMP\cooperative.mxi"

ERROR: - Render Failed

I wonder if this can be understood by NEXT LIMITV Programmers in order to detect WHAT IS WRONG?
E

[Ernesto]

Just in case: Do not tell me that the solution is to Upgrade to V2!!!!!

Ernesto

[Fernando Tella]

Are you able to copy files from and to each node without problems? I think there's something in your network setup that makes the manager fail.

Cooperative is not 100% reliable but it usually works here.

[Mihai]

The line that says ERROR is a clue no?

What is that cooperative.mxi? Is it something used in the scene? Is it the path you're saving the mxi to? What are those strange symbols in the path? When a network render fails to render it's usually because there are some files missing like textures, ior, mxi emitters etc. Make sure all these files are in a shared folder that all machines can reach. From your test it looks like you're reading an mxs file from the temp dir of one of the machines

Code: Select all

[14/September/2009 20:38:44] Reading MXS:C:/WINDOWS/TEMP\cooperative.mxs

Make sure the folder you are saving the final image and mxi is in a shared folder, you can specify a network path when adding the job. Page 131 of the manual explains in more detail, but I'll write here again:

If you have a node called 'renderbox1' which is part of a Workgroup named 'farm', do a pack & go to a shared folder on that machine. When adding the job, browse by going to My Network Places>Microsoft Windows Network>farm>renderbox1>myfolder. The path for the mxs file will then be \\renderbox1\myfolder\yourfile.mxs. Do the same thing when specifying a save path for the mxi and render bitmap.

[Ernesto]

Thanks Mihai,

But the mxs file is ok, and there are no missing maps nor files.
If that would be the case, I wouldn´t be able to render the same mxs file, in normal mode (not cooperative)
I tried all the mxs files that failed in the cooperative tests, and they worked OK in normal mode.

The local path in the temp folder:
That is the place where maxwell render saves a copy of the cooperative file, in order to calculate it faster without the network delay. This is the normal procedure, and I am not deciding it, but Maxwell alone.
The output files paths are in a Network Drive called W.

[Mihai]

The maps may not be missing on the local machine you're doing a normal render on, but missing for the other machines if they can't reach the files. Make sure first of all a remote computer can see the networked drive. In the test you posted, it looks like also the mxs is being read from a temp location. So if you do the procedure like I outlined above, when adding the job, it should work ok.

[Ernesto]

The maps may not be missing on the local machine you're doing a normal render on, but missing for the other machines if they can't reach the files. Make sure first of all a remote computer can see the networked drive. In the test you posted, it looks like also the mxs is being read from a temp location. So if you do the procedure like I outlined above, when adding the job, it should work ok.

I am totally positive that all the maps are in the W drive which is a network drive and can be accessed from any other machine.
I have performed tests rendering the MXS file from each of the mahiines in the network, and they worked ok.
The problem appears when I try a Cooperative job!

It seems that after my first and unique try, the software got broken or something...
Perhaps an incomplete Cooperative job, let some procedure pending and this is BLOCKING the possibility of doing a cooperattive again!
It is really weird that I could do the first cooperative job, that failed to save in the network output adress, and after that It seems impossible to do a new COOPERATIVE job!

I must say that I have read all the manuals several times, and they do NOT tell anything about these problems...

Ernesto

[Ernesto]

THE SOLUTION!!!!

Ok, after 5 days trying and trying all kind of options I have just found what was happpening and how to avoid this problem.

I have 3 machines: 23, 24 and 25

WHAT NOT TO DO:

Set the first machine as SERVER AND MANAGER, and run the cooperative job.
In a second stage I was planning to add moore machines.

WHAT TO DO:

Set the first machine as MANAGER, then set ANOTHER MACHINE as server, and start the process, then yu can add more machines even the machine that is working as MANAGER, that can do the job as SERVER too.

THE CRASH WAS PRODUCED in case I set the same machine as MANAGER and as SERVER, and then START THE JOB!!!!

This is weird and vvery tricky and took me a week working hard.

OPINION: in my opinion NEXT LIMIT has not the right o make me lose my time with tricky and unreliable procedures.
I think that this version that I have bought is NOT what promised, but just a beta work.
The promises in V2 are the proofs! the cooperative job was totally rebuild. If it were ok, why you are rebuilding it again?
And in case it was necesary to rebuild: it is because the version 1.7 is not working!!!
Again: I feel fooled by NEXT LIMIT!!!! because they prefer to gett more money before fullfill their promises of a working software. Of course you can have a diferent opinuion, but this is MINE!

Thanks again to alll the helpfull people in this forrum!!!

Ernesto