Hi PaQ,

> Shading artefact :P there is no reflection on this one, so
> the line here are coming from Octane trying to smooth
> the whole stuff.

Well a box is a nice simple case to work with, so that's actually good...

Getting artifacts with welding turned on like this probably means that the faces in Octane are using a shared vertex normal even though in the OBJ file each of those faces only shares a 3D point location and has separate non-shared vertex normals.

Is it possible to recreate this problem with an export created from scratch in Modo?

Try making a simple 6-faced cube in Modo, make sure you have it welded so there are only 8 vertices for the cube (so like if you moved just one corner vertex all the faces move and not just one face like it would with stacked up individual vertices), then export that to an OBJ file.

Does the one exported from Modo also have the same artifact when read into Octane? Maybe post the Modo-generated OBJ cube here so I can look at it and verify that Modo wrote a welded OBJ file and did not do something like unweld it at export time only.


> That was the first trick we used ... but of course turning
> welding off introduce a lot of other problems, like discontinuity
> on every smooth surfaces.

Well, it would only have that kind of an effect with creating discontinuities on smooth surfaces if it is creating vertex normals itself rather than using the ones from the file.

If the vertex normals from the file were actually being used, turning welding off would have no effect on shading at all.

But when normals are created by an "averaging adjacent face normals" method, that's when welding can have an impact because non-welded polygons will not be considered to be adjacent...


So it really really looks like the vertex normals in the OBJ file are not being used...


Phil, is there any way to turn on a debug display to visualize the vertex normals within the Octane display?

That would probably help a lot if that could be set up, that way it would be a lot easier to point to one specific vertex normal and say "Look at that one, it is not right, it should be pointing like this instead" ...


> My main problem here is to explain it to Radiance, as he
> doesn't seems to understand the problem. From his pov,
> there is something special in MoI, whatever I can show.

Well, it should be possible to show him the same problem from other programs as well, since other CAD programs will produce similar structured things with vertex normals set up as well.

But maybe an easy first step would be to see if you can repeat the welded cube artifact problem from something created only in Modo.

- Michael

Hi PaQ,

> Well actually that's something I don't really get. As I did a tons
> of test since few days, I actually get some case where, for the same
> object, the Ngone version is giving a much better result in Modo
> that the full triangulate one. Actually it's also visible in MoI viewport.

Hmm, that's kind of strange that you see a difference in MoI with that.

It could be something like a different triangulation being used for the display between the cases, but that is kind of surprising so could you e-mail me that file at moi@moi3d.com so I can check it over here?

I think that's a separate thing from this Octane issue though.

- Michael

Hi Michael

Modo unit cube :





I didn't add any env map here, so the scene is lit with a 'white' constant color.

(I'm sending the Ngone vs Tris right know)

Hi PaQ, so on your latest fillet cube example there, I notice that the artifacts are really pronounced in spots where there has been a centroid-style triangulation where the n-gon is triangluated with a center point added to it so the triangles are arranged in a kind of radial manner.

That also probably explains the difference that you saw between "triangles only" export and n-gons export in some cases, I forgot there can be different display triangulations used between those cases because the "triangles only" one gets those centroid points added when possible but the display triangulation for n-gons does not add them in and only connects triangles from the outer points of an n-gon.

You can disable the centroid style triangulation in moi.ini, under [Mesh Export], put:

[Mesh Export]
CentroidTriangulation=n


It looks like that could possibly shift the artifacts around a bit.

- Michael

Hi PaQ, re: Modo cube - so the cube generated only from Modo has the same kind of problem, it is not supposed to look like that right?

So that's some good information to send over to him in a kind of a batch, like:


Here's an OBJ file generated from MoI. Here's what it looks like in Octane, it's messed up.

Here's an OBJ file generated from Modo (created from scratch in Modo, nothing at all from MoI in this case). Here's what it looks like in Octane, it's also messed up in the same kind of a way.

Here's what both of these OBJ files look like rendered in some other rendering programs (Modo, Max, whatever), they render both of these cubes as expected, with distinct flat faces.


It looks like Octane is not reading in the vertex normals from the file - even though the cube faces have shared vertices (the xyz vertex locations), each face has separate vertex normals specified in the file, but when Octane reads it in, it does not seem to be using the vertex normals that were specified in the file and seems to be creating some other ones, maybe ones that are shared between the faces although that is not how they are in the OBJ file.

- Michael

Hi Michael,

Thanks for this centroid tip,

There are no more difference in MoI viewport between triangle and Ngones version, so no more difference in Modo either.

But as expected, it doesn't change anything for Octane :P

Centro off

Hi PaQ,

> But as expected, it doesn't change anything for Octane :P

Well, the artifacts are slightly more evenly arranged... :)

