OctaneRender for Rhino Beta 1.20.1 [OBSOLETE]

[face_off]

great improvement to lock the viewport now.
Now it sticks to the right rendering Viewport. Would it also be possible,
maybe via right-click on that "lock octane camera" that it also keeps
the camera settings / perspective even when navigating in the perspective
view afterwards. This would make handling / navigation in certain situations a lot more
convenient but lets you stay in your chosen perspective to create a great
lighting.

Hi Johannes

I'm not sure I 100% understand what you are after. Would it be possible to provide some more info pls? Are you wanting to keep the Octane or the Rhino camera/perspective settings? Maybe if you give an example of where it would be used that would help.

Thanks

Paul

[ALTO]

Would it also be possible,
maybe via right-click on that "lock octane camera" that it also keeps
the camera settings / perspective even when navigating in the perspective
view afterwards.

You can just create two perspective view in Rhino and lock Octane with one of them, while navigating in the other.

[newske]

My temporary fix for replacing all block instances at once.
Reference block must be at [0,0,0]

Code: Select all

import rhinoscriptsyntax as rs

blocks = rs.GetObjects("Select Blocks to be Replaced", rs.filter.instance)
ref = rs.GetObject("Select Reference Block", rs.filter.instance)

rs.EnableRedraw(False)
for block in blocks:
    rs.Command("_SelNone")
    rs.SelectObject(ref)
    rs.Command("_CopyToClipboard", echo=False)
    rs.Command("_Paste", echo=False)
    replacementBlock = rs.LastCreatedObjects()
    xfm = rs.BlockInstanceXform(block)
    rs.TransformObject(replacementBlock, xfm)
    rs.DeleteObject(block)

[face_off]

My temporary fix for replacing all block instances at once.
Reference block must be at [0,0,0]

Nice resolution - thanks for sharing.

I will see if this can be more automated in the plugin (could even add a button to call that script).

This makes me realize another issue: proxy geometry doesn't respond to an instances transformation matrix. This means that it's very difficult to scatter fauna since it would have to either be exported to .csv (or hopefully soon .txt) or changed manually...

You use the sliders in the plugin to transform each instance, OR you load a csv to scatter many of the one instance (so fauna would be the later case). There is a script I saw in these forums to export a scatter file for a set of Rhino block instances which could be used for this. Applying the block instance transform to the proxy doesn't work (at the moment or unless I secure the services of a maths genius) because you've got a block instance transform in one axis coordinate system (Rhino's Z = up), and the proxy (plugin) transform in another (Octane's Y = up), so combining them is not something I've worked out how to do.

Regarding reading in CSV rather than TXT, Octane Standalone reads CSV, so it seemed like the obvious choice of importing transforms. But TXT might be possible.

Paul

[face_off]

Newske - thinking about this some more - the sliders for scale and rotation in the Geometry tab could be removed, and the user could set the block instance scale and rotation to apply scale and rotation to the proxy. The current system (Geometry tab) was originally put in because of issues converting Rhino axis to Octane axis, but those are now solved, so the Block Instance transform could be used for the proxy transform. If everything thinks that is the way it should work, happy to make that changed.

Paul

[newske]

Hi Paul,

I have managed to get .csv exporting working -- it's not ideal though. Also that little python snippet I wrote doesn't account for all things (transformation wise) just location. I have been using the snippet below to organise csv files properly in my python export script.

The conversion from YUP to Z is a changebasis tranformation:

(1,0,0),(0,1,0),(0,0,1) TO (1,0,0),(0,0,1),(0,-1,0)

It can be neatly wrapped in a python function using the rhinoscriptsyntax to transform a normal transformation to something that octane can read:

Code: Select all

def XFormFlipYZ(xfm):
    flp = rs.XformChangeBasis2((1,0,0),(0,1,0),(0,0,1),(1,0,0),(0,0,1),(0,-1,0))
    return(flp * xfm)

However I'm sure googling changebasis transformations would offer the pure mathematical matrix solution, if that's desired.

Regarding blocks scaling proxies - that would be perfect! Just need that and a 'replace all' - where all the selected blocks get replaced by proxies.

----

On a similar note, there's a strangeness to using .csv files to scatter proxies - since they have to be linked to a block with proxy assignment, the coordinate system is thrown off if the block is not at 0,0,0 (as the coordinates seem linked to the block location). If the changes mentioned above aren't made (as they would more or less remove the need for scatter files altogether) it would be good to have a way to reference a .csv and reference block without actually having it in the scene - ie. just through Octane for Rhino's tabs - this would greatly ease the workflow for scatters.

----

On another note, I found that using the command line arguments for octane allowed for camera motion blur, which was a great effect. Is there any way to implement this? Seems like it might be difficult..


I hope the changebasis transformation might enable you to develop the scatters a bit more!

Newske



Edit:
The rhino common is Rhino.Geometry.Transform.ChangeBasis(x0,y0,z0,x1,y1,z1) which may be more useful to you

[face_off]

Hi Newske - thanks for the info. Yes, I worked with ChangeBasis during the development of the plugin, but wasn't getting the results I expected. I ended up using the code posted in the SketchUp forum here to solve the problem of converting transforms from XYZ to XZ-Y.

Regarding blocks scaling proxies - that would be perfect! Just need that and a 'replace all' - where all the selected blocks get replaced by proxies.

There are 2 requirements you listed there....

1) Use the block instance for the proxy scale and rotation. That is a pretty major change from the current plugin behavior, and will impact all users, so I need an indication everyone wants this change - otherwise I'll make the change and get lots of nasty emails from ppl saying they want it back to old way.

2) Add a button to propagate the selected block instance proxy to all instances of that block. This can be done.

On a similar note, there's a strangeness to using .csv files to scatter proxies - since they have to be linked to a block with proxy assignment, the coordinate system is thrown off if the block is not at 0,0,0 (as the coordinates seem linked to the block location). If the changes mentioned above aren't made (as they would more or less remove the need for scatter files altogether) it would be good to have a way to reference a .csv and reference block without actually having it in the scene - ie. just through Octane for Rhino's tabs - this would greatly ease the workflow for scatters.

This is a bug. The next version to set the location of a proxy host instance to 0, 0, 0 /IF/ it has a CSV file - that way the "translation" will be correct.

It's great to get this feedback on the proxy system. It's certainly an area where some tweaks will make a big difference. I would also love to add live updating to "scattered" geometry, although that requires reloading the transform, which has the potential to lag the system. Maybe it could be a configurable option.

I've got a new release almost ready and will add the above, and hopefully get it out in the next 24hrs.

There is also a very nice change going to happen (after Rhino SR6 is release) where the Material tab in the plugin will be moved into the Rhino Material panel. So you Octane materials will become another type of Rhino material. McNeel is assisting with this change by adding functionality into the SDK, to this change's release will need to be timed with the appropriate Rhino SR release.

Paul

[newske]

Hi Paul,
Great - looking forward to it.

1) Use the block instance for the proxy scale and rotation. That is a pretty major change from the current plugin behavior, and will impact all users, so I need an indication everyone wants this change - otherwise I'll make the change and get lots of nasty emails from ppl saying they want it back to old way.

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.


Regards,
Newske

[newske]

Hi Paul

It seems that the proxies assigned to blocks are cleared when the scene is saved/re-loaded. Of course this is a huge hassle to re-assign all proxies and scatters every time...

Newske

[face_off]

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 just need to know it something the majority of users want.

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.

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.

It seems that the proxies assigned to blocks are cleared when the scene is saved/re-loaded.

I will fix this.

Paul