Strange behavior in Specular material with HDRI

[treddie]

Heheh....A brick indeed. But it encapsulates the frustration of having spent the last two entire days trying to find a solution. If all the software vendors would just stick to the specification, I think none of us would be having any problems.

I am intrigued on what may be causing this, this problem is pretty old actually,

I am not surprised that it is an old problem since many programmers have been screwing around with "universal" specs for a very long time.

Can't upload any files today, as I think the servers are being worked on. Will try to upload the bubble tomorrow.

[treddie]

I think the file is too large to upload. I keep getting kicked out with a zip file of 19.3Mb.

Basically, if you are using Cinema4D (R12), which is where I know the problem exists in part, if you try to export out any OBJ from there and give it refractive surfaces in Octane, it will happen. It jacks up the normals so that any exporter that is used to get the OBJ out of C4D will have to do some sort of repair work to get it back to about where it was before it was imported.

Earlier on, when I was working out my new workflow to include Octane, I was using Lightwave instead of Cinema4D and did not have this problem there at all. UNFORTUNATELY, Lightwave10/11 has a zillion other issues that just make it a dog piece of software (used to be great. Now it's just buggy cow pie). C4D was looking so promising, so this glitch is very disappointing. I simply cannot run objects through it that have refractive surfaces in Octane. And until Octane supports multiple OBJs, I'm rather stuck.

[Proupin]

k, try to lighten up the file as much as possible by keeping a small portion of it and you've checked the artifact is present; I could try to do one model from scratch and investigate but that wouldn't help you at all cause my plan is to read the resulting .obj file (its data)

[treddie]

Proupin >

Still no luck uploading a lightweight model in a zip at even 12-19Mb. So I put the files on MediaFire with the link below:
http://www.mediafire.com/?e6ebx8iany4si2h

Because the mesh is much lower res than what Octane needed for it to be completely smooth at render time, it will probably show some defects. At any rate, the zig-zags shouldn't be there under any circumstances, but they're there in the C4D OBJ.

In the zip you will find different OBJs:
1. The original OBJ from Creo.
2. The Creo OBJ after having passed through C4D.
3. The Creo OBJ after having passed through Lightwave (Preferred one).

A problem with the direct OBJ export from Creo is that it has duplicated vertexes that serve absolutely no purpose at all for wherever boundaries occur (mesh area butting up mesh area, corners of an object, etc.). The Lightwave OBJ has these vertexes deleted. So if you want to compare data, I would stick with using the LW file as your reference, not the one fresh out of Creo. This should be OK, since I have not seen any issues with the mesh quality coming out of Lightwave (LW has OTHER issues, like with the MTL file...but I digress).

To summarize the behavior I have noticed, the following results come from when the OBJ file passes through the following programs from the modeler (Creo) to the renderer (Octane):

Creo --> Octane OK (OBJ stays pristine).

Creo --> C4D --> Octane BAD (Zigzags, weld lines, pillowing around complex detail).

Creo --> LW --> Octane OK (OBJ stays pristine).

Creo --> C4D --> Maxwell --> Octane Kind of OK (OBJ still a little damaged once Maxwell's "Recalc Normals" function is used to repair the bad C4D version
of the OBJ).

Also, to re-iterate, I do not believe the problem is in the exporters of C4D (native, Okino or OctaneExporter by abstrax at Refractive). Regardless of which exporter is used, all end up with the same corrupted state, implying that the data is already corrupted by C4D when it is imported into the program.

Looking at the data in the OBJ files, and comparing between the different versions is a bit difficult. It looked like Lightwave might have kept to the same general order of data in the categories (vertexes, texture coords and vertex normals), but the C4D data was all mixed up. You can try to do text comparisons to find the same vertex in each file, but this is complicated by the fact that C4D and LW change the precision of the data with C4D being the worst. LW would keep the same number of decimal digits for x and y, and then for some bizarre reason, drop one digit in z!. (OK...whatever, Newtek. Hey! I have an idea...If the data doesn't need to be changed, how 'bout just leave it alone?! Actually...How 'bout not screwing with the data at ALL?!). URGH! Frustrating. Brother.

[roeland]

This is a problem with smoothing and refraction. It is most visible if you assign a specular material with index 1, which should be transparent, and look from a distance.

For example this is a low poly sphere. Both sides should look like the right hand side.

I will try to solve the problem.

--
Roeland

[treddie]

Thank you Roeland.

You know, I tried playing with the index, and I found just the opposite! Or at least it seemed that way anyway. Dropping to "1" cleared it all up but then I got a sort of watercolor texture look to the transparency, which, when I zoomed in, looked like the triangles on both sides of the glass all superimposed over each other.

Also note the weird herring-bone like pattern on the glossy surface and the pillowing around areas of fine detail. I am only having these issues with C4D. It just seems to be something that messes up the data before exporting OBJ, because all of the exporters end up writing OBJ files with the same problem.

[GeoPappas]

This is a problem with smoothing and refraction...

I will try to solve the problem.

Awesome!!!

[treddie]

OK, now I am completely clueless. My previous work with taking OBJ from my modeler, through Lightwave to delete duplicated points, and then sent to Octane showed no problems at all. (See right image). But the image on the left, which took the same path from modeler to Octane has the dreaded zigzags. I THOUGHT LW was an OK path to take, but now I see that it is unpredictable.

To date then, the only (dependable as far as I know now) uncorrupted OBJ is the one right out of my modeler. As soon as it goes through any other program on its way to Octane, the refractives have a good chance to get screwed up.

[Jaberwocky]

treddie
You could try passing the obj file thorough Mesh Lab to see if one of the filters in that program fixes the mesh.

Just a thought.

link

http://meshlab.sourceforge.net/

regards

Jaba

[treddie]

Thanks for the link Jaberwocky! I'll try anything to find a solution to this. I know Roeland is working the problem, too.