But yeah you probably don't want any artifacts at all, hmmm?

In a moment I will do an export of your filleted cube out of Rhino for you test with as well.

- Michael

Hi PaQ,

> In a moment I will do an export of your filleted cube out of
> Rhino for you test with as well.

Actually, I won't do that, because actually Rhino doesn't have any way to write a welded OBJ file, it can only write the structure as when MoI has welding disabled, which I think you said produces a pretty different result.

For welding problems, let's focus on the cube example. That example is pretty clear - cube from MoI = problem, cube from Modo = same problem...

Probably a different case for non-welded would be good, a simple shape that is supposed to be smooth but gets creases in Octane. What would be work for that, maybe just a cylinder in 4 segments?

- Michael

Hi Michael,

\\re :Modo cube

So the whole trick is to explain that IF the normal vertex channel WAS actually correctly read by Octane, we should get a flat shaded cube, without any smooth group/edge split system.

... but that's something I allready tried to explain, without real succes ...

I don't know what to think about Radiance's normal test from blender, where he actually invert or move the normal manually before exporting the model.
The model is actally looking like a mess in Octane, inverted normal seems indeed inverted ... so somehow ... Octane is reading the vertex normal direction from the .obj file.

Hi PaQ,

> ... but that's something I allready tried to explain,
> without real succes ...

Hmmm, well I guess maybe don't try to explain the actual cause since that is going nowhere, just give the facts?? Like:


Simple cube exported from MoI - doesn't work properly in Octane.

Simple cube exported from Modo - also doesn't work properly in Octane - this certainly proves it is not anything specific to MoI.

Same cube works properly in every single other renderer...

So that's a pretty significant bug, Octane should be able to render those cubes the same as other renderers are able to.

The cube OBJ files are nice and simple short files without much data in them so eventually he should be able to dig into them and figure out what is going wrong in Octane.


> The model is actally looking like a mess in Octane, inverted
> normal seems indeed inverted ... so somehow ... Octane is
> reading the vertex normal direction from the .obj file.

Hmmm, well it sounds like he is possibly reading them in but somehow only using them for frontface/backface type calculations and not actually for generating the pixel level shading.

That would be quite strange though, because the primary purpose of vertex normals is to be used for shading!

For welded data though, the cube examples seem to show that they are not actually being read in properly for cases where faces have a shared 3D vertex but individual "per-face" normals. In some cases if a program only has lists of data at the vertex level it can have difficulty dealing with per-face type data, that might be one structural problem area.

- Michael

Hi Michael,

[Actually, I won't do that, because actually Rhino doesn't have any way to write a welded OBJ file, it can only write the structure as when MoI has welding disabled, which I think you said produces a pretty different result.

For welding problems, let's focus on the cube example. That example is pretty clear - cube from MoI = problem, cube from Modo = same problem...

Probably a different case for non-welded would be good, a simple shape that is supposed to be smooth but gets creases in Octane. What would be work for that, maybe just a cylinder in 4 segments?]


I've allready post so many examples, with edge weld on, off, closup of surface discontinuity, reflection glitches ... giving the .obj, compared with modo (it's the only software I have at home to comparing stuffs).

And of course I allways give extreme exemple with super low mesh ... because it's where artefacts are visible.
It's also true that if I tesselate my model like a fool, I have probably more polys than rendered pixels, glitches are not visible anymore :O)

... but it doesn't mean that low res has to look like 'shit' (sorry it's starting to be a little bit late here :)).

So I know I'm picky on that point, hopefully other users seems to be also annoyed with this, and I'm sure Radiance want to please users as much as possible.

Maybe there is something I don't understand, maybe the smoothing group implementation will also fix the other problems ...

