THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 25/06/2009 at 10:37, xxxxxxxx wrote:
Cinema 4D Version: R10-R11
Platform: Windows ; Mac OSX ;
Language(s) : C++ ;
I have a concern about these three in use together. My plugin is a generator plugin which now utilizes multiprocessing threads to increase throughput. So, say you have 4 processors, it divides the input 'polygon clone' into 4 objects of equivalent polygon counts, one for each thread. Some of the settings of the generator are min/max ranges and random::Get01() is used to get random values inbetween the range. So, you put this on a render farm or use Net Render on a few machines which have different numbers of processors which may result in different divisions of the polygon object.
How might this affect or change the results from the original machine to the render machines?
Should I go the more memory intensive route and create random number tables to the extent needed before entering the threads so that the variations are always the same for the same input/seed?
This is something that really must be known before any notion of commercial release.
On 25/06/2009 at 16:43, xxxxxxxx wrote:
Bump - thanks ahole forum-spambot.
On 28/06/2009 at 10:28, xxxxxxxx wrote:
On 29/06/2009 at 00:22, xxxxxxxx wrote:
For NET render the generator has to produce identical results no matter what system is rendering. So yes you have to find ways to ensure indentical ways. I think the easiest would be some sort of caching if possible.
On 29/06/2009 at 11:31, xxxxxxxx wrote:
Thank you! (I think).
Here's a addendum question: When a document is sent out for rendering on a network, is the generator recalculated or will the current result be used (as it is in the document when there are no changes to the generator parameters)?
On 01/07/2009 at 15:29, xxxxxxxx wrote:
Let me know what you think of this assault.
As memory intensive as it would be, it would guarantee unique and constant random numbers no matter how many processor threads. It would remove repetition of random numbers seen in the threads as well. Create a large table of random numbers once before going into the threads. This large table would be based on the number of polygons, splitting the table into a table per polygon and sent to the thread which is working on that polygon. So, there would be n unique tables per thread where n is the number of polygons. Very memory intensive (probably in the MB range) I think since there might be many random numbers used per polygon in the various operations. This could be reduced if the table were used cyclically.