If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
New! You can now log in to the forums with your chaos.com account as well as your forum account.
Works fine now, but the bightness problem is back. I see know, that the physical sky is the problem: it seems to be, that the slave use a 180° turned sky environment - the master buckets show the sun from an other dir than the slave buckets. Also a reopen of the scene dosn't help.
Interesting - I'll see if I can track down the mismatch of sun direction.
Two questions for DR and IM more: single frame mode and I want to get a IM cache file for future use. So, if I set the IM cache path d:\IM.vrmap, than the cache file is saved at the master hdd only. But if I set read cache, than the slave try to read at the slave hdd too. Is it a bug?
So, it works only, if I manualy copy the cache file from the master hdd to the slave hdd.
And how will it work for incremental save? Is the best way, don't automatic write the cache to hdd and manualy save the cache file from the memory after the whole IM is calculated?
For DR, all of the saving is done through the host computer. So if you want to save the IM calculation, it will be saved by the host computer, in the location specified, after the IM information is compiled from the slave computers.
If you want to read a saved IM file that it is basically the same procedure as textures. That file must either be in a location that is accessible to all computers (like a network drive), or be available locally in the same file path.
As for Incremental Add, the IM solution stays within memory the whole time the calculation is being done. I believe the IM only gets written at the end of the calculation, not at the end of each frame.
Joe, my Rhino.exe at the master use 311MB and the slave 50MB. We talk about it befor ... could be good, if the spawner could be used at the master for rendering too and not the rhino.exe. Maybe you get a 64bit version working so we could use unlimted RAM for rendering ... dreaming ...
Joe, my Rhino.exe at the master use 311MB and the slave 50MB. We talk about it befor ... could be good, if the spawner could be used at the master for rendering too and not the rhino.exe. Maybe you get a 64bit version working so we could use unlimted RAM for rendering ... dreaming ...
I think unlimited is pushing it a bit Since I think 64bit windows still stops at 4 gig. But its better than 2 or 3. I think we can manage an x64 spawner.
Its "virtually" unlimited...meaning that whatever the limit is at (think its at least at 16TB, but I've heard different things from different sources), you aren't going to be building a system any time soon that gets anywhere close to that limit. I think the maximum that I've seen a mobo support is something like 32 GB or something like that (it may even be up to 64), but the point is that you've got to have very very deep pockets to even max out what is presently available.
Yes it is technically limited to 2^63 - 1 bytes I believe... but no hardware is anywhere near that and I didn't think that XP64 went above 4 gig per process, or something like that. I could definitely be wrong though.
I didn't think that XP64 went above 4 gig per process, or something like that. I could definitely be wrong though.
Anyone feel like donating to the "Lets see if Damien's X64 System can Max out 4GB per process" fund...I need the memory first...Donations are much appreciated...no animals will be harmed in these tests. ;D
Oh, last I installed 3dsmax trail I was confused by the usage to much ... .
And I suppose so, I can not install a new trial again.
Joe, 4GB per process could be nice too - a first step to the unlimited RAM.
EDIT: 8TB seems to be the 64bit single process limit.
Some infos from the WWW:
"The major differentiator between 32-bit and 64-bit Windows is in memory
support. Currently, 32-bit Windows is capable of supporting up to 4 GB of
system memory, with up to 2 GB of dedicated memory per process. Windows XP
64-Bit Edition will currently support up to 16 GB of RAM, with the potential
to support up to 16 TB of virtual memory as hardware capabilities and memory
sizes grow."
Virtual Address Space per 32-Bit Process = 4 GB if compiled with /LARGEADDRESSAWARE
Does that mean that Rhino can use up to 4 gb without having to be a true 64-bit app, as long as its compiled with the Large address thing??? McNeel has said that making Rhino 64-bit is not at the top of their list, but if they used the large address thing, that would at least be much better then the 2 gb thats allowed now.
Good news: I meshed a scene so that I get 8.000.000 polygons and than I copied the scene again and again .... at RAM usage 3.8GB of the rhino3d.exe I got the crash.
Next test like befor, but with less copies. I start the rendering and at 3.8GB Rhino crash. So, my current limit is 3.8GB.
My system contain 5GB RAM now. Some weeks befor my system contain 4GB and Rhino crash at 3.2GB allways. So, the extra RAM helps Rhino. Interesting for me, my page file is set at 4GB, so I should get 9GB RAM, but I got crashes if the 5GB are full.
Comment