Hi PaQ,

> Maybe there is something I don't understand, maybe the
> smoothing group implementation will also fix the other
> problems ...

Well, no it's not gonna unless by "smoothing groups" he actually means "using the vertex normals from the OBJ file to do the shading"...


Well, maybe Phil can use the cube example, that's a very simple example and it's always easier for someone to analyze simple cases.

I guess you may want to just avoid trying to use Octane with any CAD data until the most basic stuff like just getting a cube in works though.


Maybe tomorrow or whatever could you do one more test with the attached file?


That's an unwelded file (with one version from MoI and one version from Rhino), and if it shows a segmented looking result in Octane instead of a smooth looking cylinder, then that definitely shows that vertex normals are not being used for the shading. That's another very simple case that you would probably want to be working in Octane before it would really be suitable for rendering any CAD data.

- Michael

Here's the output from Octane, with a simple diffuse material (with normal smoothing turned on or off). The black triangles is another problem Octane is currently having. Are the cylinders supposed to be completely smooth? I can see some larger segments on the sides, even with smoothing turned on

Is the relevant discussion over in the octane forum in a private thread for registered beta testers only or something? I couldn't find it when I searched.

Just going by what I've seen here, I agree with Michael's assertion that the vertex normals aren't being handled correctly. I don't like that example Radiance gave with the sphere from blender. It sounds like he just selected a few faces, flipped them, and exported. Seeing that the faces are messed up in Octane doesn't prove anything about how the vertex normals are being handled, since the winding order of the vertices in the face definitions would also have changed. Octane could very well still be just averaging face normals. I just can't see the usefulness in that example.

The thread is in the subforums for licensed Octane customers, yes. I'll ask to have it moved to the general area so that other folks can see it

Hi candide, thanks for testing that.

> Are the cylinders supposed to be completely smooth? I can
> see some larger segments on the sides, even with smoothing
> turned on

Yeah, it should be completely smooth if it was shaded using the vertex normals that are stored in the file.

If you see any segments at all, it means that smoothing is being created from the polygon data (which is in separate pieces because it was saved with no welding out of MoI) instead of using the true cylinder normals that are in the OBJ file.

For example here is what it looks like imported into Cinema4D and rendered, note that there is no visible seam between any of the segments:



- Michael

So Phil - a welded box and this unwelded segmented cylinder are both good very simple test cases for Octane.

It's really important for both of these simple cases (or at the very least the unwelded case) to work in order for CAD data to be handled well.

As best that I can tell, the problem is that the vertex normals in the OBJ file are not being used for doing the shading.

If they were, then the box would have flat looking faces instead of having improper smoothing applied there, and the cylinder would have smooth looking faces instead of having improper creasing applied in that case.

- Michael

Thanks Michael and Paq for putting so much time into this issue. I've learned a lot from reading this and will forward it to Radiance.

I tried to compare a cube exported with Blender and one with MOI3D.

The Blender file is this:

# Blender3D v249 OBJ File:
# www.blender3d.org
mtllib Blender-Cube.mtl
v 1.000000 -1.000000 -1.000000
v 1.000000 -1.000000 1.000000
v -1.000000 -1.000000 1.000000
v -1.000000 -1.000000 -1.000000
v 1.000000 1.000000 -1.000000
v 1.000000 1.000000 1.000000
v -1.000000 1.000000 1.000000
v -1.000000 1.000000 -1.000000
vn 0.000000 0.000000 -1.000000
vn -1.000000 -0.000000 -0.000000
vn -0.000000 -0.000000 1.000000
vn -0.000001 0.000000 1.000000
vn 1.000000 -0.000000 0.000000
vn 1.000000 0.000000 0.000000
vn 0.000000 1.000000 -0.000000
vn -0.000000 -1.000000 0.000000
usemtl Material
s off
f 5//1 1//1 4//1
f 5//1 4//1 8//1
f 3//2 7//2 8//2
f 3//2 8//2 4//2
f 2//3 6//3 3//3
f 6//4 7//4 3//4
f 1//5 5//5 2//5
f 5//6 6//6 2//6
f 5//7 8//7 6//7
f 8//7 7//7 6//7
f 1//8 2//8 3//8
f 1//8 3//8 4//8


