OctaneRender for Rhino Beta 1.20.1 [OBSOLETE]

[newske]

At the moment there is no assumption the same proxy will be used for all block instances. You might have different OBJ's assigned to instances of the same proxy. This is my understanding of how people want it to work. You can have one block instance definition and assign all your different proxies to instances of that definition.

That's fair enough - in that case it just needs a 'replace selected' type of thing.

[face_off]

Newske - I have not been able to reproduce you issue with the proxy settings not saving. Can you provide more details pls, and perhaps a very simple scene file which would allow me to reproduce the problem?

I did find an issue where if you assign a proxy with the Viewport open it was not being registered (or saved), which is fixed in the next version.

Regarding using the proxy host (block instance) scale and rotation, I've investigated further, and this is not viable at this stage. The axis order of the block instances is different from the Octane Placement rotation node, so the rotations end up incorrect. This is fixable, but is not easy, and I'd rather put that time in to the new material integration. So for the time being - export the block instance transforms, and load the file in as a scatter file.

Paul

[ALTO]

I struggle to see where this would be a hindrance, really - I can't imagine it being any more convenient than this - and this also means that scripting languages can interact with the geometry - which is where proxies are most important ie. scattering. Anyhow - what would be necessary to give you proof that this is a good idea? -ha

I use fauna as the primary example as it's generally what's necessary for scattering most, but given what the Rhino workflow is (and time spent on archvis forums) it would seem the ideal situation would be

1. Make a block that's the approx bounding box of your geometry ie. grass/trees/anything really
2. Assign proxy to block
3. Scatter/copy/place block while scaling. The bounding box gives a clear indication of how the proxies will behave
4. On rendertime, proxies render as expected and clear.

I quote all of what newske said, i think this could be the correct workflow, having a single proxy for each block instance allow us to have, for example a lowpoly tree used in the viewport as block, and the related highpoly (proxy) used in rendering. Scattering, moving, rotation, etc.. should be applied to the block.
This is not a priority for my point of view, but i'll really like to have this in the future.

[newske]

Newske - I have not been able to reproduce you issue with the proxy settings not saving. Can you provide more details pls, and perhaps a very simple scene file which would allow me to reproduce the problem?

Paul

Paul,
I managed to reproduce the problem.
The issue does not occur when the files are located on C:\ - I didn't test which files specifically, just moved all the scene files and relinked. When on my external drive (L:\ in this case) the files are not saved. Moving to C:\ would be very cumbersome in this case since it's a shared HD, or in other cases could be a network drive.

I attached the scene file for reference, anyway - perhaps try it on both C:\ and another (non-windows) drive for reference.

Newske

[face_off]

I managed to reproduce the problem.
The issue does not occur when the files are located on C:\ - I didn't test which files specifically, just moved all the scene files and relinked. When on my external drive (L:\ in this case) the files are not saved. Moving to C:\ would be very cumbersome in this case since it's a shared HD, or in other cases could be a network drive.

Newske - I was still unable to reproduce the problem. I copied onto my E: drive, loaded, relinked, saved, reloading and everything was fine. Perhaps try the next version (available in 30 mins) and let me know if the problem persists.

Paul

[face_off]

Hi

I have refreshed the installers at the top of this thread with the following:

1.20.1.18
- Fixed issue where assigning a proxy to a block instance when the Viewport was not open was not working
- Improved "fov" calculation for Parallel views - still needs tweaking
- Fix issue where proxy scatter host was not been set to 0, 0, 0
- Added button to copy the selected proxy info to all instances of the current block
- Improved the ability extract Rhino "Environment" information into the rendertarget (so the diffuse color is used if an IBL is not present)
- Fixed lag issue when using HideSwap
- Fixed exception when creating an emitter from a rectangular light
- Fixed issue where using the _Copy command was not copying the proxy info to the new copy of the block instance

Paul

[newske]

Newske - I was still unable to reproduce the problem. I copied onto my E: drive, loaded, relinked, saved, reloading and everything was fine. Perhaps try the next version (available in 30 mins) and let me know if the problem persists.

Paul

Ah, sorry. I mis-diagnosed the problem. It seems that it (the links being lost) occurs when the geometry is hidden when the file is open/saved (on a hidden layer).

Newske

Edit:
I think there's also the same problem which is/was applying 'hide' as to 'lock' - that is, 'hide' 'show' 'show selected' 'lock' 'unlock' 'unlock selected' etc - it seems to cycle through the materials of the objects when unlocking, slowing down the process... or something.

Edit2:
This applies to group/ungroup, too. [using 1.20.1.18]

[face_off]

Hi

I have refreshed the installers at the top of this thread with the following:

1.20.1.19
- Fixed issue where proxy info was not being loaded from saved scenes for hidden objects
- Fixed lag issue when grouping/ungrouping, and performing a number of other actions.

Thanks Newske for reporting these.

Paul

[newske]

Paul
There seems to be a memory leak when rendering animations using the viewport geometry. Using a large scene and watching the frame counter my memory (listed under Rhino.exe) continually goes up.

Edit: it seems to happen regardless of whether viewport geometry is used -- but I have not confirmed this.

Newske

[face_off]

There seems to be a memory leak when rendering animations using the viewport geometry.

I spent many hours watching the task manager and memory consumption with the plugin during close beta testing. It's not really possible for a memory leak to occur with RhinoCommon code (since it is managed C#). And to date, there hasn't been an memory leaks found with the Octane API (which is "unmanaged" code). I noticed that often memory used will increase for quite some time, then a huge block of memory will be freed. I suspect it depends how much RAM you have too. With lots of free RAM, there may be less priority placed on releasing memory whilst the CPU is working hard rendering an animation.

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