Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Frood

Pages: 1 ... 126 127 [128] 129
1907
Could you clarify that a little bit? Basically what you would like to achieve is a sort of "clustering" of slaves in Backburner like it is possible e.g. with mental ray and it´s satellites? So that a single BB job (1 frame) uses not only one slave but multiple ones?

In that case I don´t understand why you wrote "[...] who wants to render more than one frame [...]". Because even if you have to render 1 single frame you can´t use all slaves by submitting it to BB. You have to render it locally. But consider Render Setup -> coronaRenderer -> Performance Settings -> # of threads (=cores to use). Set this to [your_core_count]-1 and let the frame(s) render with all slaves included. You can still work at your box and if RAM isn´t the issue you will not even notice.



1908
[Max] Resolved Bugs / Re: Another DR Problem
« on: 2015-03-10, 11:38:17 »
WORX! 1.000 thanks, NOW Corona is in fact production ready for us ;)

1909
[Max] I need help! / Re: DR problem.............
« on: 2015-03-10, 09:38:41 »
Not even max, it´s the basic network configuration which is faulty imho. Name resolution does just not work. When opening a shell on the slave I bet a "ping nas" would´t work either. We would have to know a few other things to resolve that completely, e.g. is there a DHCP and/or name server in his network or is he using static ip´s and a etc/hosts file, how is the tcp/ip configuration set on the slave etc... But yes, it´s in fact no CoronaDR issue (any more :)


1910
[Max] I need help! / Re: DR problem.............
« on: 2015-03-09, 17:46:50 »
As maru wrote, the slave cannot (or does not) access the texture. Aurelarchi, you haven´t started drserver as Administrator or any other user than the one who is currently interactively logged in by accident, have you? If so, that would be the cause.



1911
[Max] I need help! / Re: DR problem.............
« on: 2015-03-09, 12:23:34 »
If you are still interested to resolve your issue, please do as you were advised in reply #1 and reply #3 and check the results from the slaves directly using the "retain EXRs" feature. You somehow refused to give us any result until now.

Good luck

1912
[Max] I need help! / Re: DR problem.............
« on: 2015-03-09, 12:00:39 »
So if i understand i have to use \\NAS\Données\........... and not "Z:\dossier ARCHI\.... ?

Well, "have to" is not quite what I meant. It´s more a general advice. You never know how your scene gets rendered tomorrow :) When it comes to Backburner for example, there may be no "Z:\" available because BB-Server is running as a different user account or service  who has no "Z:\". If you are using and running DrServer interactively as a user who has Z:\ mapped you are of course fine. But using UNC paths does not hurt and you avoid most of the standard issues when rendering with multiple nodes.

As for your scene: I didn´t found any errors, I was just stating that your scene renders fine here on dr-slaves with vray installed :)

Good Luck!

1913
[Max] I need help! / Re: DR problem.............
« on: 2015-03-09, 11:19:24 »
I took a quick look at the scene from aurelarchi and dr-tested the file:

- slaves that have vray installed render correctly
- slaves without vray have the following warnings:

09.03.2015 10:43:39;  ***WARNING*** Missing dll: vrayphysicalcamera2013.dlo - VRayPhysicalCamera
09.03.2015 10:43:39;  ***WARNING*** Missing dll: vrender2013.dlr - V-Ray Adv 2.40.03
09.03.2015 10:43:39;  ***WARNING*** Missing dll: vray_rtmax2013.dlr - V-Ray RT 2.40.03

and spit out a white exrs VERY fast :) This is what turns the framebuffer white after a while (and this is what happend to user totinguis and others I guess). Simplest (obvoius) solution is to recreate the vray cam as standard cam, second (obvoius) solution is installing vray on the slaves.

And there may be still a path issue left: I would literally NEVER use mapped drives letters to link assets in any networked environment, even when working locally and even if slaves have access to and mapped the network source. Allways use UNC paths. The material you used for the floor is mapped to "Z:\dossier ARCHI\Maps\Bois[...]". This should read "\\NAS\Données\dossier ARCHI\Maps\Bois[...]". This is just a general workflow hint and not part of the issue as far I can see (but of many others).

Besides that, the test scene works as expected here.

Good luck!

P.S. Maru, what do you mean with "In this file, I am not able to see how the bitmap is loaded."?

1914
[Max] I need help! / Re: DR problem.............
« on: 2015-03-09, 11:11:57 »
I have the same issue with DR. I've installed the 45 day demo versión to try it out and everything works flawlessly except for DR. Everytime data is received from render nodes the image starts to get brighter and brighter.

Totinguis , are you sure you have vray installed on your slaves? If not and you are using a vray cam, the slaves start to render (and deliver) white exrs like crazy - turning your framebuffer white.

Good luck

1915
[Max] Resolved Bugs / Re: Another DR Problem
« on: 2015-03-05, 11:07:58 »
[...] and release a hotfix?

+100!

Related/same:
https://forum.corona-renderer.com/index.php/topic,7145.msg48043.html

Bugtracker:
https://corona-renderer.com/bugs/view.php?id=776

Attached is the simplest example scene demonstrating this bug: A cube, one animated cam. Result of frame 5 is a mix of frame 4 and 5 (see jpg). The passes are set very high to get at least something from a slave.

I´m SURE it´s just one line somewhere in the code to change, please do ;)


1916
[Max] General Discussion / Re: DBR popup disable on slave
« on: 2015-03-04, 10:06:21 »
This is another reason (for me) to run DrServer as windows service. Just like satellite server/backburner server/vray spawner and so on. See https://forum.corona-renderer.com/index.php/topic,7272.0.html

This way you can even use workstations with interactive users for DR in the background. Assumed they don´t need all their CPU power and memory, they wouldn´t even notice ;) (In case of mr satellite one should change the spawning script to run the rendering task with idle priority though)


1917
Just install 1.0, start Max, switch to Corona, start a rendering and activate the 45 day trial. If you use nodes as slaves with max demo version follow "Installing Corona on renderfarms and computers without 3ds Max GUI" here: https://coronarenderer.freshdesk.com/support/solutions/articles/5000564325-activating-license

Good luck!

1918
Just want to know if there are plans to do so. I run DrServer as a windows service here on the farm nodes and workstations because I consider it more controllable, convenient and consistent.

If there are no plans about that in near future I could do a short how-to in the Goodies section using "non-sucking service manager". It´s simple to setup but maybe some not so advanced users can benefit from it. All others who are interested, take a look at http://www.nssm.cc/ - it´s a better altervative than the SRVANY.EXE approach imho.


1919
It´s more "again" than a "still" there :) I´m confident it will be addressed soon.

1920
 fobus, you´ve got the point here:

"So what if we have 5 frames (stills) with animated camera and 10 PCs to render it."

Additionally it´s about having control about the rendering result while still having benefit of multiple machine power. This is our general workflow for quick projects. Fyi:

https://corona-renderer.com/bugs/view.php?id=776

I don´t believe it´s very hard to fix but i´m waiting already quite a while for a fix (the first bugtrack entry for that bug was closed as "fixed", submission date was  2014-03-12).


Pages: 1 ... 126 127 [128] 129