That's what I'd expect. Why is the MOI file containing 12 points and in duplicate?

mtllib MOI-Cube.mtl
o object1
g object1
v 1.00000000 0.00000000 0.00000000
v 0.00000000 0.00000000 0.00000000
v 0.00000000 0.00000000 -1.00000000
v 1.00000000 0.00000000 -1.00000000
v 1.00000000 1.00000000 0.00000000
v 0.00000000 1.00000000 0.00000000
v 0.00000000 1.00000000 -1.00000000
v 1.00000000 1.00000000 -1.00000000
v 1.00000000 0.00000000 0.00000000
v 0.00000000 0.00000000 0.00000000
v 0.00000000 1.00000000 0.00000000
v 1.00000000 1.00000000 0.00000000
v 0.00000000 0.00000000 -1.00000000
v 0.00000000 0.00000000 0.00000000
v 0.00000000 1.00000000 0.00000000
v 0.00000000 1.00000000 -1.00000000
v 1.00000000 0.00000000 -1.00000000
v 0.00000000 0.00000000 -1.00000000
v 0.00000000 1.00000000 -1.00000000
v 1.00000000 1.00000000 -1.00000000
v 1.00000000 0.00000000 -1.00000000
v 1.00000000 0.00000000 0.00000000
v 1.00000000 1.00000000 0.00000000
v 1.00000000 1.00000000 -1.00000000
vt 0.00000000 1.00000000
vt 0.00000000 0.00000000
vt 1.00000000 0.00000000
vt 1.00000000 1.00000000
vt 0.00000000 1.00000000
vt 0.00000000 0.00000000
vt 1.00000000 0.00000000
vt 1.00000000 1.00000000
vt 0.00000000 1.00000000
vt 0.00000000 0.00000000
vt 1.00000000 0.00000000
vt 1.00000000 1.00000000
vt 0.00000000 1.00000000
vt 0.00000000 0.00000000
vt 1.00000000 0.00000000
vt 1.00000000 1.00000000
vt 0.00000000 1.00000000
vt 0.00000000 0.00000000
vt 1.00000000 0.00000000
vt 1.00000000 1.00000000
vt 0.00000000 1.00000000
vt 0.00000000 0.00000000
vt 1.00000000 0.00000000
vt 1.00000000 1.00000000
vn 0.00000000 -1.00000000 0.00000000
vn 0.00000000 -1.00000000 0.00000000
vn 0.00000000 -1.00000000 0.00000000
vn 0.00000000 -1.00000000 0.00000000
vn 0.00000000 1.00000000 0.00000000
vn 0.00000000 1.00000000 0.00000000
vn 0.00000000 1.00000000 0.00000000
vn 0.00000000 1.00000000 0.00000000
vn 0.00000000 0.00000000 1.00000000
vn 0.00000000 0.00000000 1.00000000
vn 0.00000000 0.00000000 1.00000000
vn 0.00000000 0.00000000 1.00000000
vn -1.00000000 0.00000000 0.00000000
vn -1.00000000 0.00000000 0.00000000
vn -1.00000000 0.00000000 0.00000000
vn -1.00000000 0.00000000 0.00000000
vn 0.00000000 0.00000000 -1.00000000
vn 0.00000000 0.00000000 -1.00000000
vn 0.00000000 0.00000000 -1.00000000
vn 0.00000000 0.00000000 -1.00000000
vn 1.00000000 0.00000000 0.00000000
vn 1.00000000 0.00000000 0.00000000
vn 1.00000000 0.00000000 0.00000000
vn 1.00000000 0.00000000 0.00000000
s 1
usemtl Default
f 1/1/1 2/2/2 3/3/3 4/4/4
s 2
f 8/8/8 7/7/7 6/6/6 5/5/5
s 3
f 12/12/12 11/11/11 10/10/10 9/9/9
s 4
f 13/13/13 14/14/14 15/15/15 16/16/16
s 5
f 17/17/17 18/18/18 19/19/19 20/20/20
s 6
f 24/24/24 23/23/23 22/22/22 21/21/21

If you tell Moi to weld vertices for export, it will create 8 too