Maya texture.outColor for Octane Materials

[dionysiusmarquis]

Hi, i really like the Maya plugin! It's gettin' better with every update. There is really not much to zero to complain.

At the moment there is just one thing: It would be a real time saver to be able to use any .outColor with octane Materials. To use the color information directly without baking out everything first. Is this possible or even already planned?

[JimStar]

No, Octane is nothing to do with Maya's CPU nodegraph calculation. Octane nodes work absolutely different in comparison to Maya's CPU-calculated nodes, so their color inputs-outputs are not compatible by design.
So, if you like to use Octane in Maya - be prepared to use Octane nodes only in Octane rendered scenes.

[dionysiusmarquis]

Yes ok I get it. I was already sure it couldn't be something trivial like float3 -> octaneTextureData. I was more thinking of using the bytes processing octane already uses for image files as an pipeline. I never looked deeper into outColor. But if its possible to rewrite the float3 outcolor to ram in an image like format wouldn't it be possible to feet octane with it somehow.

Maybe I'm still missing something here but that was my thinking when I was implementing HDR Light studio for Maya Octane as it feeds octane with new image data from hdd by changing the imageTextureName. I surely will look deeper to outColor just to get the whole picture. Octane independent

[JimStar]

I was already sure it couldn't be something trivial like float3 -> octaneTextureData

(float3 * <count of times of CPU calculation of float3 for every pixel through full nodegraph dependencies of foreign node>) -> (store somewhere as image) -> (octaneImageTexture)
See the difference?
You will need to start Maya's standard (or MentalRay's, whatever node's outColor you will have) full CPU node-graph render to get all image pixel's "float3" before feeding it to Octane. You will kill all the Octane's advantages by this CPU calculation of every foreign node before starting Octane rendering process (and by every Octane's Live-render refresh).

Just forget about it.

[dionysiusmarquis]

Oh yeah. That completely makes sense. But I think we got a misunderstanding here. I was thinking of updating the data on specific request and via image or frame changes only optional. The functionality of octaneImageTexture just fed with ram data generated out of float3. I think it could be a real winning to be able to use Mayas procedurals and general texture generation.

Edit: Like a bake to ram. Mainly to save hdd space. And time to write bake scripts.

[dionysiusmarquis]

[*] Added ability to specify image data directly as value via the API, removing the need to always go via image files.

Hi again,

I just read about this in the new 1.5. Is it at least possible to have an node which opens the ability to feed octane with image data for testing purpose?

[face]

[*] Added ability to specify image data directly as value via the API, removing the need to always go via image files.

Hi again,

I just read about this in the new 1.5. Is it at least possible to have an node which opens the ability to feed octane with image data for testing purpose?

We can fill a 2d buffer which is used as image inside Octane. But this doesn´t means to put image data from MentalRay to Octane.
When Octane is select as Renderer, there is no chance to get a color information from MentalRay.
I think the most important thing to use this buffer, is to generate some procedural textures like veins, perlin noise or others.

face

[dionysiusmarquis]

I never wanted to use any other renderer than the software one!

[face]

That´s the same.
When you switch the renderer, you have only access to the color information of this renderer.
Whereby, we haven´t access to the Octane one because the API hasn´t this ability.

If this would be so simple, then no renderer would have an option to emulate the standart shaders or there is no need to convert between them.

face

[dionysiusmarquis]

Maybe I'm continuous misdescribing what I mean. I think Juanjo describes what I'm thinking about.

... I could add some kind of support for procedurals, it is planned for the 2.x cycle, but they are not going to be true procedurals, because I am going to need to rasterize them to a limited resolution image maps...

-Juanjo

I understand that it is time consuming in Octane terms. But a bake or rasterize or what's the right term to get the texture as Pixelbuffer or what ever is needed for Octane on demand or optional per changes would be really nice.

I'm talking about these Textures:


to get something like this:

I'm really sorry if theres is something I don't understand.

Edit: I'm already doing it quite often via Hypershade->Edit-> Convert to File Texture (Maya Software). But it's getting quite exhausting to do redo the Hypershade Convert to File for every tiny change in the texture.