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

Hi Radiance,



That's not proper vertex normal handling.

Again I will quote directly from the OBJ spec:




Note the part that I have put in bold - it is intended that when vertex normals are present in the OBJ file, they are used to shade the polygon and smoothing groups are completely unused and should not affect the rendering in any way.

If you read the vertex normals from the file, all the normals for every face are already defined and there is nothing you need to do with smoothing group processing.

Just take the normals that the face is using and use them.... Don't modify them by break angles or smoothing groups or anything like that.

Maybe you are using a completely different term for what "vertex normal" is or something?

- Michael

Hi,

I will explain.

look at the cone in the first image.
the vertex normals are shown as the lightblue lines.

if you render this object smooth using the vertex normals supplied,
you get ugly shading.

because the renderer will interpolate the vertex normal of the base piece center vertex with the vertex normals of the edges of the base of the cone.







there are 2 solutions to this:

1. split the cone triangles and the base triangles into 2 groups, eg smooth groups.
the renderer still uses the supplied vertex normals, but it does'nt interpolate vertex normals shared between 2 groups during rendering (i'm not talking about remaking / averaging new normals, i'm talking about computing the shading tangent from the vertex normals during raytracing)

this is the solution the the problem here, that's why i'm adding smoothgroup support to octane.

2. split the object into 2 objects, thereby duplicating the shared vertices.
this can be done with the 'edgesplit' modifier in blender, and this is what most of our users do (who use blender).
it solves the problem because you basically end up with 2 objects, eg all the shared vertices between the base and the top of the cone are duplicated at the same positions, but you're model has much more vertices.

these images are an example of the edgesplit (eg nr 2) solution:






the problem with paq's models is that they require solution 1, since moi3d exports them all as single vertices, and you use the smooth groups to create the bounds between what is what during tangent space interpolation.
you can see the wip smoothgroup image posted by phil solves the issue. it's still not perfect because as i said it's a work in progress and i'm not redefining the bounds correctly yet.


Radiance

Hi Radiance,

A really simple test would be to load the following cylinder file:

http://moi3d.com/forum/get_attachment.php?webtag=MOI&hash=db4239ff7598c1e3029b76f4090c7f19&filename=CylinderOctaneTest.zip

Every other rendering program that uses the vertex normals from the OBJ file for shading will render that as a completely smooth cylinder without any breaks between the different pieces.

Octane does not render it like that though, it shows breaks between the different cylinder pieces, which indicates that the cylinder normals that were stored in the OBJ file are not being used.

Either you're recreating them, or you're modifying them or whatever - maybe if you make a debug mode where you could display the vertex normals inside of Octane that would help me to point to one and show you that it is in a wrong direction.

Anyway, if you can't render the above file as a smooth seamless looking cylinder, it means you have some vertex normal handling problems.

- Michael

[quote]
Note the part that I have put in bold - it is intended that when vertex normals are present in the OBJ file, they are used to shade the polygon and smoothing groups are completely unused and should not affect the rendering in any way.
If you read the vertex normals from the file, all the normals for every face are already defined and there is nothing you need to do with smoothing group processing.
Just take the normals that the face is using and use them.... Don't modify them by break angles or smoothing groups or anything like that.
Maybe you are using a completely different term for what "vertex normal" is or something?

- Michael
[/quote]

you are correct only if you actually supply duplicates with different vertex normals of the vertices that are shared between polygons with a high angle, like the edgesplit solution.
if you supply only one vertex, you need to use the smoothing groups to differentiate.

sorry, i don't want to sound like mr know it all, but that's the way it is.
you should consider adding an option to your OBJ exporter that splits objects, eg duplicates vertexes shared on high angles (eg > 30 degrees or so), like the edgesplit solution.
however, if you just write what you do now, it will render fine once my smoothing group implementation is finished.

Radiance

just remove the smooth groups (eg delete all lines starting with 's') and try rendering it and you'll see what i mean.

Radiance

it's not possible to cure 0bjects in program like Meshlab? http://meshlab.sourceforge.net/

Hi Radiance,



Yeah, those are problem vertex normals, since they were created without regard to the desired surface breaking.

MoI and other CAD programs will never create improper vertex normals like you are showing there, in a CAD program the upper cone surface is a separate logical piece from the bottom cap surface.

When MoI exports to OBJ, it writes all exactly proper vertex normals into the file, it will never make ones like you show in that first image. Every single normal is already set up to point in its proper direction to make the right appearance.

So it is important when reading in stuff from a CAD program, to not try and do any manipulation or "fixing" of the problem you show because instead of fixing things you are actually going to be disturbing the vertex normals which are coming from the NURBS surfaces.



Still what you are writing does not really make sense - when using the vertex normals you should not be interpolating anything between faces at all, you already have the vertex normals for each vertex of a face, you should only be interpolating within a single face and not between faces.

If you are trying to interpolate between faces, it means you are messing around with making vertex normals instead of using the supplied ones which already are set up at every face.


Anyway, the simple case is to look at the cylinder example I posted above, if that does not render as a smooth looking cylinder then it means you have vertex normal handling problems. That's about as simple as I can make it.

Every other rendering program that utilizes the vertex normals from the file will make that cylinder look like a completely smooth cylinder, but it does not look that way in Octane.

- Michael

Radiance, a shared vertex can have multiple vertex normals. It's not a one-to-one correspondence. In your cone example, each of the shared vertices at the base would have two vertex normals defined, one pointing down parallel with the base face's normal, and one averaged to point between the side faces. The existence of multiple vertex normals is your cue to split the model up like you would with smoothing groups.

Hi Radiance,



No, that is not correct - in OBJ files there is more than one kind of vertex list.

There is a 3D vertex list, a UV vertex list, and a vertex normal list.

2 polygon faces that touch each other can share a single 3D vertex, but still have separate normals specified for them.

That's why faces have triplets for each vertex of the face, one index is for the 3D point, the second one for the UV and the third for the face's vertex normal.

So with OBJ structure, you don't have to only have all vertex information shared, you can have 3D points shared but individual normals per face.

If you are unable to have this kind of partial sharing for Octane, that may be a structural problem in your data where you only have face vertices contain a single index value for each face vertex instead of being able to have that kind of partial sharing.

Again, to make it simple just try the cylinder case above, if it does not render as a smooth cylinder in Octane as it does in every other rendering program, it means you have some problem with vertex normal handling.

> however, if you just write what you do now, it will render
> fine once my smoothing group implementation is finished.

That would be great, but it is unlikely because as I have written many times smoothing groups should have absolutely no effect on any rendering if you are actually using the vertex normals as supplied in the file.

It's totally an either-or situation - either you are using the vertex normals as stored in the file to do the shading, OR you are manipulating or creating normals by using smoothing groups, you can't be doing both at the same time.

- Michael

Sorry but the models that have been given to me by paq do not duplicate vertex normals on shared vertices.



if i ignore the smooth groups that's what i get.
if i use them, the output is fine.

Radiance