OTOY Forums

face_off wrote: So in summary, whilst the task manager may be reporting increased memory use from time to time, from what I have observed, over time the memory is all freed as CPU cycles are available to do so. But if you have a specific test case where this is not the case, send it to me and I can investigate.

Paul

Thanks for that, an interesting little piece of info.

The scene I am using uses about 300mb vram (GPU). It has a great deal of scatters and a few blocks (without proxies). With 32GB RAM, it slowly fills up 99% of that - but as there is less ram the speed at which it takes it up slows. Even after rendering is finished, Rhino is still using 29-30GB ram, which doesn't really make sense to me. That said, I haven't yet had a chance to test whether the same issue occurs using Rhino Render - so it might not be your problem at all. Will give you an update when I get a chance.

That's interesting. I've never seen anything higher that 1.5gig on my test scene with Bongo. Alto had an occurence similar to you on one of the test builds. Is the same thing happening if you close the viewport causing a full reload each frame? I wonder if the .net version could possibly influence this? If you have a sample scene which shows this issue I will take a closer look.

face_off wrote:Is the same thing happening if you close the viewport causing a full reload each frame? I wonder if the .net version could possibly influence this?

Yes - that is happening (I just thought that was normal, funnily enough).

I can now replication the animation issue. I will check it out. The fact that you cannot cancel an animation, and Rhino grabs the current window every frame, makes this very hard to test :-\

Paul

I have identified the memory issue and resolved it. You can re-download the installers from the top of this thread.

1.20.1.20
- Fixed memory leaking when rending to the Rhino render window (particularly when rendering animations).

Thanks again to Newske for providing the info to track this issue down.

Paul

Fantastic - I'm glad that is resolved. Well done Paul.

Still having a few issues with proxies (1.20.1.20):

• Origins seem strange still - scatter (matrix) does not reference 0,0,0, but still references the base point of the block the scatter is assigned on.
  Links between obj, csv and the reference block are being lost (still) upon saving and opening the file. This now seems unrelated to the state (hidden or locked) of the block as was the issue previously. (Literally just applying the links, saving the file and re-opening and nothing else seems to lose the links)

Regards
Newske

You are right Newske - I have those changes in a different branch of the source code (the branch with the new Material integration). My apologies. I will fix this right away.

Paul

Another update. You can re-download the installers from the top of this thread.

1.20.1.21
- Re-fixed the issue where scattered proxies were not be centered to 0, 0, 0
- Re-fixed the issue where scatter and proxy info was not being loaded from a saved scene.

Paul

Paul - fantastic.

Thank you for your prompt responses to all these things -- it is much appreciated. You'll probably hear a little less from me for a few weeks as a project was just completed (thus why I've been able to test this stuff so constantly) - but there should be another in a few weeks.

You'll be glad to hear that it was a great success, largely thanks to your quick updates (not to mention the development of Octane for Rhino in the first place... obviously)

It was a good chance to test many of the features reasonably thoroughly, and I can safely say this is an absolutely fantastic product, and I will be highly recommending it.

Regards,
Newske

P.S. the only thing that still remains as far as I'm concerned (apart from the material system you're working on) is proxies having more integration with blocks - as we discussed previously.

That's for the great feedback Newske. It makes all the hard work worthwhile

Paul