OctaneRender™ Standalone 3.08 TEST 6

[Jolbertoquini]

Hi Pascal,
in your scene, the Baking texture projection is set to UVW-Planar mode, so it is not uniformely wrapped on the torus.
If you change the Projection to Mesh Uv, and connect the Baking Texture also to Diffuse, here is the result:

81A7B982-3811-4B2E-8447-202D78C02C61.jpeg

The texture is distributed in the same way, and you can see the little gap in conjunction, because the baked noise is different in the borders, but it’s an expected behavior, and obviously the procedural noise does not have this kind of issue.
Hope that it make sense.
ciao beppe

Arg, my scene must be confusing because of the displacement, so you missed my point I think.

This is the procedural noise that is using XYZtoUVW projection, not the BakingTexture node, the bakingTexture node use UVprojection.
And this is on purpose, because the point of a bakingTexture node is to convert a texture from a projection space to the UV space, else well this is a useless node that can only bake texture from UVspace to UVspace

So do you confirm this is a limitation of the bakingTexture node ? (only support UV procedural texture as input)
But in this case I think it's a bug because using different projection for the input procedural texture I get different with very weird projection...

Maybe I don't understand the purpose but Imo you cannot bake based on one UV projection and apply the result on a different UV projection. Well technically, yes you can but you may expect some unpredictable result.

Not agree, basically we are saying the usage for many years this is done in maya we are baking triplannar or camera projection on UV map you do that when you paint with Zbrush,Mari and etc.

The Idea of baking texture is just bake into texture the results you have like the camera baking. The camera baking does but you need save the texture and etc.

You are confused with the actual texture and the baking texture, Baking texture always will bake on UV, of corse you can't bake a projection... one other example Substance painter right at the core is just bake projection on UV sets.

Hope you understand now our point.

Cheers,
JO

[enricocerica]

Maybe I don't understand the purpose but Imo you cannot bake based on one UV projection and apply the result on a different UV projection.

yes You missed the point,
the main point of baking texture is to convert a procedural texture using whatever projection to the mesh UV space ....
Converting a procedural texture using one UV projection to a bitmap texture using the exact same UV projection is exactly what the bakingTexture node do, but lol this is kind of useless, well 1% useful...
If the baking camera is capable to bake texture from any projection Space to the mesh UV space, then the bakingTexture node should be able to do the same, I think that's just a bug and this node doesn't have the intended behavior with texture using projection as input...

Or maybe I just set it up wrong and I'm not clear enough to explain my point and get the explanation...

Agree with you, except that as you cannot use procedural texture for displacement this is a good way to get around this issue
By the way, I indeed missed the point

[calus]

Agree with you, except that as you cannot use procedural texture for displacement this is a good way to get around this issue

But this only works if you displace a plane ,
because as soon as you have UV seams in your mesh,
a procedural texture using a UV projection won't match at UV border so is useless for displacement.
This is why the main point of the bakingTexture Node must be to convert to mesh UV space a procedural texture using XYZtoUVW or Triplanar projection, for example (but not UVprojection),
and then the junction at UV border would be perfect, this is the purpose of such a node,
honestly I can't imagine this node's behavior have been done on purpose, this have to be a bug...

[Jolbertoquini]

Agree with you, except that as you cannot use procedural texture for displacement this is a good way to get around this issue
By the way, I indeed missed the point

I never said "you can use procedural maps in displacement" this the all point the reason of baking the projection, based on the UV of your mesh. Substance doesn't bake procedural do the same thing on the background.
kind basics this. I know is confused with similar terms such Texture, Bake , and etc hahaha

just to be clear.

[bepeg4d]

Hi,
please, look at the attached images, when you apply a baked texture in a different projection mode, the dimensions of the object become important, so you need to apply a transformation:

Replacing the texture with turbulance, you have the same effect:

ciao beppe

[calus]

Hey Bepe, thanks for taking the time,

- It seems in your example you also use a box projection in the bakingTexture Node and with the turbulence texture we can see that even like this the turbulence have been baked by the bakingTexture node like if the input was using a UVprojection,
because in the result you can see all kind of new texture seams inside the cube projection seams.

- Also in our case the bakingTexture node should always use a UVprojection because anyway the displacement node will always ignore any projection and always use the texture like if a UVprojection was used.

But thanks, anyway now i'm pretty sure the BakingTexture node just doesn't work,
to check on this just use any procedural texture with whatever projection you want (except UVprojection) and plug this in a bakingTexture node using a UVprojection,
then compare the procedural texture output with the bakingTexture output, you 'll see the bakingTexture node is trying to do something but just not what it is supposed to for a baking process ...

[mojave]

@Zay

Octane checks against the server the status of your user's ORC subscription. There seem to be an issue on the server side which I've asked the ORC team to investigate.

Thank you for reporting this.

[daniel.torres]

Thanks for the network fix. Something new pops up though:

OctaneRender 3.08 TEST 6 (3080007)

ORC user subscription request could not be performed: The server failed to proce
ss the request with HTTP code: 500
Launching net render slave (3080007) with master 192.168.0.10:1025

What's with the ORC user subscription request?

Hi Zay,

Could you give a bit more context for what you are trying to do? Sounds like you are trying to do some network rendering and this error is popping up. Is the error preventing you from moving forward?

[Zay]

Hi Zay,

Could you give a bit more context for what you are trying to do? Sounds like you are trying to do some network rendering and this error is popping up. Is the error preventing you from moving forward?

I have a regular license, so I wonder why the slave tells me "ORC user subscription request could not be performed: The server failed to proce
ss the request with HTTP code: 500", when I start the slave. Never seen that before.
But the slave works fine regardless. Just reporting what I see.

[abstrax]

Hi Zay,

Could you give a bit more context for what you are trying to do? Sounds like you are trying to do some network rendering and this error is popping up. Is the error preventing you from moving forward?

I have a regular license, so I wonder why the slave tells me "ORC user subscription request could not be performed: The server failed to proce
ss the request with HTTP code: 500", when I start the slave. Never seen that before.
But the slave works fine regardless. Just reporting what I see.

Sorry, that's a bug on our side. We added a check for the ORC subscription status, which shouldn't run in the slave at all. You can ignore this message and we will fix it with the next release.