Post here Octane for Max bugs and wish list

[gabrielefx]

-> What about button with "material preset wizard" inside map editor? (glass\gold\metall\plastic\sss-cheese....)

-> And I realy need more then 2 layers in mix material - 5 оr about!!! Сombine the Mix-materials into one another completely illogical!!!

-> It is possible to go close to BSDF style of material and exclude the specular and to operate with the IOR and Fresnel? Or may be greate new type "BSDF-material"?

Do not swear strongly

I hope that Refractive will implement soon the fresnel effect. Without it is impossible to simulate many materials.
Regarding the mix material Refractive should implement a mix method like the Vrayblend material.

[tehfailsafe]

Is there not a way to lock the viewport to a camera view? It seems that the render viewport always switches to whichever viewport I click in, even if I hit the lock icon and try to move a camera in perspective...

Or am I missing something?

[KaroBastardKiter]

quick fix: keep the one you want to lock in perspective, the others in ortho, that's a workaround.

[tehfailsafe]

But I need to animate the camera?

[tehfailsafe]

Ah.
I see, set one of the viewports to the camera I wish to render, then only use othro view to select and move the camera in another viewport...


Maybe a real viewport lock can go on the wish list?

[frednork]

in this case the camera is on the floor. Vray perspective correction works differently, in Octane for Max there is no feedback in the viewport.

its only down low (on the floor) to illustrate a point. For what ever image you want, set the camera at the level or position that you want it at. Make sure it is HORIZONTAL (thats the key) and then change the aspect ratio. It is different to the way vray does the camera perspective correct, but the way it happens in a true camera is with a shift lens - all that a shift lens does effectively is change the direction that the field of view is looking at. I did say it was a low tech method for achieving the same result without having to fix it in post production.

3d max (and vray cameras) are nothing like reality in that we can set the aspect ratio as we want. the lens length is fixed to the horizontal (field of view) however the vertical is totally arbitrary. unlike reality we can create an image with a H:V ratio of 1:100 if we wanted to...

the method above works when I perspective match to camera lenses with a shift lens - I use the number of mm of shift as a ratio to the image and render the the portion i need with the camera (vray camera) set at horizontal.
so while it might not be how a vray camera works - it is a valid workaround to the problem in octane
f

[kevinshane]

here is some wish list for me ~~
1.rendertime status when hit the render button
2.add a "W,S,A,D" to move forward on the render buffer, "E,Q" to higher and lower the camera
3.mesh light is real time affected without reloading the scene

thank you ~~~

[a.boeglin]

Hi,

I have been using octane for 3DS max the last few days and come with a few things that can easily be improved/done and would make the workflow so much more friendly.

I'll start to agree with the point hereinbefore. rendertime status while rendering would be great, just knowing how many samples are computed. And regarding the mesh light in real time affected without reloading the scene is the most important feature imo. It may require to add a feature into the octane kernel, but this is really gold, and even more, I would say moving every object and having a real time feedback into the octane viewport ( must probably work for scale and rotation as well ). I think it could be done easily. I suppose when the viewport is being started, the voxelisation process translates max datas to octane datas and transfers it to the GPU memory. Moving objects would just need to update the position of the content into the gpu memory. It could even serve to move a furniture or something. Of course if we add or modify meshes we would need to restart the octane viewport as we would restart a render on any other renderer. But moving a light and reloading the scene to see its effect, is killing, especially when the scene begins to be a bit heavy.

Another little problem I noticed, when rendering, we don't have the camera properties affecting the 3DS max frame buffer. I understand it would be complicated to include these changes into the 3DS max frame buffer, but why not using the octane one and integrating a saving button and zoom functions ? Basically we would be using the octane viewport as it is called for now, and clicking render would just start the octane viewport, working at the resolution set into the Common settings tab.

And a last point, turbosmooth. I think it is really not a huge deal to take the smoothing iterations of the render checkbox rather than the viewport one. For now if the iterations in the viewport is set to 0 and the one of the render to 1, there will be no smooth in octane's render.

[gabrielefx]

Hi,

I have been using octane for 3DS max the last few days and come with a few things that can easily be improved/done and would make the workflow so much more friendly.

I'll start to agree with the point hereinbefore. rendertime status while rendering would be great, just knowing how many samples are computed. And regarding the mesh light in real time affected without reloading the scene is the most important feature imo. It may require to add a feature into the octane kernel, but this is really gold, and even more, I would say moving every object and having a real time feedback into the octane viewport ( must probably work for scale and rotation as well ). I think it could be done easily. I suppose when the viewport is being started, the voxelisation process translates max datas to octane datas and transfers it to the GPU memory. Moving objects would just need to update the position of the content into the gpu memory. It could even serve to move a furniture or something. Of course if we add or modify meshes we would need to restart the octane viewport as we would restart a render on any other renderer. But moving a light and reloading the scene to see its effect, is killing, especially when the scene begins to be a bit heavy.

Another little problem I noticed, when rendering, we don't have the camera properties affecting the 3DS max frame buffer. I understand it would be complicated to include these changes into the 3DS max frame buffer, but why not using the octane one and integrating a saving button and zoom functions ? Basically we would be using the octane viewport as it is called for now, and clicking render would just start the octane viewport, working at the resolution set into the Common settings tab.

And a last point, turbosmooth. I think it is really not a huge deal to take the smoothing iterations of the render checkbox rather than the viewport one. For now if the iterations in the viewport is set to 0 and the one of the render to 1, there will be no smooth in octane's render.

+1 for all
Many improvements need rewriting the Octane kernel.
RS is working on instances and realtime transformations.
The implementation of instances will change everything. Then many tasks could be improved and optimized, the mesh translation for example doesn't use all cpu cores and eats a lot of system ram.
Then the qmc zippering should be optimized too...Someone is working on new algorithms.
The overall features of Octane are impressive and I'm optimist, soon we will see a new powerful upgrade.

[walkerworkshop]

My octane render viewport is not exporting the alpha channel. Alpha only seems to work through rendering via render button.