Page 3 of 9

Re: OctaneRender® for 3ds max® v2.11.1a

Posted: Mon Oct 20, 2014 8:35 am
by Norman_Stansfield
THANK YOU Karba and the team.
Right now octane for max (2.11.1a) is a renderer I've been waiting for years.
Fast easy, and optional static noise.
Able to work with fur and with forest pack pro.
Better displacement.

VRAY is dead, at least for me. Today I've tried to work with vray, but I couldnt anymore. Order of magnitude slower.

And it's great that community folks have direct influence on changes.
Keep it great, it's new industry direction.
I am slowly convincing the vfx company to switch software to octane.

all the best

Re: OctaneRender® for 3ds max® v2.11.1a

Posted: Tue Oct 21, 2014 6:49 pm
by dtxtreme
Hi Karba!

Is there a way to translate old colour correction settings to the new settings?
For instance, I have a value of black_level 0,18 (other values at default settings) which makes my texture a bit brighter with less contrast. The new contrast settings cannot be set to lower than the default value 0,001.

I´m in the middle of a big job and have a lot of colour correction settings to adjust to be able to upgrade :?

Thanks for you great work with the plugin!

Kind regards
Fredrik

Re: OctaneRender® for 3ds max® v2.11.1a

Posted: Wed Oct 22, 2014 12:19 am
by WhaleHunter
Hi Karba,

Bug Network rendering.
Octane loses samples when copying to max render buffer. (Just lost 6 gpu's worth of samples over 8 hours. makes me sad. //12000 samples gone)
Some slaves remained connected and their samples were ok. Some slaves and their samples can drop out & fail during the copy to max frame buffer. Octane does not find the samples again. This has been a recurrent theme on complex scenes, reasonably high resolution and working with network rendering since its implementation.

How to avoid this?
It appears that the master computer/s struggle with the copy to max frame buffer and cannot multi-task during this period. There also needs to be an underlying strategy for a graceful disconnection of slaves so that they never take their samples with them when they quit.

Also, at some time can we implement saving directly from octane buffer?

Regards,
N.

Re: OctaneRender® for 3ds max® v2.11.1a

Posted: Wed Oct 22, 2014 3:13 am
by Karba
dtxtreme wrote:Hi Karba!

Is there a way to translate old colour correction settings to the new settings?
For instance, I have a value of black_level 0,18 (other values at default settings) which makes my texture a bit brighter with less contrast. The new contrast settings cannot be set to lower than the default value 0,001.

I´m in the middle of a big job and have a lot of colour correction settings to adjust to be able to upgrade :?

Thanks for you great work with the plugin!

Kind regards
Fredrik
Try to decrease gamma. Result should be almost the same.

Re: OctaneRender® for 3ds max® v2.11.1a

Posted: Wed Oct 22, 2014 3:15 am
by Karba
WhaleHunter wrote:Hi Karba,

Bug Network rendering.
Octane loses samples when copying to max render buffer. (Just lost 6 gpu's worth of samples over 8 hours. makes me sad. //12000 samples gone)
Some slaves remained connected and their samples were ok. Some slaves and their samples can drop out & fail during the copy to max frame buffer. Octane does not find the samples again. This has been a recurrent theme on complex scenes, reasonably high resolution and working with network rendering since its implementation.

How to avoid this?
It appears that the master computer/s struggle with the copy to max frame buffer and cannot multi-task during this period. There also needs to be an underlying strategy for a graceful disconnection of slaves so that they never take their samples with them when they quit.

Also, at some time can we implement saving directly from octane buffer?

Regards,
N.
There is nothing I can do here. All slaves keep result on it's side, and if something happens there it will be lost.
Marcus are working on it.

Re: OctaneRender® for 3ds max® v2.11.1a

Posted: Wed Oct 22, 2014 3:16 am
by Karba
gabrielefx wrote:issue:

merging Octane proxies (from two scenes with different units) the scale is not respected.

Hi Karba,
could you add zipped proxy feature?
That is a little bit tricky. I will add some scale multiplier for easy rescale.

Re: OctaneRender® for 3ds max® v2.11.1a

Posted: Wed Oct 22, 2014 3:18 am
by emihich
Despite all possible bugs.
All the last improvements are awesome, thank you.

Re: OctaneRender® for 3ds max® v2.11.1a

Posted: Wed Oct 22, 2014 9:21 am
by mbetke
First of all, really great release. Just about to finish first full job with the new version and the new features really pushed my images. :)


One bug, but maybe it is intended:
When I lock the resoultion in interactive window and press the region render button, region render seems not to work. No rectangle.

Also, if I change displacement values in material editor while having open the interactive window it takes around 10-15 seconds until it updates. I can live with it but is it intended? Seems the CPU is pretty busy while doing the displacement calculations?

Re: OctaneRender® for 3ds max® v2.11.1a

Posted: Wed Oct 22, 2014 9:57 am
by boris
mbetke wrote: Also, if I change displacement values in material editor while having open the interactive window it takes around 10-15 seconds until it updates. I can live with it but is it intended? Seems the CPU is pretty busy while doing the displacement calculations?
displacement generates geometry at render time (that you don't have in your viewport). the gpu's need that raw geometry. so altering your settings will result in recalculating and reuploading the geometry to the gpu's I guess.
alternative (for speed improvement and/or gpu memory lowering): normal bump or bump. especially with normal bump you can achieve great results. but I guess you know that :)

Re: OctaneRender® for 3ds max® v2.11.1a

Posted: Wed Oct 22, 2014 10:18 am
by gabrielefx
issue with enlarged preview sphere (Max2014 sp5):

the render is cropped