[EONA]

Hi all

Maybe someone can help me out here.
In general we model large motor yachts, scale is 1:1 , they range from 60-150meters.
I have made a template with all our standard Maxwell materials, about 38 and a very large cylinder (about 20 kilometers in diameter and 20meters deep in the center) with a slightly curved top, this is to represent the sea with curvature, the sea object has a water/sea material that has a bump map image that is tiled across the 20km . I open this template and import my yacht into this scene I then apply my materials to all objects.
This works fine with some of the more simple models but when we have very complex rhino Runs out of memory and tells me I have to restart the system.
My feeling is that large sea object and its material is taking up a lot the memory and when used with a complex model is just too much for Rhino 4.
IS there any way of making the sea object smaller but still having the illusion that it has a distant horizon?

Just for interest: We have a similar problem when using Flaming render but we use the ground plane instead of the sea object used in Maxwell, our solution for flamingo is save it in Rhino3 format then render in Flamingo through Rhino 3, It seems Rhino4 is a resource hog .


My system:
Windows XP
Duel Quad Core Intel Xeon CPU
E5320 @1.86GHz
1.58GHz 3.25BG of Ram
Physical address Extension


Thanks
ESEA

[JDHill]

Hi Edwin,

Some questions first:

a) have you actually compared the memory usage with and without the sea object? What are the results?
b) how much memory to open just the template?
c) when does it run out of memory? When opening the .3dm, working with the scene, exporting the MXS, or?
d) Windows XP - 32bit?
e) why do you have 3.25 GB? You say PAE, I don't see how this can help you much with this RAM configuration.
f) the plugin caches Texture thumbnails - have you tried using the command Maxwell_ClearCachedData?

I suppose I would try this:

- open the template, note memory usage
- set all textured materials to show no viewport texture
- set the mesh density for your sea object to the minimum possible detail necessary for a good result
- save the template and close Rhino
- re-open the template, compare memory usage
- import your model
- apply materials, set up scene
- note memory usage
- save and close Rhino
- re-open the model, compare memory usage
- set all textured materials to show no viewport texture
- save and close Rhino
- re-open the model, compare memory usage once again

By doing so, you may be able to find some scenarios where you can modify the way you're using things to minimize the memory usage - unless you measure it concretely, you're flying blind.

Mostly, I would try to prevent both the plugin and Rhino from opening up bitmap files - both of them cache smaller versions of these, so they'll be taking up memory that you don't need to use. You can try the plugin command 'Maxwell_ClearCachedData' to free up cached thumbnails in the plugin. You may also be able to get a different (better?) result memory-wise by extracting a displaced mesh out of your sea object and applying a regular dielectric to that, rather than letting Rhino mesh the object, then putting a big bitmap on it. You can probably get away with a pretty coarse mesh - if you play around with the Weld command.

In the end, if you're running into things like this, you likely will want to think about running a 64bit OS with more than 4GB of RAM to give Rhino as much breathing-room as possible.

JD

[EONA]

Thanks JD
As always you give us mere mortals a quick response.
I will have a look into this and get back to you.
a) No have not,
b) a first quick look @ memory usage viewed in windows task manager
-Open Rhino 4 - 56520KB
-Open Template- 126120KB
-Import boat -974348KB
c) It opens the file but working with the scene it will crash
d) Would you suggest Windows Vista? Will Rhino improve in performance?
e) I have no clue to what Physical address Extension is and why we have this. It came on the system when it was bought last year
f) No but will from now on
I will try you other suggestions. I have already set the wire frame thickness to 0 on meshes and set edge thickness to 1 (otherwise you see nothing) this helps a lot in moving around the model on some of our other less powerful systems

Oh buy the way I was told by someone at McNeel that


“The problems is not Rhino nor Flamingo, the problems is Windows.
It cannot handle more than 2gb per application. this does not happen on
Windows 64. but Rhino and Flamingo arent designed to work with windows 64.
There is a trick to force windows to use more than 2gb of memory per
application.http://www.gidhome.com/support_team/gid3gb/index.html
I am not recommending you to use it, but I guess you should know about it.”



Now that looks a bit scary for my limited behind the scenes windows knowledge.
Thanks again
ESEA

[JDHill]

That is just the general thought process that I would start with when tackling an issue like this - once you have some measurements, you can start to see where your bottlenecks are and it will become easier to make the right choice about how to proceed.

Depending on your video card and other hardware, I wouldn't guess you'd ever be able to get more than 1.5-2GB usage out of Rhino on your machine. With XP 32bit and 4GB, the most I've ever seen for one app was MXCL, and that was at ~2.7GB. The rest of the memory is reserved for other things, and this might vary depending on some of the installed hardware. I would be curious to see what your boot.ini file looks like (should be hidden, in the root drive). Setting up an x86 machine with the /3GB switch can be tricky, so that's why the McNeel people discouraged you from doing it. But as I say, I don't think you could gain much there anyway - you really need more RAM and an OS that can use it.

I won't flat-out recommend any OS, but I've been on 32bit Vista pretty much since it was out, and I have found it to be much more stable than XP SP2 was. If you do move to a 64bit OS, Rhino should be able to use up to 4GB if it's installed and available. Same goes for the plugin, it is also compiled with the necessary flags set for using up to as much memory as is possible for a 32bit application. Note, though that the memory limit is per-process - the plugin runs inside the Rhino4.exe process, so the max limit applies to the combined usage of Rhino, and any plugins including Maxwell.

Beyond all the hardware/OS considerations though, really look at how you're using what you do have, i.e. don't use render-mesh settings that are more detailed than they need to be. I'd figure you could get away with very little detail overall when you're dealing with models of that scale - maybe you'll need to tune up a few pieces here and there, but there is likely lots of geometry in the scene than can be optimized.