please take a closer look at the LiveDB material editor that you can see in this screenshot:
- Material editor of OctaneRender with scale
Kind regards
Dominique
Material Export Problems
Hello TIG,
please take a closer look at the LiveDB material editor that you can see in this screenshot:
As you can see it has a scale that says "10cm". The purpose of this scale is to define how the material should look like, how large it is. SketchUp uses units, e.g. meters for its model. So it is clearly defined how a material has to look like when applied to a SketchUp model. It certainly must NOT take any UV-map-scalings into account as in your first two screenshots, because the size of the texture and its scaling is already part of the material description. I certainly know that the scaling can be changed in a material, but it doesn't make sense to change it, because it already defines how it should look like relative to the 10cm scale. So there seems to be a bug in OctaneRender.
Kind regards
Dominique
please take a closer look at the LiveDB material editor that you can see in this screenshot:
As you can see it has a scale that says "10cm". The purpose of this scale is to define how the material should look like, how large it is. SketchUp uses units, e.g. meters for its model. So it is clearly defined how a material has to look like when applied to a SketchUp model. It certainly must NOT take any UV-map-scalings into account as in your first two screenshots, because the size of the texture and its scaling is already part of the material description. I certainly know that the scaling can be changed in a material, but it doesn't make sense to change it, because it already defines how it should look like relative to the 10cm scale. So there seems to be a bug in OctaneRender.
Kind regards
Dominique
The UV scale is dependent on the object rendered. On some objects the unit interval (0.0–1.0) spans one meter, on some objects it spans much more, on some it spans much less. There is no way of taking that into account on the material ball. On the material ball we have chosen to make the unit interval span about 2/3 of the circumference of the sphere.dom wrote:As you can see it has a scale that says "10cm".
--
Roeland
Hi Roeland,
sorry, I think you misunderstood me. I don't want the material editor/sphere to be changed, it is fine as it is. But the material editor is used to define a material. You can see in my screenshot of the material editor how the material should look like. And when applied to my model, it doesn't look this way in one of the two cases because it is incorrectly scaled by OctaneRender.
> On some objects the unit interval (0.0–1.0) spans one meter, on some objects it spans much more, on some it spans much less.
In the SketchUp exporter you can define the size of a unit, it is usually "Meters". And I think there is also such a setting in OctaneRender, which was also set to "Meters". Additionally it isn't the problem, because if you look at my screenshots, you can see that the *same* material was scaled with two different scales in the *same* scene. This shouldn't happen. It is a material, not a texture.
Maybe a more technical approach will help:
I think you have to normalize the UV vectors to a length of 1 (e.g. one meter). And THEN you have to use it to apply the material and texture.
What you currently seem to be doing is to use the UV vectors with their given length as vectors for the texture. This is obviously wrong, because it leads to differently scaled textures, which do not reproduce what was defined in the material editor. In the material editor I exactly defined how the material texture should be scaled according to the 10cm scale.
Do you understand what I mean? Or do you want to say that the 10cm scale in the material editor is useless and was added for no purpose?
I am sorry that this wasn't understandable in my first post, but I hope everything is clear now. It would be really great if you could fix this bug in OctaneRender!
Kind regards
Dominique
sorry, I think you misunderstood me. I don't want the material editor/sphere to be changed, it is fine as it is. But the material editor is used to define a material. You can see in my screenshot of the material editor how the material should look like. And when applied to my model, it doesn't look this way in one of the two cases because it is incorrectly scaled by OctaneRender.
> On some objects the unit interval (0.0–1.0) spans one meter, on some objects it spans much more, on some it spans much less.
In the SketchUp exporter you can define the size of a unit, it is usually "Meters". And I think there is also such a setting in OctaneRender, which was also set to "Meters". Additionally it isn't the problem, because if you look at my screenshots, you can see that the *same* material was scaled with two different scales in the *same* scene. This shouldn't happen. It is a material, not a texture.
Maybe a more technical approach will help:
I think you have to normalize the UV vectors to a length of 1 (e.g. one meter). And THEN you have to use it to apply the material and texture.
What you currently seem to be doing is to use the UV vectors with their given length as vectors for the texture. This is obviously wrong, because it leads to differently scaled textures, which do not reproduce what was defined in the material editor. In the material editor I exactly defined how the material texture should be scaled according to the 10cm scale.
Do you understand what I mean? Or do you want to say that the 10cm scale in the material editor is useless and was added for no purpose?
I am sorry that this wasn't understandable in my first post, but I hope everything is clear now. It would be really great if you could fix this bug in OctaneRender!
Kind regards
Dominique
The problem is that the UV scaling is dependent on the mesh, and it is not exported from the application. For instance in your living room example 1 unit spans the entire room when you use the floorplan (it needs to, because you don't want to tile the floorplan), but 1 unit spans some fixed distance when you use the wood texture (assuming it is tiled). That is why the stone texture gets scaled differently for those two cases. Octane has no way of knowing the unit length for the UV coordinates it is getting.
The cm scale is mainly there to scale procedural textures.
--
Roeland
The cm scale is mainly there to scale procedural textures.
--
Roeland
Oh, sorry, you are right, I didn't think about that! 
To know the size of the UV vectors it would have to take into account the size of the mesh. So you are right, it isn't sufficient to "normalize" the UV vector.
I now first thought that you could just compute the correct factor for scaling the material, but the problem is that it may be different in different areas on the mesh based on the projection of the texture (e.g. on a sphere). It would only work on flat surfaces.
Sorry, so the 10cm scale in the material editor is just to let the materials in the LiveDB have a similar scale. Ok. Sorry for the long posts and the many questions! It is a little bit unintuitive, but you are right, there doesn't seem to be a general solution for this problem
Kind regards
Dominique
To know the size of the UV vectors it would have to take into account the size of the mesh. So you are right, it isn't sufficient to "normalize" the UV vector.I now first thought that you could just compute the correct factor for scaling the material, but the problem is that it may be different in different areas on the mesh based on the projection of the texture (e.g. on a sphere). It would only work on flat surfaces.
Sorry, so the 10cm scale in the material editor is just to let the materials in the LiveDB have a similar scale. Ok. Sorry for the long posts and the many questions! It is a little bit unintuitive, but you are right, there doesn't seem to be a general solution for this problem
Kind regards
Dominique
In my example with the two materials on the three faces - "plain_pink+textured_brick+textured_brick[mapped@50%]" there are unexpected results from using two different LiveDB materials picked at random.
The LiveDB 'skin/leather' when used for the two materials, maps onto all three faces at the same size, although the plain_pink has no UV-mapping, the textured_brick is mapped at 100% on one face and the other face's textured_brick material was scaled to 50%: so here all mapping is ignored by this particular LiveDB material.
In contrast, the LiveDB 'wallpaper' when used for the two materials, is sized differently for all three faces: the former-plain_pink face is mapped very finely with a small repeat [rather than at 100% as would be logical - this could be an error in Octane?], but the textured_brick does map correctly, with the wallpaper appearing correctly at 'half-size' on the face using a scaled version of the textured_brick.
So... the question is what is the difference between the two LiveDB materials that gives these different results?
If the 'wallpaper' is typical then it does work as expected because a textured [and mapped] material in the SKP will be mimicked in the OCS LiveDB material, whereas a 'plain' untextured material in the SKP and then the OCS has no mapping data to use, so the LiveDB material is left floundering...
Shouldn't the untextured material that is swapped be mapped at 100% ? Or is this impossible to fix inside Octane ??
The LiveDB 'skin/leather' when used for the two materials, maps onto all three faces at the same size, although the plain_pink has no UV-mapping, the textured_brick is mapped at 100% on one face and the other face's textured_brick material was scaled to 50%: so here all mapping is ignored by this particular LiveDB material.
In contrast, the LiveDB 'wallpaper' when used for the two materials, is sized differently for all three faces: the former-plain_pink face is mapped very finely with a small repeat [rather than at 100% as would be logical - this could be an error in Octane?], but the textured_brick does map correctly, with the wallpaper appearing correctly at 'half-size' on the face using a scaled version of the textured_brick.
So... the question is what is the difference between the two LiveDB materials that gives these different results?
If the 'wallpaper' is typical then it does work as expected because a textured [and mapped] material in the SKP will be mimicked in the OCS LiveDB material, whereas a 'plain' untextured material in the SKP and then the OCS has no mapping data to use, so the LiveDB material is left floundering...
Shouldn't the untextured material that is swapped be mapped at 100% ? Or is this impossible to fix inside Octane ??
TIG
There are two systems for sampling textures in Octane. At the moment they are tied to the type of texture used.
The leather material uses a procedural volumetric texture. These are sampled in Octane using the position of the point. Therefore the scaling of this texture is dependent on the object having the correct size, and it is possible to compare the this material with the grid in the material preview.
The bricks and the wallpaper use an image texture, which is sampled with the UV coordinates from the mesh, so the scaling of this one depends on the UV mapping and is independent from the size of the object (but note that an application may adapt the UV mapping to the object size).
--
Roeland
The leather material uses a procedural volumetric texture. These are sampled in Octane using the position of the point. Therefore the scaling of this texture is dependent on the object having the correct size, and it is possible to compare the this material with the grid in the material preview.
The bricks and the wallpaper use an image texture, which is sampled with the UV coordinates from the mesh, so the scaling of this one depends on the UV mapping and is independent from the size of the object (but note that an application may adapt the UV mapping to the object size).
--
Roeland
So how do users know which LiveDB material is which ?
The first kind ignore all SKP mapping and texturing/plainness.
All SKP textured materials imported are suited to the the second kind of UV-mappng.
A SKP's plain materials don't swap well with LiveDB with second type.
Can the 'kind' of LiveDB material be adjusted ??
It all appears somewhat arcane and steeped in mystery, and not at all intuitive or clear...
Users want to be able to swap materials simply, and not worry about these complexities too much.
The first kind ignore all SKP mapping and texturing/plainness.
All SKP textured materials imported are suited to the the second kind of UV-mappng.
A SKP's plain materials don't swap well with LiveDB with second type.
Can the 'kind' of LiveDB material be adjusted ??
It all appears somewhat arcane and steeped in mystery, and not at all intuitive or clear...
Users want to be able to swap materials simply, and not worry about these complexities too much.
TIG