OTOY Forums

Has anyone experienced this before? Please see attached image. The zigzagging in the glass bubble is not part of the mesh. In addition, there are raised lines going around the bubble. The vertical one is actually part of the mesh (it is a mold seam) although it appears way too wide, and the horizontal one is not really there except that in the mesh, the polys change shape in this area. This does not cause problems in other renderers, only Octane (I have imported the same mesh into other renderers with no issue).

I have tried rendering in Octane with both the 260 and the 560 separately with no difference. So it looks like an issue in Octane. Have I got some setting screwed up or something?

Thanks for any responses!

p.s. Forgot to mention that all textures are "simple" for now...no bitmaps, so there are also no bump/normal maps, etc.
Also, have added the software I am using to my signature (Cinema4D with the OctaneExporter plug).

Seems to happen when smoothing is on in conjunction with a high poly mesh. Almost as if Octane is having trouble with the normals or something. If I turn smoothing off, the problem goes away, but then I am left with each poly refracting at its own specific angle without normal smoothing between polys, which is bad too.

try to reduce the phong angle at 40 or below, it should fix the problem
ciao beppe

I lowered it to 35deg but no change.

I will go back and see if I missed something when I made the change.

Sorry, no go.

I tried angles from 5-89.5 in Cinema4D, with "Use Edge Breaks" on and off, and also with Angle Limit checked off instead of on. There were no changes to the ripple pattern.
Since I can take the same OctaneExporter obj file into other renderers with no problem, it has to be something in Octane, is my guess. The problem is exactly the same whether I use PT or PMC.

The plot thickens!

Apparently in the other renderers, the problem exists too, though only about half as bad. I couldn't see it until I rotated the object to a different angle. BUT...there is the option in one of the other programs to Recalc Normals, and that fixes the problem. So it appears to be that the normals data in the obj file is wrong and needs to be recalculated, but Octane does not have a feature yet to do the recalc, correct? Right now it is hard to say whether or not this affects non-specular materials since they do not involve refraction. But it is also an intermittent problem...Some refractive objects experience it, others don't.

Regarding the mesh image below, part of the problem appears to be how the normals are interpreted in those areas where a fairly uniform poly mesh butts up against another fairly uniform poly mesh, where the meeting between the two results in a complicated transition boundary. This accounts for the “lines” that appear in the Octane rendering at the start of this thread.

However, this is only part of the problem. The zig-zagging of the refractions in the Octane rendering may mean that overall, the normals may just be plain sloppy, containing large errors in direction. If this is the case, then all of the artifacts in the rendering are due to some level of erratic direction of the normals, resulting in a very exaggerated representation of the actual topography.

Again, I know that having tested this model in another renderer (that has the ability to recalculate the normals), that this problem can be completely and accurately corrected. Cinema4D by itself does not seem to be able to do this. Octane has no provisdion for recalculating normals either. The big question for me is, will Octane have this ability in the future?

Looking into this further, I still have no solution. So I did a bunch of tests today and here is a chart showing the results. I am suspecting that the problem has no single origin...It seems to be a mix of sloppy normals in an OBJ file coupled with a possible issue in Octane where it cannot deal with inaccuracies in the normals beyond some fuzzy threshold. In the least, it looks to me like Octane may be a little loose in its treatment of normals, compared to other unbiased renderers. When fine detail is required, it seems lacking in its ability to maintain that detail, most notably in refractive surfaces where inaccuracies become "magnified" and immediately apparent.

Anybody have any ideas?

After still more tests, I came to the following conclusions:
1. The "weld line" like boundary issues were caused by two separate problems:
a. The "weld-line" near the base is caused by a too low poly mesh for any renderer to faithfully construct. This
region is where a curved surface abruptly changes direction to meet another curved surface. Unless the
mesh has high enough resolution to record enough normals to faithfully reconstruct this boundary, it can
only go with the limited information the mesh actually possesses. Apparently, Octane exaggerates the
problem as of beta 2.57/2.58. The only solution is to use a much higher poly count.

b. All the other "weld'lines" were caused by a too low poly mesh for Octane for this type of object (even
though it had 273,880 polys). Apparently, and on a very smooth curvature where there are no abrupt
direction changes, if a mesh has a fairly regular polygon pattern that must meet up with another fairly
regular polygon pattern of different form, then a boundary between the two areas must be constructed that
patches the two areas together when the mesh is built (See closeup mesh image in earlier post). This is not
tolerated well in MaxwellRender or Octane, but it is far worse in Octane at this beta stage. The only solution
is to use a much higher poly count.

