OTOY Forums

What makes it look this way (bad) in max is by unchecking normals, with normals it works ok. I also found it present in glossy materials, not only refractive, although it's less noticeable.

I guess Octane doesn't smooth properly without a good set of vertex normals. I hope they find a way to rebuild normals better than current, because exporting without normals cuts obj writing/reading time in half (that's why the models that work for you are twice as big)

You should try riptide's exporter for Cinema, and see how it goes

Yah, they're huge. It's compounded by the fact that I use rounds a lot. So if I have some object that could be fairly low poly, I have to hold the detail in the finest areas, and that usually means the rounds. So up goes the poly count.

I did notice that one program (can't remember which it was) did not export normals at all. So that obj version was going straight into Octane without the information.

Roeland mentioned he was looking at the issue, so I hope he finds something. I am going to try Jaberwocky's suggestion about MeshLab, too, to see what happens.

treddie wrote: I did notice that one program (can't remember which it was) did not export normals at all. So that obj version was going straight into Octane without the information.

what do you mean? Neither LW nor C4D seem to export normals, whether Creo and maxwell does (although maxwell rebuilds, so quality drops); note that with riptide you are still in c4D creating the obj so the normals information is there. With meshlab you'll try to fix an already faulty obj without normals

Neither LW nor C4D seem to export normals, whether Creo and maxwell does...

You know what? You're partially correct...I went back into the data and noticed there were no "vn" IDs in the C4D native export, but I did find them in abstrax's OctaneExporter version. Question is...did C4D remove them on import, forcing the OctaneExporter to rebuild them, or did C4D keep them and just mess them up?

I will try riptide's exporter as you suggest. But if C4D removes the normals info on import, just seems like EVERYONE who builds an exporter for it will have the same problem...rebuilding what C4D should just have left alone. So trying his exporter will be a quick experiment to do and see what happens. I will report back.

Creo and Maxwell definitely export the normals. Creo's are pristine which I kind of would expect that from an engineering program. UNFORTUNATELY, they brain fart when it comes to exporting textures...only a maximum of four allowed! Truly bizarre. I think all of these companies get together in a secret annual meeting conspiracy and decide how each can contribute to making each of their exporters stupid on different counts. ) Kind of like the Babylon of interchange formats. THE SOVIETS LIVE!!!!

Hm...according to the Riptide documentation, C4D does import normals. So I guess, not very well.

Thanks for the links Jaberwocky and Proupin. And the results are..

MeshLab was able to correct things to a certain extent. It seemed to be able to eliminate the zigzagging, or at least to reduce it so that it was practically gone, but had difficulty healing boundaries between butted mesh areas. Compared to Maxwell's Recalc Normals function, I think Maxwell did noticeably better, but certainly not perfect.

Now comes the interesting part. I then tried Riptide and if I both imported and exported in C4D with it, Octane would hang when the OBJ was imported. BUT...and again inside C4D, if I imported with Riptide and then EXPORTED with OctaneExporter...walla...a beautiful mesh:

and I think this supports my idea that C4D corrupts the normals. Riptide did something to maintain the data quality by circumventing C4D's native import function. Oddly though, it corrupted the export such that Octane would hang and have to be closed via Task Manager. Or possibly, Octane did not properly parse the data when it was imported there. I have no way of knowing either way.

There is however, one remaining issue in all of this, if we accept this whole approach for C4D as THE solution. In looking at the two closeups of the successful Octane render, there is an interesting watercolor quality to the mesh smoothing which I think is an Octane issue:
In the first image, the watercoloring seems to be just that...A watercolor-like texture. But in the second image, it appears that this texture is composed of incompletely smoothed polys.

Overall, things look much, much better although I have not yet attempted including the bubble in a multiple surface OBJ. That's next.

The shading calculation in Octane is faulty. Usually it is not that visible, but for transparent objects like this bulb it becomes more visible. I will make an updated release later today, you can then try if it looks better in the new release.

--
Roeland

Oh...Sweet! Thank you Roeland, your'e the best!

I'll give it a try and see what goes whenever you're ready.

Funny thing about this bubble...It was a pain to build the model so that it would render properly back in 2008. The surface was so unforgiving from a modeling and rendering standpoint. Took me 4 months to get it figured out, because it is a very precise reverse engineer of an Apollo Spacesuit helmet I took measurements from. So it wasn't like I had any liberties with how I could design it...It had to be what it was.

As a 3D model, it seems to frustratingly test anything it touches...Kind of like the Midas Touch in reverse. )

This is a copy of my response over in the Candidate testing area for the new release 2.58e.

The watercolor look is almost completely gone now. I think it's still there but VASTLY improved. In some spots I don't see it at all.

You can't see it in these images, but the zigzags are still there, unchanged. I really think that is a C4D problem. Especially since I just did another refractive test with another scene, using the same workflow as when the bubble would fail, and it's perfectly fine. This time, the refractive was a solid glass object, not a hollow one. I am going to test the same object but next with a thin surface instead of a complete solid to see if it behaves like the helmet bubble.

I think it is also possible that there is something intrinsically different about the bubble mesh from other meshes. Even though I have re-xported it from Creo, and the vertex normals are exported, maybe Creo did something unique that is difficult to interpret by other loaders. At any rate, Octane has zero problem with the mesh when it comes straight out of Creo. Unfortunately, I can't then combine it with other meshes easily for the single OBJ that Octane requires.

Thank you very much for your time on this Roeland. Much appreciated.

Everything is fixed. Woohoo!
These images do not show any of the prior issues. To do it, I adjusted my work flow so that Lightwave is no longer in the loop. Even though this means extra vertices in the OBJ file that Creo exports (these have nothing to do with the normals), I will just have to accept the larger file size. So now I go the following route:
CREO > C4D > Octane.

To make it work though, I have to go around C4Ds import function and use Riptide's importer. This makes it possible to get around C4D's faulty importer. But then I cannot use Riptide's exporter. It crashes Octane! So I use the OctaneExporter to get the file out of C4D and ready for Octane.

Thank you Roeland for your help on the "watercolor" problem. And thanks go out to Proupin and Jaberwocky, for suggesting Riptide and MeshLab, respectively. Although I am n ot using MeshLab at this point, it could very well get me out of a trouble spot in the future, so it is now part of my toolkit.

As soon as I add the fabric headpad and get my textures completed for the helmet and put it in the studio setup I made, I will post some final renders.