Itoo Software Forum
RailClone => RailClone Pro (*) => Topic started by: Mustafa on April 30, 2014, 06:56:40 AM
-
I got this error on slave PCs when rendering with V-Ray DR
(http://i58.tinypic.com/15fmbtc.png)
windows 8.1.1 64-bit
3ds Max 2013 64-bit + Update 6
V-Ray 2.40.03
Railcone Pro v2.2.3 Network License
-
Hi,
It occurs just using render slave/s or also locally? Please try to delete railclonevray20.dll file (in the 3ds Max root directory) on all your render slaves and reinstall RailClone with V-Ray DR spawner service stopped. Also double check you are using the same release of V-Ray on all computers included in DR. Hope this helps you but let us know in case of any troubles.
Kind regards,
-
I've had this problem for some time now on the render nodes only. I just accept it and restart the spawner on the render node.
I'll try the fix suggested and let you know.
Bill
-
It just happens on the slaves PCs and doesn't occur on the master PC .. (each PC render the scene locally with no error when DR is OFF)
I have the same version of V-Ray & 3ds Max on all PCs ..
sometimes it resolved by restarting the spawner but at the last time it doesn't work at all .. I had to convert RailClone to EditPoly to discard it from the scene ..
Edit: Restart the spawner is working but I need to restart the spawner each time I press render
I will try your suggested solution and tell you what I got ..
Regards,
-
Have also had this problem for a while, but is intermittent
-
This type of intermittent problems may be difficult to fix, more if happens within of V-Ray.
Please, send us the vraylog.txt files to support@itoosoft.com. Hopefully we can get some useful info from them.
-
I have it happening at the moment on a scene Im working on.
Which Vray log files do you need? The DR slaves?
Any idea where I can find them? :)
-
Yes, we need the VRayLog.txt of the slaves, which is created at c:\
If this issue happens always with a specific scene, please send it as well. It may very helpful to identify the problem.
-
Ok, so I have not tried the fix suggested, but here is a bit of an update:
I have just updated all our machines to the latest version of Forest pack and have just had the error occur, so it is not fixed in the latest release of Forest pack. However, for me it is a very specific time, and process that causes this error. In order for me to get this error, all I have to do is: start a local render with v-ray distributed rendering enabled and a selection of nodes being used; then when the process is started, but the nodes have not actually contributed any buckets to the pre-passes, just hit cancel in the v-ray render dialogue to cancel the render. The last time I did this (only a few minutes ago) I got the error locally, although this doesn't usually happen, and on all the nodes. Hitting cancel on this error dialogue will reset the max dummy on the nodes, and you are ready to go again.
In brief, I think it has something to do with the calculation of the forest pack geometry ready for rendering, which is in some way connected to vray, and yet when you cancel the render in the middle of this process it doesn't like it.
I hope that helps.
EDIT: I just realised that this post is in the rail clone forum. I have been having the problem with forest pack, but I assume the error is caused by the same problem. I have both, so don't know which is causing the problem.
Cheers,
Bill
-
Thanks for the information, Bill. We'll make some tests following your indications.
-
Any updates on this issue?
-
No, sorry. Until now we could not reproduce this problem in our test machines. This is essential in order to debug and fix it.
We have modified slightly the VRay initialization in RailClone 2.3.0b (to make if safer), but we don't know if that change would help with this problem.
-
Did you get this error to appear when you tried my "method"?
Cheers,
Bill
-
Did you get this error to appear when you tried my "method"?
Unfortunately not. May be it fails more frequently in render farms using many nodes, but in this case we must use a single node running under a debugger (if not, we cannot trace the problem). Even on these conditions, usually we must reproduce the crash several times.
The main problem is that the crash doesn't generates a minidump (which is easily traceable).
-
We are also getting this. Any solution?
-
Unfortunately not. Although we could to reproduce the crash a couple of times, we didn't find the cause.
Now i'm trying to crash it again, so we can send the debug info to ChaosGroup, but it doesn't fail. We'll continue trying it... :(
-
We are also getting this. Any solution?
We are collecting some stats to isolate the problem: what Forest, RailClone and VRay version do you use ?
Thanks,
-
If you suffer this problem and use RailClone 2.2, please try with the latest RC 2.3 beta and tell us if there is some change.
We have included a fix in this release that would solve the problem, but we are not sure. This bug is not easy to reproduce, and until now we only got the crash using RC 2.2.
-
Hi,
We are also having this issue for a while now.
The error only happens when clicking cancel on a render; About 1/4 of the time we can go and click ok on all render nodes...
No problem on workstation.
We haven't figured out if the problem is caused by Forest Pack or Railclone but I thought it was Forest pack related.
All workstations and render nodes are running on Forest pack 4.24 and Railclone 2.34 and we're still having this problem.
-
Unfortunately we have done tons of tests, but no clue about what may be causing this problem. It would be some bug clearing data in the cancelling process, but we have verified our code several times and everything seems correct. Also we got the crash only a few times in our test scenes, so it's completely random.
I'm afraid we are stucked with this issue.... :(
-
It seems I was wrong in my previous post. We were running Railclone 2.23 and after updating to Railclone 2.33 the problem does seem to be fixed (or at least better). So build 2.33 fixed a lot for us conserning this issue !
-
It seems I was wrong in my previous post. We were running Railclone 2.23 and after updating to Railclone 2.33 the problem does seem to be fixed (or at least better). So build 2.33 fixed a lot for us conserning this issue !
Great !. That has sense, because we could not reproduce the problem since the RC 2.3 changes.