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

Hi Phil,

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

It's like Candide wrote above - turn on the "Weld vertices along edges" option in MoI and then you will get an 8 vertex cube with shared vertices between the faces.

That's exactly what the weld option in MoI controls - whether to generate shared points where surfaces meet, or whether to have individual points for each surface but that are stacked up on the same location in space.

If you enable weld then you should be able to create an 8 vertex cube that will have the problem shown above when rendered in Octane.

- Michael

Here's an update. Radiance added Smooth Groups Support (not 100% finished yet) and it improved the situation greatly.

Here's a file that PAQ exported from MOI.

Without Smooth Groups.





With Smooth Groups.




Thanks for all the support Michael. I appreciate your insight and putting up with us as we work to make Octane Render a great tool for MOI users.

Hi Phil, that's nice to have some progress there!

But really smoothgroups is not the best solution - the best solution is to not try and do any kind of additional smoothing calculations or break angles or anything like that at all, and just use the vertex normals as provided in the OBJ file.

You're still going to see various artifacts if the accurate vertex normals are not used for shading, for example in your "with smooth groups" post above, there are some irregularities visible in this area here:




That is supposed to be a perfectly smooth sphere, and the vertex normals that are in the OBJ file come from that sphere.

But if you try to recreate the vertex normals from the polygon data alone, _even with a smoothing groups mechanism enabled_ (!!!) you won't get as good of a result as just using the normals that are stored in the file.

I don't really know how I could explain it in any better ways than above in this thread, did you see my prior simplified explanation about why smoothing groups should not have anything to do with rendering the output from MoI? That was here:
http://moi3d.com/forum/index.php?webtag=MOI&msg=3386.16


What about the cylinder case as posted above, does the new Octane smoothing groups mechanism solve that problem?


- Michael

Hi Phil,

It's still completely amazing that Radiance is trying to resolve this shading issues using smoothing groups.
It doesn't make any sence ... it's like importing the object in 3dsmax, remove the vertex normal map, and
using the smoothing group system to rebuild the normal and the sharp edges. That will NEVER match the accuracy and
the shading look from the original .obj with proper vertex normal.

This is how it looks in modo, without any smooth group, nor edge split.



Now, the smoothing goup system is super cool for poly software, it's definitively a nice feature ... it will enhance MoI (or cad)
models a lot, but will never come close to other render engine solution like C4D, Modo, LW, Maya Max etc.

Well it's just a non progammer advice :P

Hi Phil, any irregularites in the vertex normals will especially show up in areas with specular highlights in them or with reflective materials.

You really want to just be using those normals for shading instead of calculating anything by smoothing groups at all.

Here's a comparison from loading that exact same OBJ file into Cinema4D, which does utilize the vertex normals stored in the file for shading - as you can see it gives a "perfect" result - every area is shaded exactly the same as the original NURBS data, that's the kind of high quality that you get if using the stored vertex normals :



- Michael

Hi guys,

Those images are from a work in progress, the smooth group implementation is not finished.
People don't seem to understand things so i'll clarify them:

* I am not re-calculating vertex normals in octane, if they are present in the OBJ file, they are read and used directly for rendering. they are not modified or re-created by an averaging process.

* the images posted by philbo are not %100 in that the groups are used, but the correct splitpoints are not calculated yet. a vertex that is shared by 2 groups is currently set to the face normal, which gives the remaining facetting you see in the smoothgroup render. I'm still developing it and i need to write the code that handle these situations.

So just a bit of patience and when i'm done i'm sure it will look %100.
Phil posted those images a bit pre-maturely here, they are work in progress and clearly show that smoothing groups are the solution to the issue.

Radiance

Yeah I'm not sure why a renderer is looking at the smoothing group data at all. I always considered the smoothing group definitions in an .obj file to be "metadata" for the poly modeling apps. It's just an oldschool way for artists to have some control over the vertex normals. The vn definitions should always be what's referenced, even if smoothing groups were used to generate them.

Hi Phil, also if it helps any here is again the quote from the OBJ format spec:



Note the part that I put in bold - it is intended that when vertex normals are present in an OBJ file, that they are used to shade the polygons and smoothing groups actually have no role in the rendering.

Smoothing groups is a mechanism that you use when you are trying to create vertex normals from a bunch of polygons - if you have some better quality normals like ones that came from a NURBS surface, you need to use those better quality ones instead of trying to create new ones which will not be as accurate.

- Michael

smoothing groups are not used to recreate any vertex normals.
they are only used to define the bounds of interpolating the provided vertex normals during rendering.

without smoothing groups, models with large angles between polygons get abnormal shading, even when you use the provided high-quality vertex normals.
you need smooth groups in the OBJ file to render them correctly.

smoothing groups have nothing to do with recreating vertex normals in any way.
i think you're mixing up the concept of using smoothing groups in a modeling application,
and the transport of data in OBJ.

Radiance

Hi Radiance,



Every test that PaQ has done is showing otherwise though.

A good simple test is the cylinder case I posted above - if the vertex normals from the file were being used for shading, that would render as a completely smooth cylinder instead of in segments with visible breaks between them.

Also another thing doesn't make any sense - if you're using the vertex normals from the file for shading, then why are you also doing stuff related to smoothing groups?

A smoothing mechanism is something that is only used when you are creating vertex normals from polygon faces.

So it is simply not physically possible to both be using stored vertex normals, and at the same time using a smoothing group mechanism - if you are using smoothing groups it means you are calculating vertex normals and if you are calculating vertex normals it means you are not using the stored ones...


It's an "either or" situation - Either you are using the stored vertex normals, _OR_ you are using a smoothing group mechanism to create vertex normals.

You can't be doing both at the same time.

All signs point towards you creating the normals from the polygon data and not using the normals from the OBJ file to shade with.


- Michael