Supporting native 3ds max maps
Supporting 3ds max maps is an ESSENTIAL feature, and i cannot persuade my company change our workflow without this. Its major drawback if we cannot use max maps. thanks
I can say this as a ~5 year user. That is not going to happen.thanulee wrote:Supporting 3ds max maps is an ESSENTIAL feature, and i cannot persuade my company change our workflow without this. Its major drawback if we cannot use max maps. thanks
Other rival gpu renderers also have hard time implementing all native maps.
Cebas finalrender (mosquito GPU) has the greatest support for native textures but it has its own major drawbacks.
You or your company should choose. Don't get your hopes up for what you ask.
I for example use vray if I need railclone Pro's Instancing Engine. Where as it's impossible use railclone and octane in very heavy scenes.
Sometimes it is the compatibility and native use that counts versus the speed and good look.

My Portfolio
windows 10 Pro. |1070 + 1070 + 1070 + 1070 | i7 @4.5Ghz
windows 10 Pro. |1070 + 1070 + 1070 + 1070 | i7 @4.5Ghz
Complete 3rd party procedural data has to be built on top of a live shader compiler - which will be introduced first through OSL in Octane.thanulee wrote:Supporting 3ds max maps is an ESSENTIAL feature, and i cannot persuade my company change our workflow without this. Its major drawback if we cannot use max maps. thanks
This means yes?Goldorak wrote: Complete 3rd party procedural data has to be built on top of a live shader compiler - which will be introduced first through OSL in Octane.

While i understand the technical difficulties, with all honesty is not my concern. As a customer i have certain needs. And those needs are not to my standards alone, are industry standards. I do not see any problem with all other engines. I tried redshift which is in beta, and is supporting everything with no issues.oguzbir wrote:.
Other rival gpu renderers also have hard time implementing all native maps.
Cebas finalrender (mosquito GPU) has the greatest support for native textures but it has its own major drawbacks.
It would be ideal to have all plugin support as well, but one step at a time

If I'm not mistaken, this means "you'll be welcome write your own procedurals in Open Shading Language". Or get them from a third party.thanulee wrote:This means yes?Goldorak wrote: Complete 3rd party procedural data has to be built on top of a live shader compiler - which will be introduced first through OSL in Octane.
Yes. The 3.1 shader compiler system can be leveraged by plug-ins to support/translate the host app's procedurals via OSL.riggles wrote:If I'm not mistaken, this means "you'll be welcome write your own procedurals in Open Shading Language". Or get them from a third party.thanulee wrote:This means yes?Goldorak wrote: Complete 3rd party procedural data has to be built on top of a live shader compiler - which will be introduced first through OSL in Octane.
Seriously?? If that is the case... This seems a completely useless feature, cause all reasons we pick octane is because we are artists and not programmers.... unless im missing something big here...riggles wrote: If I'm not mistaken, this means "you'll be welcome write your own procedurals in Open Shading Language". Or get them from a third party.
it means that someone might make money off making this kinds of supporting plugins to the.. plugins..
- C4D already supports its native maps
- C4D already supports its native maps
3dmax, zbrush, UE
//Behance profile //BOONAR
//Octane render toolbox 3dsmax
//Behance profile //BOONAR
//Octane render toolbox 3dsmax