OctaneRender for Rhino Beta 1.20.1 [OBSOLETE]

[vanhage]

Clicking the Resolution Lock on the Setup tab and then saving the file should address this issue.

I'll try to describe more clearly. If I lock the resolution to the desired size and launch the octane render viewport, the camera FOV gets modified by changes to the selected rhino viewport. See attached screen grabs.I'm not sure if this is more of a rhino issue, but it seems like the camera FOV is inherited from the rhino viewport directly with no way to lock its value to the render target.

The concern for me would be that if I set up a view and I can't replicate the exact viewport configuration that I had at the time I made the render, there is no guarantee that I can do the same render again.

Keep it up.
-Pete

[face_off]

I'll try to describe more clearly. If I lock the resolution to the desired size and launch the octane render viewport, the camera FOV gets modified by changes to the selected rhino viewport. See attached screen grabs.I'm not sure if this is more of a rhino issue, but it seems like the camera FOV is inherited from the rhino viewport directly with no way to lock its value to the render target.

The concern for me would be that if I set up a view and I can't replicate the exact viewport configuration that I had at the time I made the render, there is no guarantee that I can do the same render again.

On the Octane Viewport there is a camera button (Viewport Navigation) - enable it and the Octane camera is no longer sync'd to the Rhino camera fov, position, target, etc. This setting gets saved with the rendertarget - so if you save the rendertarget to the Rhino View - whenever you select to render that View, it will use the saved rendertarget camera settings.

Paul

[vanhage]

On the Octane Viewport there is a camera button (Viewport Navigation) - enable it and the Octane camera is no longer sync'd to the Rhino camera fov, position, target, etc. This setting gets saved with the rendertarget - so if you save the rendertarget to the Rhino View - whenever you select to render that View, it will use the saved rendertarget camera settings.

I just did a test. When you enable the octane render viewport's navigation button it does lock the camera properties. BUT if you switch to another named view, the previous named views render target FOV gets applied to the named view render target FOV that you are switching to.

-Pete

[face_off]

I just did a test. When you enable the octane render viewport's navigation button it does lock the camera properties. BUT if you switch to another named view, the previous named views render target FOV gets applied to the named view render target FOV that you are switching to.

You are right - the Viewport Navigation button status is not being saved to the view. I will fix this for the next release.

Next release has a long list of mods and fixes. It is probably about 24hrs away....

Paul

[jitendra]

try ti decrease rayepsilon to 0.00001

Thank you Refracty.
It is solved.

[face_off]

I will fix this. The Octane ground plane material should be linked to the Rhino material assigned to the ground plane.

Quick update on this - the Rhino API is not giving access to the Ground Plane material - so for the moment pls create a surface plane for use as a ground plane - which you can then assign a material. I have reported the issue to McNeel - so will fix the problem once I get more info from them.

Paul

[face_off]

-For blocks which contain objects on layers that are off, the objects are visible in the render window. This can be worked around, but in an architectural context where teams of people collaborate to make the model, it seems odd to have to explode or delete geometry for the sake of the render.

Hi Pete - whilst I could reproduce this earlier today, I cannot now (so another change I made may have rectified this) - so can you pls re-confirm this issue still exists once you get the next release.

Thanks

Paul

[Bendbox]

I did my first complete project last night with Octane for Rhino and it is working wonderfully! I did run into two issues, but I'm not sure if they are bugs or intended behaviors.

1) When loading a background image and saving the file, it works perfectly -- however upon exiting Rhino, and the re-opening Rhino and the same saved file, the background image gets lost, and has to be re-assigned. It's not a big deal, just an extra step to have to re-assign a background image to the same file every time you re-open and need to render. Is this correct behavior or a bug?

2) When assigning a color, or texture map in the diffuse channel of the Octane material, the Rhino "rendered" viewport does not get updated, although the Octane rendered viewport does. (see screen grab below). In order to get the color or texture map to correctly show in the Rhino rendered viewport, one must change the color or texture map on the Rhino material itself, not in the Octane material. I know the Rhino material is then converted to an Octane material, but it just seams like an unecessary step to have to go back and forth between the Rhino material and the Octane one. But maybe there is a good reason for that workflow I'm missing.

Thanks for your wonderful work on this terrific plugin, I'm loving it!

[img][img]http://s9.postimg.org/e2kh5qbbj/Screen.jpg[/img][/img]

[face_off]

1) When loading a background image and saving the file, it works perfectly -- however upon exiting Rhino, and the re-opening Rhino and the same saved file, the background image gets lost, and has to be re-assigned. It's not a big deal, just an extra step to have to re-assign a background image to the same file every time you re-open and need to render. Is this correct behavior or a bug?

The loading of background images is really just for the purposed of getting your lighting and positioning right - the final compositing needs to be done outside Rhino. So the background image is not saved with the Rhino file. Ideally the image would be saved, but at this point in time it's not possible (and it's not a trivial thing to implement).

2) When assigning a color, or texture map in the diffuse channel of the Octane material, the Rhino "rendered" viewport does not get updated, although the Octane rendered viewport does. (see screen grab below). In order to get the color or texture map to correctly show in the Rhino rendered viewport, one must change the color or texture map on the Rhino material itself, not in the Octane material. I know the Rhino material is then converted to an Octane material, but it just seams like an unecessary step to have to go back and forth between the Rhino material and the Octane one. But maybe there is a good reason for that workflow I'm missing.

Yes - the is the correct behaviour. It is a one-way conversion process (since you might have a complex set of nodes plugged into the Octane diffuse pin which will not directly convert to a Rhino diffuse color). Is there a reason you need the Octane diffuse color in the Rhino Viewport? If you only want to set the color once, check the "Reconvert Materials Automatically" checkbox in the Settings. Then changing the Rhino material diffuse color will automatically cause the Octane material to be reconverted from the Rhino material. Be careful with this though - you loose your Octane material edits for that material.

Hope that answers your questions.

Paul

[Bendbox]

Is there a reason you need the Octane diffuse color in the Rhino Viewport?

Hi Paul,

Yes, for two reasons. It's faster (for me at least) to set up texture mapping using the Rhino Rendered Viewport than rendering in Octane. The second and main reason, is that I often send clients screenshots of the Rhino Rendered viewport for pre-rendering approval (this is mainly so they can check they will have the views they, want, graphics are in the correct positions, etc.) -- if the colors and texture maps don't show up, this is not possible to do. My work involves tons of graphics on surfaces and right now, I've got to change the Octane material and the Rhino material to get them to show in the Rhino viewport. Having to change both materials (octane and basic Rhino) seems like an extra step. I'm always working right next to (or over web connection with clients) and being able to see changes to material colors and textures in the Rhino Rendered viewport is very quick and informative. Much faster than during actual rendering. Then the Octane rendered viewport is used for material fine tweaking and lighting.