OTOY Forums

Can you tell me, is it expected that I should have to create overrides for most materials?

I was trying to do a test for each of the basic types of materials and could not get metal to work. The IOR is inaccessible unless the shader is transparent, and Octane requires the IOR on glossy materials to make metallic shaders?

Maybe I'm missing something.


Also can we please have a reset zoom button? And a resize window to fit render size?
The render window is so frustrating to inspect the image with, that I simply avoid navigating in it.

Thanks.

Could this feature be added through some sort of workaround? For me it doesn't have to match the Modo version as long as it's randomly selecting the meshes within the group when scattering them.

It's a great way to add variety. For example I recently used this for floor planks. 10 different planks distributed at random to get a varied floor. Or scattering different plants randomly over a landscape.

"Users can control the percentage that a group member is used by cloning the elements. For example, if the Group contains 9 red spheres and 1 blue cube, the blue cube only appear approximately 10% of the time across the surface."

First priority is of course to make it not crash even if it doesn't work properly.

It's a great way to add variety. For example I recently used this for floor planks. 10 different planks distributed at random to get a varied floor. Or scattering different plants randomly over a landscape.

I agree - this is needed, and thankfully easy to implement - you just need 2 (or more) Replicators instead of one - one for each mesh. The only downside to this approach is that it is possible to get more than one geometry item at the one spot - but for trees, plants, etc that is no issue. For planks of wood.....you might be better off just having a flat plane and using the wood planks texture from the LiveDb.

Crash is fixed in the next release, which I will get to you shortly.

Paul

You could also freeze the replicator so it uses instances instead.

HI
I just bought Octane today with the modo plugin.
I love the look of the renderer, and am trying to convert over some of my scenes.
I have a scene that was created in modo with a ground plan. It is mapped with a front projection texture with a shader and fog applied to it. I also have the image in the environment material as well, so I can have a complete seamless backdrop for the machinery in modo.
Is there a way to do that in Octane?
I don't seem to see how I could do this without creating a mesh object like a photography cyc.

I have a scene that was created in modo with a ground plan. It is mapped with a front projection texture with a shader and fog applied to it. I also have the image in the environment material as well, so I can have a complete seamless backdrop for the machinery in modo.
Is there a way to do that in Octane?
I don't seem to see how I could do this without creating a mesh object like a photography cyc.

It would be good to see a screenshot of the effect you are trying to get.

In general, fog would be implemented in Octane via a scatter node on a cube surrounding the scene. There seem to be a number of different ways this can be implemented, but as a starting point, check the thread from the Poser plugin forum from last week http://render.otoy.com/forum/viewtopic.php?f=45&t=38577.

There is also a Perspective projection node in Octane - which (and I haven't tried this myself) when located and directed from the camera, might be able to be used as a front projection. But that would be an advanced topic (and I'd need to research this to provide any more info).

Paul

Here's comparison between a MODO preview render window (left) and the Octane preview (right) with the same outer size. You can see that the MODO window respects the aspect ratio of the final resolution while fitting the whole camera view in the window. The Octane window zooms in and crops off parts of the camera frame.

Hi Riggles. I had another look at this. The image you posted has "Preview" enabled, so the Viewport is going to set the Octane Resolution. If the Octane Viewport and the Modo proview window are different aspect ratios, the Octane Viewport will preserve the HORIZONTAL fov (ie. what you can see rendering on the far left and right of the Modo poreview should match what's in the Octane Viewport. To get an exact match, turn off Preview, and tick "Use Modo Resolution" in the Kernel settings.

Paul

face_off wrote:

Here's comparison between a MODO preview render window (left) and the Octane preview (right) with the same outer size. You can see that the MODO window respects the aspect ratio of the final resolution while fitting the whole camera view in the window. The Octane window zooms in and crops off parts of the camera frame.

Hi Riggles. I had another look at this. The image you posted has "Preview" enabled, so the Viewport is going to set the Octane Resolution. If the Octane Viewport and the Modo proview window are different aspect ratios, the Octane Viewport will preserve the HORIZONTAL fov (ie. what you can see rendering on the far left and right of the Modo poreview should match what's in the Octane Viewport. To get an exact match, turn off Preview, and tick "Use Modo Resolution" in the Kernel settings.

Paul

I guess I'm still a little confused. Here's another screen capture:

The Octane viewport in Preview mode doesn't seem to respect either the horizontal or vertical FOV of the MODO render.

Basically, what I'd like is for the Octane viewport to behave the same way as the MODO viewport when in Preview mode. That is: taking the smaller dimension of the viewport window (x), setting that as the larger of the two Octane resolutions (x), then setting the smaller Octane resolution (y) by the aspect ratio of the final render. So: y=x/(16/9) or y=x/(5/4). That's what the MODO Preview Render window is doing. The benefit is that you get to see exactly what your render frame will cover no matter how big/small that preview window is. Otherwise, you'll have to manually change the resolution values back and forth between preview resolutions and final render resolutions, which is what we currently have to so.

Edit: I think I've added to my confusion by not using (or thoroughly understanding) the Overscan mode. I'd still like MODO Preview functionality, but that might require supporting Fill mode as well.

cakeller98 wrote:OK - perhaps a script though - that flattens the selection set tags down to individual material tags though? AND/OR a warning .... it should not simply be a confusing WTF and why is this not working?! it should be a transparent limitation that causes a notification from the render plugin that states... "you've got selection set tags, which won't render correctly"

silently failing will cost a bunch of folks a bunch of time wasted beating their head against a wall.

I think a better solution is to just put selection sets in the list of "known limitations". There's too many MODO native features that aren't supported to start creating notifications for them. That would also be quite annoying to those who already know these features aren't supported. Also, a known limitation list educates a potential buyer so they purchase the plugin with full knowledge of what does and doesn't work.

cakeller98 wrote:Can you tell me, is it expected that I should have to create overrides for most materials?

I was trying to do a test for each of the basic types of materials and could not get metal to work. The IOR is inaccessible unless the shader is transparent, and Octane requires the IOR on glossy materials to make metallic shaders?

Maybe I'm missing something.

I'm guessing that support for basic MODO materials in Octane is more of a convenience thing, not as a replacement for Octane materials. So, yes, I would recommend using overrides for your materials. (Side note: to control IOR for glossy surfaces in MODO, add a fresnel layer to your material and set it to "reflection amount". Also, check the "invert" and "reverse" boxes. This is only supported in the MODO renderer).

There's too many MODO native features that aren't supported to start creating notifications for them.

yes they should be known limitations in the manual OF COURSE.
maybe put them in the log, or dont.

but this response I keep hearing that "notifications get annoying" disregards the fact that modo will allow you to mute any warning you don't want to have again. so that's simply not an argument against warning dialogs... at all.

y'all don't want them, fine. I've found the limitations that I have to work around and gotten my stuff squared.

But I disagree with the statement of there being too many native features that aren't supported being reason not to tell the user why the renderer isn't working. though - I admit a dialog probably isn't the best way to notify for that stuff. logged advisories yes. dialogs no.

Maya has a great tool for pre-flight checking renderings, including giving diagnostics about what won't work in mental ray. In addition, mental ray at verbose logging will tell you EVERYTHING that isn't "right" with the renderer including things that don't wreck the render.

Yes, I agree with Paul, his time is better spent getting important things done on the plugin. But hopefully every feature that is supportable in a reasonable way will be supported - eventually...

Another thing about the difference between a list of known limitations vs warnings/notifications/log entries. If you don't know modo well enough you might not understand the limitation or how it relates to the problem you're having. So no... it's not enough to have a list of known limitation IMO.

But, I'm just one voice.