2. The OctaneExporter for Cinema4D (R12) is not part of the problem. The problem is in C4D itself, in part...After
exporting OBJ's via their native exporter, their Okino Wavefront exporter, and OctaneExporter, all had the
same identical problems, namely zigzagging and "weld-lines" when brought into Octane. So, I conclude that
C4D imports meshes and does something to the normals as some internal operation that cannot be adjusted or
turned off. Nothing in Preferences is available to counteract the problem. I validate this by the test I did
where I exported a higher poly OBJ file out of Maxwell (after Recalc Normals was clicked and smoothing angle
set to 89.5 deg) and directly imported it into Octane without passing through C4D. It rendered fine with hardly
any artifacts issues. I then took the OBJ export that was made in C4D (the same file that caused problems in
Octane), sent it back through Maxwell and re-exported it as another OBJ. This one also rendered fine in
Octane without much issue. Regardless of the path that the OBJ took from modeler to Octane, C4D corrupted
the quality of the OBJ in such a way that the original mesh quality could not be completely restored via
Maxwell's "Recalc Normals" function.

3. Exporting the OBJ mesh directly from my solid modeler (Creo) into Octane did not cause ANY issues that would
require post work in Photoshop, provided the mesh had a high enough poly count. Unfortunately, you cannot
export a Creo OBJ with more than four materials or the extra materials will simply be ignored and the resulting
surfaces ganged up randomly with the prior four....So this is not an option for Octane as of Beta 2.57/2.58. But
at least Creo respected the quality of the data it exported in the OBJ to the fullest degree.

4. Exporting the OBJ mesh directly from MaxwellRender into Octane did not cause any significant issues. With
what issues were apparent, lowering the Smoothing Angle from 89.5deg to something like 30deg helped to a
certain extent. But again, and unfortunately, you cannot export a Maxwell scene as one single OBJ file...All the
objects in the scene get exported to individual files, so this is not an option for Octane either, as of Beta
2.57/2.58.

5. MaxwellRender and Octane each have their own problems when interpreting OBJ files. However, when a
mesh is being uncooperative, Maxwell's "Recalc Normals" function can be a life-saver even though it does not
always remove all problems regarding normals. That having been said, I have never had a "perfect" render
out-of-the-box...Every render requires some post work in Photoshop to one degree or another, even if it is
minor.

6. The Wavefront OBJ format is probably a very good format, but unfortunately, it seems that each software
manufacturer takes liberty with the specification by doing things that divert from it in dangerous ways. For
instance, some exporters only export the OBJ file, not it's partner, MTL material file. This is not desirable in
that some applications may require the MTL file in order to properly load the OBJ file, and may hang or crash as
a result. Any well-written software should be able to avoid such a catastrophe by checking for the existence of
the MTL file first and should be able to generate its own default MTL if need be, when the MTL file does not
exist. The problem is that this ASSUMES that such software is written properly to detect such a problem, and
clearly, even if the software was NOT written to detect the problem, the OBJ file should always come with its
MTL file anyway...Even if it is nothing more than a default file with default materials. Some programmers
assume that just because their proprietary materials system cannot be exported to the OBJ format that they
should just ignore the MTL. This is sloppy programming practice since the OBJ format specifically includes the
MTL partner file.

This image shows my latest tests:
Another issue appears to be that each software vendor may be taking liberty with the accuracy of the data contained in the OBJ file. This is the only reason I can come up with to explain how one program can corrupt the quality of an OBJ as it passes through it from initial import to export. Or maybe they feel they should do something to the data because they feel it is important to fit the needs of their own software. Whatever the reason, the result is an exported OBJ that pulls away from the expected standard specification, and that causes nothing but grief for people who need to incorporate that data in their own programs. Interoperability is compromised because of lazy programming practices. The correct course to take when interoperability is concerned is to take into account the accuracy of the data that other software may require and if internally that accuracy is not used, then keep a preserved copy of the original data in case the file is to be exported, and to always do calculations at a high level of accuracy when it affects a possible export.

Where does this leave me and anyone else with a similar problem? Clearly, the perfect solution would be the ability for me to export out directly from Creo to Octane. Unfortunately...due to sloppy programming...Creo's exporter only allows a maximum of four materials!! Go figure. Where did the magic number "4" come from anyway?! Was it part of the OBJ specification? NOOOOOOOOO!

So my only other option is to use an intermediary step to combine my parts into a single OBJ file...A step which does not easily exist...Unless....Just unless, Octane soon (pretty please, VERY SOON) allows the rendering of multiple OBJ files. I will be in Heaven on that day. And a Recalc Normals button would sure be a great safety net when needed.

hi! quite a brick you wrote there I am intrigued on what may be causing this, this problem is pretty old actually, I could run similar tests in 3ds max and we should be able to issolate the reason. If you think you could attach an .obj, so we dont depart from this object. cheers